Code quality and maintenance: Emerging risks of open source use

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 2021 found that 85% of the 2,400+ codebases scanned contained open source components that were more than four years out of date. Eighty-eight percent contained components that had no new development 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.”