A software program invoice of supplies (SBOM) gives transparency into the weather of an built-in software program product. Such transparency is essential to figuring out system vulnerabilities and thus mitigating potential safety dangers. There may be rising curiosity in utilizing SBOMs to assist software program provide chain threat administration. In September 2024 Military leaders signed a memorandum requiring SBOMs for vendor-supplied software program. Extra not too long ago, the Division of Protection (DoD) Chief Data Officer, by means of its Software program Quick Observe Program, is requiring that software program distributors submit their SBOMs, in addition to these from third-party assessors, to allow detection of variances between SBOMs for a similar software program.
Completely different SBOM instruments ought to produce related data for a bit of software program at a given level in its lifecycle, however this isn’t at all times the case. The divergence of SBOMs for particular person items of software program can undermine confidence in these necessary paperwork for software program high quality and safety. This weblog publish outlines our crew’s latest findings on why SBOMs diverge and recommends seven methods to enhance SBOM accuracy.
SBOM Harmonization Plugfest
The SEI’s 2024 SBOM Harmonization Plugfest challenge, sponsored by the Cybersecurity and Infrastructure Safety Company (CISA), aimed to uncover the basis causes of SBOM divergence, similar to imprecise definitions or requirements, how uncertainty is addressed, or different implementation selections. The SEI introduced collectively SBOM device distributors, requirements producers, and others within the SBOM neighborhood to provide pattern SBOMs for evaluation. The not too long ago launched Software program Invoice of Supplies (SBOM) Harmonization Plugfest 2024, on which this publish is predicated, outlines our crew’s findings, evaluation, and proposals to assist SBOM producers generate extra constant and dependable SBOMs.
We requested Plugfest contributors to generate and submit SBOMs based mostly on 9 software program targets chosen as a consultant pattern of varied programming languages as seen in Desk 1 under.
The SEI gained approval from most contributors to make their submissions public. These SBOMs that had been authorized for launch are now out there at SEI’s GitHub website.
Overview and Evaluation of Submitted SBOMs
We acquired 243 SBOMs from 21 Plugfest contributors. To make sure anonymity and to forestall any bias in our evaluation, we anonymized participant names by assigning alphanumeric codes to every. One participant, who was assigned the code Y2, submitted many extra SBOMs (102) than all of the others (Determine 1). Y2 generated and submitted SBOMs in each format their device supported (i.e., supply and binary evaluation in addition to enriched and non-enriched).
Determine 1: SBOMs Submitted per Goal
Evaluation
To make sure an goal evaluation, we first decided analysis standards for our evaluation of the SBOMs. We then decided automated approaches to extract data from the SBOMs to facilitate our improvement of software program instruments for evaluation in addition to our technology of baseline SBOMs, which we used for comparability functions.
Analysis Standards
Assessing the consistency of the minimal parts of the submitted SBOMs was a essential part in figuring out their completeness and accuracy. An inventory of minimal parts specifies the baseline SBOMs ought to meet and facilitates data sharing. The standards we used for minimal parts are these required for documenting a software program product’s main part and its included parts as outlined in CISA’s Framing Software program Part Transparency: Establishing a Widespread Software program Invoice of Supplies (SBOM):
- SBOM Writer Identify
- SBOM Timestamp
- SBOM Sort
- SBOM Major Part
- Part Identify
- Part Model String
- Part Provider Identify
- Part Cryptographic Hash
- Part Distinctive Identifier
- Part Relationships
- Part License
- Part Copyright Holder
Evaluation Instruments
As a result of many submissions, we developed instruments to automate ingesting and processing SBOMs to gather, collate, and export knowledge about them. Members submitted SBOMs in SPDX and CycloneDX codecs in a wide range of encodings together with JSON, XML, and YML.
We wrote code for processing SBOMs utilizing Python inside Jupyter computational notebooks hosted on an SEI inside Bitbucket repository, which additionally contained a duplicate of SBOM Plugfest submissions. We used two main notebooks for analyzing SBOM submissions: one for CycloneDX and one for SPDX. We sought to extract the next from every SBOM:
- data associated to the presence or absence of minimal parts
- details about software program parts, together with their relationships to at least one one other and with the goal software program
In every pocket book, we collected data from every SBOM by doing the next:
- traversing the listing of SBOM submissions, importing JSON SBOM information, and decoding the JSON information in order that knowledge could possibly be extracted
- extracting minimal parts from every SBOM the place the info existed and noting the place knowledge was lacking
- developing a dependency tree based mostly on the dependencies listed in every SBOM (These dependency timber contained details about software program parts and the forms of relationships amongst these parts as listed within the SBOM.)
- collating knowledge from every SBOM into two widespread knowledge constructions: one for data associated to minimal parts and the opposite for part data
We analyzed the info constructions utilizing Python knowledge science packages, or we exported them as comma separated worth (CSV) information for additional evaluation. We used details about the presence or absence of minimal parts to generate abstract statistics for every software program goal and every SBOM sort (supply/construct). We used dependency graph data to investigate the presence/absence of parts and assess the depth of the SBOMs.
Baseline SBOMs
We chosen three outstanding open supply instruments, Syft, Trivy, and Microsoft’s SBOM Instrument, to create baseline SBOMs for every of the 9 software program targets. The baseline SBOMs served as preliminary examples of what we would anticipate to see submitted by Plugfest contributors. The baseline SBOMs additionally allowed us to develop evaluation instruments early within the challenge so we might begin analyzing contributors’ SBOMs as quickly as they had been submitted.
Findings from SBOM Evaluation
The next are notable findings from our analysis on the SBOMs submitted for the Plugfest. These findings, ordered from the trivial to the extra complicated, clarify the forms of variances within the SBOMs in addition to their causes.
- Part quantity, content material, and normalization. We discovered important variance in each the variety of parts and the content material of the minimal required parts in SBOMs from totally different contributors for a similar software program on the similar lifecycle section. Some variance in SBOM content material is as a result of lack of normalization; the identical content material was merely being written in another way (e.g., software program model detailed as v 2.0 or simply 2.0).
- Software program variations. One other trigger for variance in SBOM content material is that some software program specs enable for a variety of doable software program variations, however SBOMs enable solely a single model to be documented for every dependency. This leads to SBOMs having varied variations listed throughout totally different contributors for every goal that allowed model ranges.
- Minimal parts. Some variance in SBOM content material is because of variations in whether or not contributors included minimal parts or not, which can be as a result of considerably synthetic nature of producing SBOMs for a analysis challenge.
- Use instances. SBOMs have numerous use instances, which result in several types of SBOMs. The wide range of doable use instances is a further trigger for the dearth of harmonization throughout SBOMs for a similar goal. If we had specified a use case, contributors could have taken a extra harmonized method to how they generated, enriched, or augmented their SBOMs for that use case.
- Construct and supply SBOMs. Members used totally different approaches to generate their construct and supply SBOMs, which led to variations within the found parts. Some contributors used a container construct course of to generate their construct SBOM, and others constructed a standalone executable for his or her chosen runtime setting utilizing the goal’s language or build-framework-specific course of. Construct SBOMs additionally different based mostly on the setting and gear configurations every participant used. Supply SBOMs seize dependencies declared or inferred from supply code. Some contributors used extra data from exterior areas, such because the artifact repositories referenced by dependencies or the contents of platform toolchain libraries, to deduce extra dependencies.
- Dependency interpretation. A evaluation of submitted explanatory readme information and discussions with contributors indicated some variations within the interpretation of dependency. Some submissions included dependencies of first-party parts that aren’t usually deployed, similar to goal documentation construct instruments, CI/CD pipeline parts, and non-compulsory language bindings.
7 Suggestions for Bettering SBOM High quality
The next suggestions based mostly on our analysis and evaluation will enhance the standard of SBOMs and assist guarantee constant content material in SBOMs for a similar goal.
-
Emphasize inclusion of the next minimal parts:-
SBOM Sort.
Embody the SBOM Sort to doc the lifecycle section for which this SBOM was generated (e.g., Supply, Construct). We advocate that this attribute be required quite than non-compulsory. -
Part Model String.
Emphasize the significance of reporting the model precisely as supplied by the provider. This reporting minimizes the necessity for normalization as a result of knowledge being inconsistently reported (e.g., one SBOM studies
v 2.0
and one other studies
2.0
). -
Part Provider Identify.
Embody the title of the entity that supplied the contents of the software program being described. This helps customers of the SBOM perceive which third events had been a part of the availability chain. A typical registry of part suppliers would assist normalize this entry. For open supply software program parts, which should not have a conventional provider, a direct reference or hyperlink to the challenge repository needs to be supplied. -
Part Cryptographic Hash.
SBOM steering ought to clearly state what parts are being hashed when a cryptographic hash is included. Make it extra simple for SBOM customers to know the right way to confirm the hash worth. Alternatively, when supplying cryptographic hashes, SBOM creators needs to be express about what was hashed. -
Part License.
Emphasize the necessity to present licensing data or to notice that the license data will not be recognized or was not included.
-
-
Enhance normalization of SBOM parts.
A lot divergence in SBOMs is because of lack of normalization (e.g., model numbering as talked about earlier or
date/time
which can be written as 2025-06-15 or just as August 2025). Standardize on utilizing the time period
provider
for a
main provider
and the time period
producer
for a
secondary provider
. -
Doc how the time period
dependencies
is interpreted within the SBOM technology course of.
Develop steering to tell apart dependencies by class (e.g., runtime, assessments, docs). -
SBOM turbines ought to doc their method to producing SBOMs.
This may assist customers higher perceive potential variations in SBOMs for a similar software program. Additionally doc the use case for which the SBOM is being generated. Completely different use instances could require variations in SBOMs. -
Use the suitable device for the setting.
SBOM creators and customers ought to guarantee they’re utilizing an acceptable SBOM device for his or her particular setting. SBOM instruments usually deal with a subset of the programming languages and construct environments. -
Assist developer neighborhood SBOM efforts.
Some developer communities are working to incorporate SBOM turbines in language instruments and construct frameworks to make it a lot simpler for initiatives utilizing these languages and frameworks to generate SBOMs as upstream suppliers. These efforts have an outsize affect as a result of they decrease the barrier for creating SBOMs and push the SBOM technology additional upstream to challenge maintainers who’ve detailed information of their very own supply code and construct processes. -
Develop and validate SBOM profiles.
To assist stakeholders talk extra successfully, they may develop and validate SBOM profiles, every profile being a well-defined restriction positioned on a number of SBOM requirements to make clear that means and allowable values for every subject, its cardinality, and structural points. The
OWASP Software program Part Verifications Commonplace (SCVS) BOM Maturity Mannequin
profiles characteristic is an instance. One other method could be to outline a JSON schema that extends the prevailing schemas for CycloneDX and/or SPDX and provides the mandatory clarifications and restrictions for a profile.
Future Work on Guaranteeing SBOM High quality
SBOMs are of rising significance to safeguarding the safety of all software program programs, together with DoD and important infrastructure programs. As extra organizations require use of SBOMs, there will likely be better want to make sure their high quality and completeness, together with offering transparency for undeclared dependencies. Choices to maintain SBOM parts opaque could also be rethought if third occasion SBOMs can present wanted transparency. This analysis challenge is a part of a seamless SEI effort to enhance the standard of SBOMs.