As the recently issued 2020 Open Source Security & Risk Analysis (OSSRA) report from the Synopsys Cybersecurity Research Centre (CyRC) details, open source components and libraries are the foundation of literally every application in every industry in business today. It found that of the 1,250+ codebases examined in this year’s OSSRA report, 99% contained open source components.
The first OSSRA, issued in 2016, reported that 36% of the audited code was open source: that percentage has now nearly doubled to 70%. In other words, the average application contains significantly more open source than proprietary or commercial off-the-shelf code.
Taking Responsibility for the Code You Didn’t Write
While most development teams have processes in place to test and fix code they write, those processes don’t necessarily extend to open source. Proof of that can be seen in the codebases examined in the CyRC OSSRA report, where 75% contained at least one open source vulnerability, with nearly half containing high-risk vulnerabilities. An average of 82 vulnerabilities were identified per codebase.
The good news is that the vast majority of vulnerabilities listed in the 2020 OSSRA can be fixed with an update—usually only a minor patch—to the component. The bad news is that too few developers have developed the mindset that they “own” the open source they use as completely as they do the code they write and aren’t patching known issues with the open source in their software.
The open source community generally issues updates at a much faster pace than the average commercial software vendor. When these updates contain security patches, companies need to adopt them as soon as possible, but an alarming number of organizations consuming open source are not applying the patches they need, opening their business to the risk of attack and their applications to potential exploits.
In fact, many organizations are startlingly behind in using the latest version of any given open source component. The 2020 OSSRA found that 82% of the codebases examined contained open source components more than four years out of date, the result of an “insert and forget” mindset.
Developers typically don’t add version information about a component to the inventory spreadsheet before moving on to other work. No one takes on the responsibility to keep the component updated; it becomes legacy code, and as long as it continues to function as expected, is ignored and forgotten—until it breaks or comes under attack.
Keep the open source you use current with a software inventory—a.k.a. a software bill of materials (BOM)—that includes all open source components, the versions in use, and download locations. Maintaining an accurate, up-to-date software BOM can help organizations ensure their code is high quality, compliant, and secure. As in manufacturing, where the concept of a parts BOM was first invented, a software BOM allows you to pinpoint problematic components quickly and prioritize remediation efforts appropriately.
The Problem of Aging, Unsupported Open Source
also, 88% of the codebases examined in the 2020 OSSRA had open source components with no development activity in the last two years. All software ages and loses support, and with open source, the number of developers working to ensure updates—including feature improvements, as well as security and stability updates—decreases over time. The component eventually becomes legacy code and more likely to break without the support needed to provide fixes.
Without policies in place to address the risks that legacy open source can create, you open yourself up to the possibility of issues in your software. Again, a regularly refreshed software BOM can be key for monitoring the overall “health” of open source components—including identifying whether anyone is maintaining the code.
One of the reasons behind the popularity of open source is that viable projects usually have strong communities improving, updating, and patching vulnerability issues as they become known. As a first step to open source use, developers need to vet the health of a community before downloading any given open source component.
Even when a developer takes care to download components only from robust open source communities, there’s no guarantee the community will remain active in maintaining that component or the specific version downloaded.
From a pragmatic standpoint, engaging with the communities whose open source projects your organization relies on is one of the best ways to ensure those projects stay healthy and up to date.
A report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020 named “Vulnerabilities in the Core” found that some of the most active open source developers contributed to projects under their Microsoft, Google, IBM, or Intel employee email addresses, indicating that both those developers and their organizations recognize the importance of keeping the open source projects they use viable and active.
We still continue to see large numbers of vulnerabilities patched regularly, and we are aware of the challenges on security departments to maintain a regular patching schedule, but a BOM could be a way to help ease the pressure.