A recent Software Vulnerability Report revealed that of the 46 products appearing in the list of top 20 products with the most vulnerabilities during August – October in 2016, 11 were security-related products from vendors such as AlienVault, IBM, McAfee, Palo Alto and Splunk.
Many of the vulnerabilities in these security products are actually vulnerabilities discovered in open source, or third-party components embedded within them. This highlights how important it is that software producers understand the third-party components used in their products and the associated vulnerabilities.
It is unthinkable today that any software development team would not incorporate open source or third-party components into the product they help build. In fact, the average software product is made up of at least 50 percent open source technology. The ability of open source to expand a developer’s productivity has allowed the industry to create products containing large amounts of functionality, but also has created a situation where the security of the product depends on a long and complex software supply chain.
Even though their technology depends heavily on open source software (OSS), most organisations are not properly tracking and monitoring their use of these components. Data shows that most organisations have difficultly producing a Bill of Materials (BOM), or list of the open source they are using. Even during a Merger & Acquisition (M&A) – when a company is expected to provide as much information as possible – most organisations are unable to disclose even a single open source project they depend on. For many companies who have some components on their list, this list is still a small fraction of the true list of dependencies. Research shows that a company’s true list is typically on average 20 times larger than their current disclosure.
Pretty much every open source component is governed by a license, with obligations that a company must follow if they are distributing a product containing that component. These obligations typically include passing along the text of the license, copyright statements, and in some cases the source code of the component or complete product. Again, most organisations are not providing the content as required by the open source licenses.
How does this happen?
Developers are under intense pressure to build software products and release them on a tight schedule. Tracking and managing their use of open source has not been a part of most organisation’s heritage and has been ignored until it causes a serious high-visibility issue. Many people who find themselves managing a software team did not have access to the same amount of open source when they were learning to be developers. Senior management is also unaware of the compliance and security requirements of using open source software, so do not require compliance or OSS management. Often, it takes an outside event such as a hack, M&A activity, compliance request or OSS disclosure requirement from a customer to kick-start the process.
What can happen when you don’t manage your use of open source?
The two most common issues encountered by companies who do not properly manage their use of open source are being out of compliance with the licenses they use, and finding themselves at risk due to untracked vulnerabilities in the open source they are using.
The first issue often leads to the second. If a company does not know what open source it depends on, it is impossible to comply with the licenses as required. It also means that any current or future security vulnerabilities discovered in those software components are not handled. It is very common for OSS components to have new vulnerabilities discovered after they are first shipped. These vulnerabilities can sit silently in a shipping product until taken advantage of by attackers. This is especially important to track if your organisation is involved with security or networking.
How to start managing your use of open source?
The first element of an open source management programme is education. The basics of compliance and OSS management need to be taught at all levels of the organisation, not just at the developer level. Senior management must be made aware of the compliance requirements, as well as the need to periodically update shipping products in order to upgrade vulnerable open source components. If these requirements are not planned for and budgeted, they will not ever get done. In many companies, a small team of subject-matter experts across many disciplines at the company come together to form an Open Source Review Board (OSRB). This team often includes technical, legal, IT and management. The OSRB will help set policies, respond to compliance and security events and provide training and knowledge to the rest of the company pertaining to open source. The group can be ad hoc or more tightly structured depending on the maturity and size of a company.
These policies can then be implemented by the development teams. First to comply with all the open source licenses they are using, as well as create a process to discover vulnerable components and release upgrades as needed. Software Composition Analysis (SCA) tools exist to help discover and manage the OSS that is being used. These tools can also help automate the process of vulnerability alerting.
What does successful management look like?
After a company enacts policy, educates its employees and rolls out a SCA management solution, it will be able to display some of the hallmarks of OSS compliance and management. These include creating a BOM for each software release, following the license obligations as required and creating updates to shipping products when vulnerabilities are discovered. By setting up these processes and following OSS best practices, companies are able to successfully comply with community expectations and reduce their exposure to OSS-related vulnerabilities.
