You know that static analysis can find code quality defects in your proprietary code. But what are you doing to manage your open source code quality risk?
In the invaluable Gartner research paper Technology Insight for Software Composition Analysis, the analyst cites an interesting finding during his examination of the current state of SCA (software composition analysis): “Mature organizations are expanding open-source management to include assessments of the overall ‘health’ of the software, based on a given package’s provenance and support.”
As open source use has gained traction over the years, the focus on managing that open source has also evolved. Organizations that knew they used open source initially concentrated their efforts on open source license identification—a key part of any open source management strategy. As open source use grew in popularity, a risk beyond license risk emerged—identifying and mitigating known vulnerabilities, another critical factor of open source management.
What the Gartner paper refers to as “health” can also be thought of as the state of any given open source component’s code quality and whether that code is being maintained, an emerging risk for organizations using open source destined for embedded or web applications.
Code quality in open source
Developers creating embedded software to control machines or devices that we don’t typically think of as “computers” (such as cars or medical equipment) are usually tightly focused on code quality defects that could cause reliability or functionality issues. Traditionally, that focus has been on the code the developers write, not with quality issues of the open source components they use in their applications. Many development teams use static application security testing (SAST) tools, such as Coverity® SAST, to uncover quality issues in their code. However, SAST isn’t effective in finding third-party open source software vulnerabilities or identifying open source license types or versions—information needed to gauge the overall “health” of any open source component.
One of the reasons behind the popularity of open source components is that viable open source projects usually have (or had) strong communities improving, updating, and patching vulnerability issues as they become known. However, even if a developer takes care to download a component from a robust open source community, there’s no guarantee the community will remain active in maintaining that component. Black Duck Audits conducted in 2018 found that 85% of the 1,200+ codebases scanned contained open source components that were more than four years out of date or had no development activity in the last two years.
Out-of-date open source components are an end user issue as often as they are an open source community issue. Development teams might be reluctant to update because they’re concerned that using a newer version of an open source component will require modifying other code, causing a ripple effect that could bring development to a standstill. Or they worry that on updating, they’ll find the component’s development community has gone cold, meaning they’ll be responsible for fixing any flaws or vulnerabilities that arise in the future.
Both scenarios are antithetical to the reason for using open source in the first place—building better, faster, stronger code.
Getting a complete view of the open source in your codebase with a BOM
How do you know whether you’re using high-quality open source components? Or if you’re using a current version of the software? Is it the most stable? Is there a robust community actively maintaining the component?
Among its conclusions, the Gartner report recommends you “Continuously build a detailed software bill of materials (BOM) for each application providing full visibility into components.”
A complete and useful software bill of materials must include all open source components, the versions used, and the download locations for each project. It also needs to include all dependencies, or the libraries your code calls to, as well the libraries those dependencies link to.
While it’s possible to create a BOM manually, doing so requires a significant investment of time that may affect developer productivity and lead to higher development costs. “A BOM generated by an SCA tool provides more comprehensive information (specific versions, license, etc.),” the Gartner paper notes, “and potentially a more advanced understanding of dependency mapping among various components and frameworks.”
You can find the Gartner research paper Technology Insight for Software Composition Analysis here. It’s an intriguing read that I strongly recommend to anyone interested in better management of the risks of open source use.
Gartner, Technology Insight for Software Composition Analysis, 01 November 2019, Dale Gardner
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, express or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Fred Bals. Read the original post at: https://www.synopsys.com/blogs/software-security/open-source-code-quality-risk/