It’s Tuesday morning and you arrive at the office before 8am to get an early jump on the day, only to find your inbox filled with customer inquiries about the latest OpenSSL security vulnerability announcement. They are asking (rather, demanding) to know if their recent product purchase relies on the version of OpenSSL in question. Ideally, you would be able to quickly pull up the open source bill of materials for each model number to verify whether OpenSSL is on the list. Note — the open source “bill of materials” is the list of all open source components used in the construction of a product, which is analogous to the ingredients list found on food packaging. However, in many organizations, this information is not easily accessible.
This “Tuesday morning” scenario is playing out with growing frequency. Many people are familiar with the Equifax (Apache Struts) breach in 2017, but serious vulnerabilities have also been reported in 2019 with PostgreSQL, Kubernetes, Docker, Python, RubyGems, libcurl, libssh2, and WordPress, just to name a few. To be clear, open source software is not more problematic than proprietary software with respect to security vulnerabilities. Open source is typically developed and heavily vetted by a community that scrutinizes the code. Identified vulnerabilities are often quickly squashed by the same army of contributing developers – enabling fixes to be made available shortly after a problem is identified. Often, the issue may center more around companies not applying the fixes as soon as they are available. That was the case with Equifax.
Another reason for the growing number of reported open source incidents is the increased dependency and use of open source components in the construction of modern day software solutions. Today, in order to be agile, it is the norm rather than the exception for software developers to leverage open source to the point where it represents the lion’s share of software from which a device is constructed. The Linux operating system, for instance, often serves as the nervous system for industrial devices. Hence, ignoring open source puts a company at a competitive disadvantage.
Unfortunately, for many companies, there is little transparency in terms of a product’s open source bill of materials. A formal program and disciplined effort is required to collect this information during the product development lifecycle. Hunting down this information post- product release can be an order of magnitude more costly in both time and money. Steps to take post-release typically include: (i) tracking down all the source code used to construct the product; (ii) gathering open source tribal knowledge dispersed among your suppliers and internal software development team (who may have moved on to other initiatives); and (iii) using source code analysis tools.
Open source component transparency is particularly important for software suppliers because of the multiplier effect they have in potentially propagating security vulnerabilities. In an attempt to get ahead of the problem, the Food and Drug Administration (FDA), in late 2018, added the requirement that premarket device submissions will need to include a software bill of materials.
This raises the question: How can I obtain assurance that my suppliers and development team have the discipline required to create a software bill of materials of sufficient quality?
The Linux Foundation's OpenChain certification provides an answer. The OpenChain specification defines a standard for assessing a company’s open source compliance program completeness. One of the core requirements is the creation (and maintenance) of an open source bill of materials. This requirement, which is necessary to manage open source in general, is also critical to security vulnerability management. As they say in the business, “you can’t manage what you can’t measure.” You can’t respond to vulnerabilities and threats if you don’t know they are present. To best position your company to respond to such inquiries, you need to start with the bill of materials of your suppliers and internal development team.
The OpenChain Specification is an open source project that has incorporated feedback from hundreds of contributors. Any organization can download it for free and visit the OpenChain conformance website to begin self-certification or engage a third-party certification authority. Although it may represent an additional requirement for suppliers, the cost to obtain OpenChain conformance pales in comparison to the time and cost savings obtained by using open source or the cost to remediate the situation post release. Most importantly, it mitigates the risk for the entire supply chain with regard to open source compliance and cyber security considerations.
OpenChain certification is a definitive way to be assured that you have access to the necessary information, and could help change your Tuesday morning fire drills into just another item to check off your list.
Mark Gisi , Director of Open Source Programs at Wind River Systems, is manager of the open source program office responsible for open source adoption; risk mitigation; community engagement and innovation acceleration. Mark is also a lead contributor to the Hyperledger Software Parts (SParts) lab project and chair of the Linux Foundation’s OpenChain Specification. Mark holds a MS degree in Computer Science and a BS degree in Mathematics. Mark has presented at over a dozen Linux Foundation events including the Open Source Leadership Summit, Open Source Summit North America and Europe, and Open Source Compliance Summit in Japan.