Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) documents are mentioned in numerous publications from government entities including the Cybersecurity and Infrastructure Security Agency and the National Telecommunications and Information Administration.
But what information do they actually convey, how do they relate to each other and who produces them and when are key questions for software producers and consumers alike.
The foundation: SBOM
An SBOM provides an overview about all components that constitute a given software product - many of which are typically produced by third party suppliers like open source software projects.
According to the NTIA, minimum data fields for an SBOM include the name of the component supplier, component name and version, other unique identifiers, the relationship between software component and product plus information about the SBOM author and update timestamps.
Vulnerability management
This information is crucial for vulnerability management, which tracks the publication of security advisories for all the software products installed in a given environment, as well as the assessment of their potential impact and their mitigation or remediation.
SBOMs themselves contain no vulnerability information, which is where VEX comes into play: VEX documents make statements about vulnerabilities contained in the components that constitute a given product. They convey critical information about the product, especially whether it is or is not affected by a known vulnerability and what mitigation steps, if any, must be taken.
Obviously, this information is invaluable for vulnerability management, and allows organizations and agencies to prioritize remediation activities, optimize resource allocation and secure their systems more efficiently and effectively. This is very important considering the constant increase of vulnerability disclosures – the number of published Common Vulnerabilities and Exposures (CVEs) will reach 26,000 in 2023 -- and the accelerated pace of exploit development.
Standards and formats
SBOM and VEX information can be represented using different standards and related formats, especially CycloneDX and SPDX, and most tooling supports both.
It is also important to understand that SBOMs are considered stable once a product version has been released to customers or deployed to production, since its components will no longer change. This is only required when an SBOM creation is flawed, such as when the tools used to create it failed to identify components or described them incorrectly.
In contrast, the vulnerability status, remediation actions or impact descriptions in VEX documents is much more dynamic. CISA recommends issuing VEX documents at different stages of the vulnerability analysis, such as when the problem is under investigation, when a vulnerability is disclosed or once the analysis is complete.
Exchanging and tracking
Exchanging and tracking changes to VEX information is covered by CISA’s November 2023 document, When to Issue VEX Information, which outlines several scenarios.
The list of potential VEX producers includes software suppliers, researchers who test for security issues, public or private vulnerability coordinators, and vulnerability detection and management tools. But the CISA has added a catch-all category to cover anyone who coul d potentially issue VEX information, such as regulators or auditors.
As for when VEX information could be issued, the CISA mentions the following common events:
— The discovery of new upstream vulnerabilities;
— When a vulnerability gets significant public attention;
— When a vulnerability gets actively exploited;
— When a VEX statement changes its status, reaffirms a previous status, or when additional information is introduced;
— During coordinated vulnerability disclosures; and
— When required by law.
Common pitfalls
Unfortunately, various technical complications interfere with the establishment of the different relationships between products, components and vulnerabilities.
For one, it can be difficult to establish all the components that constitute a given product. Many tools focus on manifest files that model dependencies between projects and upstream components. However, manifest files fall short of dependencies that are established by other means (cf. phantom dependencies), or when source or binary code is copied into a project’s source code management system. Preliminary experiments show that SBOMs produced by different tools and at different stages of the software development lifecycle differ in the number of reported components.
Another problem is identifying all components and component versions affected by a given vulnerability. This is partly due to the above-mentioned shortcomings, but has also other reasons, such a forks of open source projects, the production of numerous artifacts for a given component version, e.g. for different OS architectures, the renaming of projects or that the affectedness of older, unmaintained versions is oftentimes not checked at all.
And yet another area of potential imprecision and incorrectness relates to the status “not affected”, which states that a given product is not impacted by a given vulnerability, e.g. because the “vulnerable code [is] not in execution path”. Corresponding justification is typically produced through SAST or DAST tools, which can rely on inaccurate program analysis techniques.
SBOM and VEX standards have the potential to make vulnerability management more efficient and effective. Existing formats are supported by the majority of vendors, which is an important step towards interoperability. However, both producers and consumers of SBOM and VEX information must be aware of all the challenges related to software composition and program analysis. The best standards for SBOM and VEX cannot help if wrong or incomplete information is represented.
Henrik Plate, CISSP, is Security Researcher at application security company, Endor Labs.
