Open-Source Security: The Good, the Bad, and the Ugly
Synopsys’s Security and Risk Analysis (OSSRA) Report reveals some interesting results for developers, including that almost all of the 1250 audited codebases included open-source software of some sort (see figure) which explains why open-source security must be addressed. This is good for open-source projects and for sharing code, but it can be bad if the open-source software contains security errors. The ugly aspect is that tracking open-source software use and keeping software up-to-date can be a challenge, especially if companies don’t know what open-source software is in their products.
Tracking a project’s software components is important regardless of whether the code is open source or not. Commercial software used within a project is usually easier to track since a contract is usually involved along with service and support. Open-source software is more of a challenge because one open-source project often depends on other open-source projects. Thus, the issue can cascade into a significant amount of code involved in a project.
Keeping up-to-date can be a challenge by itself—trying to find problems and get fixes is often problematic since there’s often no support services or contract involved. This alone is a good reason to support your favorite software project. Many software projects have commercial support of the project as well as paid support services, so using some projects is no different between using open- or closed-source software.
Keep in mind that open-source projects like Linux and Android are often the de facto standards for a whole range of products. As one of the report’s authors put it, “Open source was long seen as the domain of hobbyists and tinkerers. However, it has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smartphones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”
Synopsys Black Duck Audits is a service provided by Synopsys. Software audits software and services are available from a number of sources. Black Duck Audits examines source code to determine what open-source software is being used. From there, it can determine the versions involved and compare that to the current open-source project status, including bugs that may be outstanding or fixed. The anonymized results of audits are used to generate the report.
Software audits are also handy for finding IP dependencies due to licensing. This is important for open-source and commercial software. At one extreme are licenses that place no requirements on the distribution of an application. At the other extreme, a license may place requirements ranging from the release of open-source software used in a product to specific costs (e.g., a per device license fee).
On the plus side, the Black Duck analysis noted that 98% of the open-source software being used utilizes 20 of the most popular licenses like GPL or Apache. This simplifies dependencies and use of open-source software.
next: the security issues
But back to security.
Security issues can crop up in any software. Security holes in one piece of software can often be used as an exploit within a larger chunk of code. Often security errors attributed to operating systems like Windows and Linux are typically due to a problem in a driver or library employed by an application. Likewise, common libraries or runtimes are used in many aspects of an operating system or application. From a user’s perspective, the problem is the higher-level application or operating system, as they can’t delve into the underlying software where the error is located.
A number of organizations and services are addressing open-source security. For example, Open Web Application Security Project (OWASP) has tools, resources, and training. Synopsys’s Coverity Scan static-analysis service is available for free to open-source projects. And other tools like Sonatype’s Nexus Repository OSS version complement a commercial product.
Keeping open-source software up-to-date is something that can typically be done as part of a build process since the dependencies are based on the dates of files. Unfortunately, tracking bugs, especially those related to security, and their fixes is a much more manual process these days. It’s also one that will be critical for all types of development from systems through applications.