The good news: open source software is nearly universal. The bad news: half of source code repositories contain high-risk vulnerabilities, according to a new report released by the firm Synopsys.
An analysis of anonymized source code repositories finds that the vast majority of code is open source – much of it in need of a security upgrade.
Open source code was found in virtually all the code repositories audited – 99 percent. And it made up the bulk of the code in those repositories (70 percent), Synopsys found. But more open source use didn’t correlate with better security. In fact, 75 percent of the source code audited “contained vulnerabilities” and roughly half contained “high-risk vulnerabilities.”
Open Source is Growing, and Bringing Vulnerabilities With It
Synopsys’ 2020 Open Source Security and Risk Analysis is the fifth annual examination of open source software security, representing the data of more than 1,200 codebases.
The growth of open source is on the rise, the company found. Its share within codebases nearly doubled since 2015: from 36% to 70%. All sectors are employing it; with industries including telecommunications, financial services, clean energy, and IoT. This wide usage means the vulnerabilities and risk associated spread widely across the economy.
Synopsys’ Black Duck Audits identified an average of 445 open source
components per codebase in 2019, a big increase from the 298 components it found in 2018. Open source use is also concentrated. Synopsys counted 124 open source components that were commonly used across the codebases of 17 industries, many containing known vulnerabilities.
No Silver Bullets for Open Source Vulnerabilities
Even as open source use has grown, so has vulnerable open source code. Synopsys found that 75% percent of the codebases audited in 2019
contained at least one public vulnerability—a jump from 60% of the codebases audited 2018. On average, Synopsys found 82 vulnerabilities per codebase. Even worse, 4 of the top 10 vulnerabilities found in the 2019
audit did not have CVEs associated with them at the time they were discovered.
The sheer breadth of open source use makes hunting down vulnerabilities one-by-one impossible. “The bad guys make the rules” Tim Mackey, Principal Security Strategist, Synopsys tells the Security Ledger. To secure open source software, Mackey said that firms must change both their security practices and their corporate culture as it relates to security. Neither are easy tasks.
In contrast to commercial software packages, open source software generally doesn’t promote vendor-customer relationships. That means those looking to secure their codebases need to engage with and rely on online communities and message boards.
Even then, the journey to secure open source doesn’t end. Mackey said firms need to employ consistent monitoring of open source components in their applications: identifying publicly known vulnerabilities, replacing out-of-date software and dumping components that cannot be patched.
Building a Software “Bill of Materials”
Mackey says that while there is no one single roadmap to conquering the open source security problem, there are tried and true strategies to securing your codebase.
You can’t solve problems you don’t know exist, which is why Synopsys recommends first and foremost to audit software and develop a software “bill of materials” (BOM). The guiding principle is that once a security team has stock of the software it uses, it can then understand the risks associated with them.
Once a BOM is created, checking codebases against Common Vulnerabilities and Exposures (CVE’s) and other scoring systems gives a yardstick for gauging how at risk open source components might be. However, Synopsys cautions against relying on a single source as they update at different times with different information.
Still, while simple on its face, the practice of building BOMs is not widely adopted, Synopsys found.
(*) Correction: an earlier version of this story described the data used in the report collected from a survey. The report was built from audited codebases from Synopsys’ Black Duck Audit Services customers. Correction issued May 21, 2020.