Detangling SBOM, CVE, and Regulatory Mandates

Software bills of materials (SBOMs) and Common Vulnerabilities and Exposures (CVEs) are not new concepts to software developers, and the two are not inherently related. But because both are now included in governmental regulations, their use is under greater scrutiny, and development teams must ensure that their practices meet the regulatory mandates. That is not always an easy project to tackle.

However, the call for both SBOMs and CVEs is causing developers to conflate the two — and doing so introduces problems.

CVEs Are Dynamic 

CVEs are entries in a publicly disclosed catalog of information security vulnerabilities; security professionals coordinate efforts to prioritize and address those vulnerabilities.

The CVE program serves as a universal dictionary. A unique identifier such as “CVE-2017-5754” refers to a specific, well-documented vulnerability and helps track progress and (ideally) mitigation. Each record includes a description of the vulnerability, information on affected package versions, a severity score, and, optionally, a list of known affected products. Software specialists regularly monitor CVE reports to learn about vulnerability status and patches.

Importantly, CVEs are ephemeral. They capture a vulnerability at a particular moment in time. The CVE may be addressed, with patches issued to protect relevant systems, but sometimes CVEs are reopened. That can happen when a CVE patch is later found to not fully solve the issue.

We might wish to think that a closed CVE is static, but it’s like plumbing repairs: The weakness is fixed for now.

SBOMs Are an Inventory List

An SBOM is a machine-readable inventory of software components included in a software product. It can be relevant to stand-alone software or to software delivered in an intelligent device. An SBOM can be used for different activities, such as mapping software to licenses, tracking dependencies between software packages, or disclosing how the software was assembled. 

In recent years, SBOMs have become important (and sometimes mandatory) as a way to track software packages to vulnerabilities.

There are recommendations about the elements that should be included in an SBOM, but granularity is often not defined. Everyone makes independent choices about what to include at which level of detail (e.g., component, file, or binary level) or lifecycle phase (such as build or runtime). For instance, if the software delivery is a Linux image with kernel and user packages, the first level in the SBOM is the Linux distribution version. The next level is the kernel and packages within the distribution and their versions. You might need to list the source files used to compile the package, or even the compiler, and the compiler flags used to build packages. At the extreme, the SBOM includes the files used to compile the compiler.

SBOM vs. CVE

An SBOM is static by nature. It includes information about what a particular set of software deliverables includes. The SBOM lists all software components with an identifiable version number to ensure tracking. The content does not change until there is a new delivery or upgrade. Therefore, each product release comes with a static SBOM that is valid forever — or is supposed to be. 

On the other hand, the CVE process is dynamic. CVE records are unpredictable, as they are uncovered at various stages in a software component’s lifecycle. It is crucial to properly track and categorize them in a comprehensive database to prevent cybersecurity attacks.

A CVE is marked as “fixed” when a remedy is available that has been successfully validated. Still, it is not certain that any given CVE will remain in the same state. It is not uncommon for a CVE record to become “vulnerable” again when new evidence concludes that the applied fix did not resolve it or triggers a new vulnerability scenario for the same component.

It is tempting to include CVE references in an SBOM because, after all, that is what is in the inventory today — but adding dynamic content makes the entire SBOM dynamic. The end user can no longer trust that they have a correct, up-to-date version, so they don’t know what is actually in the bill of materials. That obviates the entire point of the exercise.

What Compliance Looks Like

Practically speaking, organizations must create an SBOM with every new software release. 

If an upstream component has a known vulnerability, as reported in an CVE, you must assure that the security weakness is managed and addressed. In commercial software, at least, that includes monitoring, assessing, and notifying commercial customers about a given vulnerability. Vendors need to deliver the fix in a timely manner, particularly in response to service level agreements (SLAs) with hard deadlines. Patches need to be backported to older software versions, validated, and then deployed in the field.

You can certainly create these assets manually. The elements in an SBOM are spelled out in this Wind River document.

The other option for managing SBOMs and CVEs is to work with domain experts. 

• Wind River Linux enables automated SBOM generation in the Software Package Data Exchange (SPDX) format for Yocto-based projects during the build process. The tool captures detailed information about software components, including their relationships, and licensing data. The user can define what level of information to include, depending on the end use case.
• Wind River monitors all CVEs and performs CVE mitigations to Wind River Linux. The fixes are packaged and delivered in a timely manner in update releases in a fixed release cadence. 

We’d love to consult with you as you contemplate your path forward. Contact us to learn more, especially regarding commercial deployments of Linux in embedded and edge use cases. 

By Tomas Holmberg, Product Line Manager