Best Practices for Open Source Governance
Companies of all sizes and across all industries are creating software products and relying on open source code to do it. Both Forrester and Gartner, the industry’s leading research and advisory firms, claim that anywhere between 80%-90% of all commercial software developers use open source components within their applications. But how is open source usage accounted for? How is it managed? Or is it?
The move from blind eye to a governance policy
Historically the answer would have been a blind eye and deaf ear turned to open source usage and an undocumented, unmonitored free hand given to developers to choose open source components at their own discretion.
Fast forward down the production line and these unsuspecting developers begin to notice that the excessive freedom they enjoy spells out more trouble than benefit as they pull open source components without checking for vulnerabilities, without considering vulnerability severity, with little knowledge of the licenses attached to their components of choice, and find themselves a few weeks or months down the line in a world of remediation hurt.
In today’s development climate, companies are questioning and negotiating the balance between getting their open source usage under control and managed in an automated, continuous and consistent manner, and leaving developers the freedom they need to productively do their jobs.
Related: Open Source License Compliance
A dialogue that needs to happen
Open source governance comes into play firstly as a conceptual idea. The idea being that an organization acknowledges the extent of its reliance on open source and agrees that there are too many risks involved in not knowing what components go into their code.
When the whens and hows of open source usage become real concerns, an organization starts talking amongst itself. It starts asking its legal, security, development and production teams how code is actually written and listening to the answers that come back. It then goes on to formulate a governance policy, placing particular emphasis on what developers – those “men on the ground” – have to say about how they do what they do.
This is the move from a conceptual governance policy to a practical one. From the understanding that an open source inventory needs to be managed somehow, to the policy by which the company tracks, approves, controls and maintains the open source components used in its software. The practical manifestation of a governance policy encompases a detection and approval process, an organizational chain of command to deal with open source usage, and a decision regarding the automation of these processes.
Real solutions for real problems
Open source code carries with it the potential for security, legal, and operational risks. If not handled properly, these risks can result in delayed release dates, extended go-to-market timelines, hundreds of thousands of dollars in remediation efforts, not to mention faulty usability and an unwanted customer experience for your end uses.
So what’s a CTO to do? The answer is two-fold. Primarily, avoid affected components from entering your code. Secondly, know about vulnerable components and treat them before hackers exploit. The answer is, in other words, formulate a governance policy for your organization and execute it.
It is that the solution stage that a governance policy will get into the nitty gritty of choosing automation tools. Software composition analysis tools (SCA) come in all shapes and sizes and their functionalities vary from one product to the next. These tools range in ability from detecting vulnerable components in the pre-pull stage and blocking vulnerable components from getting selected by developers, to detecting vulnerable components already in your code and pinpointing their location. SCA tools can be set to fit the security measures decided upon in your governance policy, so that they block vulnerable components of a certain severity but not another.
