Gartner’s recent report Technology Insight for Software Composition Analysis, makes four open-source security recommendations that companies should think about when determining what type of software composition analysis program they want to have. From the need for a software bill of materials, to the importance of a hardened software supply chain to the crucial role OSS licensing plays, the report provides guidance on how to address the inherent risk of open source components - something we’ve been focused on at Sonatype since our founding.Gartner’s fourth, and final recommendation, emphasizes understanding the overall “health” of software packages, by provenance and support. Gartner reports that mature organizations are expanding open-source management to include health assessment by default. They write:
Go beyond questions of security vulnerabilities and licensing when evaluating tools to determine a product’s ability to report on the overall health and welfare of a given software package.
Open Source Repositories Are an Appealing Target
“Attackers are targeting open-source repositories with malware to infect organizations earlier in the software supply chain,” Gartner writes, summarizing a growing risk we’ve been following for over two years.
As we wrote earlier this year:
This new form of attack on our software supply chains, where OSS project credentials are compromised and malicious code is intentionally injected into open source libraries, allows hackers to poison the well. The vulnerable code is then downloaded repeatedly by millions of software developers who unwittingly pollute their applications to the direct benefit of bad actors.
Software composition analysis (SCA) tools are crucial in defense of open source repository attacks. SCA tools establish a baseline of security and compliance within the code. Ideally, the SCA tools work in conjunction with static application security testing (SAST) or an interactive application security testing (IAST) tools, enabling visibility into control and data flow within the application.
“[C]omprehensive visibility into the open-source and commercial components and frameworks used in an application or service must be considered a mandatory requirement,” Gartner writes, emphasis added.
“Poor Health” is a Proven Risk
What constitutes the “health” of an open source project or specific component? Gartner says the measurement is “somewhat subjective”:
Finally, more sophisticated and mature organizations have begun to demand information regarding the overall “health” or reliability of an open-source package. This is a somewhat subjective judgment. It is based on such factors as the number of contributors, the frequency of updates, how rapidly reported vulnerabilities are remediated (or not), and whether those vulnerabilities and any remediation are publicly reported. Packages with few contributors, where responsibility for maintaining the package has changed (which requires an extended period in which to resolve reported issues, etc.), may pose an increased level of risk.
We respectfully disagree. We can measure health.
The health question was central to our work with research partners Gene Kim from IT Revolution, and Dr. Stephen Magill from Galois this year. The culminating research, the 2019 State of the Software Supply Chain report, found a direct correlation between development team behavior and security. Across 36,000 projects, we were able objectively examine and empirically document release patterns and cybersecurity hygiene practices across teams. Those with excellent health metrics, deemed Exemplars, enjoyed many advantages.
Exemplar open source projects are a small, elite group. They comprise just 3% of the studied projects. Yet, the outcomes from their good hygiene practices are visible in our research, including:
- 18x faster at updating dependencies
- 6.8x better at releasing components where all dependencies are up to date
- 3.4x faster at remediating vulnerabilities
- 6x more popular
- 2x more frequent with their component releases
- 33% larger development team size
- 4x more likely to be managed by open source foundations than by commercial stewards
Proactively Addressing Against Malicious Attacks and the Dot Zero Conundrum
Using SCA tools and encouraging healthy development practices are just the beginning. With malicious code entering open source projects at the source -- inserting mal intent prior to the development lifecycle -- defense demands a new approach. Automation tools must become smarter.
The Sonatype platform is addressing this reality by developing additional methods to identify destructive intent as well as behavior. As Brian Fox, Sonatype CTO and co-founder explains:
Sonatype is combining a new type of behavioral analysis with machine learning and proprietary data to give our customers an indication or early warning sign, when a new release of an open source project demonstrates heightened risk attributes. Think of it as Minority Report meets precise, curated data. Our goal is to give customers a holistic view of the security of a release so they can make an informed choice about how to proceed and whether the risk they’re taking is an acceptable one. We want to give them data in context.
Brian further noted
At Sonatype, we believe you need precise data and metadata in context in order to decide whether to accept a release, no crystal ball needed.
In addition to identifying malicious activity based on commit behavior, Sonatype’s expanded Nexus Intelligence capabilities also collect real-time metadata pertaining to the quality of new component version releases. This provides another layer of insight into the integrity of every new version of a component and enables developers to automate and scale dependency management with greater piece of mind.
Anyone looking at SCA should ensure ongoing software security by adopting proactive health practices. Governance of SBOMs and OSS licenses, coupled with supply chain resilience and understanding open source projects with exemplar hygiene habits, are the keys to resistant, healthy software.