A Software Bill of Materials (SBOM) is a structured inventory of the software components, libraries, modules, and dependencies contained in a software product. It provides information about what software is built from, helping organizations identify third-party and open-source components that may introduce security, licensing, or supply chain risks.
SBOMs have become increasingly important in federal cybersecurity and software acquisition. Executive Order 14028, issued in 2021, directed the federal government to strengthen software supply chain security and specifically addressed providing purchasers with an SBOM for software products. Since then, agencies including CISA and NIST have developed additional guidance around software component transparency, secure software development, and supply chain risk management.
What Information Does an SBOM Contain?
Modern software products rarely consist entirely of code developed by a single vendor. Applications frequently incorporate open-source libraries, commercial components, frameworks, packages, and dependencies maintained by other organizations. Those components may themselves depend on additional software.
An SBOM creates a structured record of these relationships. Rather than requiring a customer to treat an application as a single opaque product, the inventory provides visibility into the components used to build it.
Common SBOM information can include:
- software component name;
- component version;
- component supplier or author;
- unique identifiers for components;
- dependency relationships;
- SBOM author;
- timestamp showing when the SBOM was created or assembled.
The exact information depends on the SBOM standard, organizational requirements, and the software being documented. CISA’s work on SBOM minimum elements has focused on three broad areas: data fields, automation support, and practices and processes. The objective is not merely to produce a list of component names, but to create information that can be reliably exchanged and used by software producers and consumers.
Dependency information is particularly valuable. Suppose an application does not directly contain a vulnerable library but depends on another package that incorporates that library. An inventory limited to top-level components may not reveal the complete exposure. A more detailed SBOM can document relationships among direct and transitive dependencies and make this type of analysis easier.
An SBOM is also associated with a particular software product or release. Software changes over time as developers update packages, replace libraries, remove components, or introduce new dependencies. An SBOM that accurately described version 3.0 of an application may no longer accurately represent version 4.0.
Why SBOMs Matter for Software Supply Chain Security
One of the primary uses of an SBOM is vulnerability management. When a vulnerability is discovered in a widely used software component, organizations need to determine whether that component exists within the products they develop, operate, or purchase.
Without component-level information, this can require extensive manual investigation. With an accurate SBOM, a software producer or customer can search inventories for the affected component and determine which products require further analysis.
The process can be summarized as follows:
- A vulnerability is identified in a software component.
- The organization identifies the affected component and relevant versions.
- SBOM data is searched for products containing that component.
- Dependency relationships and actual exposure are evaluated.
- Affected software is prioritized for remediation, mitigation, or vendor action.
- Updated components and product releases are documented in subsequent SBOMs.
An SBOM does not determine by itself whether a product is vulnerable. The presence of a component associated with a known vulnerability does not always mean that the vulnerable functionality is reachable or exploitable in the specific application. Configuration, implementation, operating environment, and other technical factors can affect actual risk.
This distinction is important in federal cybersecurity. An SBOM provides evidence about software composition, while vulnerability analysis determines what that composition means for a particular system. Treating every component match as proof of an exploitable vulnerability can generate unnecessary remediation work, while ignoring component information can leave significant risks unidentified.
SBOMs can also support incident response. When a new vulnerability affects a common library, agencies and contractors with reliable software inventories can identify potentially affected products more quickly than organizations that must first determine what components their applications contain.
Common SBOM Formats and Standards
An SBOM is a type of information rather than a single proprietary file format. Several machine-readable standards can be used to represent software component inventories and relationships. Automation is important because large applications can contain hundreds or thousands of components, making manual inventories difficult to maintain and analyze.
Two widely used SBOM formats are SPDX and CycloneDX.
| Format | Developed or Maintained By | Primary Focus |
|---|---|---|
| SPDX | Linux Foundation | Software component, licensing, security, and supply chain information |
| CycloneDX | OWASP Foundation | Software supply chain and component analysis, including SBOM use cases |
SPDX, or Software Package Data Exchange, originated as a standard for communicating software package and licensing information and has developed into a broader software supply chain standard. SPDX became an international standard, ISO/IEC 5962, in 2021.
CycloneDX was designed as a lightweight standard for software supply chain use cases and supports component, dependency, vulnerability, and related information. It is widely used by software development and application security tools.
Machine-readable formats provide several advantages over static spreadsheets or manually prepared component lists. Security tools can ingest SBOM files, compare components against vulnerability information, identify dependencies, and integrate software composition data into development and security workflows.
The format alone, however, does not determine SBOM quality. A technically valid SBOM may still be incomplete if important dependencies are missing or component versions are incorrect. Federal buyers and contractors should therefore consider the completeness, accuracy, and currency of the underlying data as well as the format used to exchange it.
SBOMs in Federal Software Acquisition
Federal attention to SBOMs increased substantially following Executive Order 14028, Improving the Nation’s Cybersecurity. Section 4 directed federal agencies to improve software supply chain security and called for guidance concerning practices including providing purchasers with an SBOM for each product directly or by publishing it on a public website.
NIST subsequently published guidance addressing secure software development and software supply chain practices. CISA has also worked with government, industry, and other stakeholders on SBOM implementation, minimum elements, sharing, and related software transparency issues.
For federal contractors, an important point is that SBOM requirements should be determined from the specific solicitation, contract, agency policy, and software involved. The existence of federal SBOM initiatives does not mean that every contractor selling any software product to the government automatically has an identical SBOM submission requirement.
When an agency requires an SBOM, procurement documentation may address matters such as:
- which software products require an SBOM;
- what components and dependencies must be documented;
- the required SBOM format;
- how and when the SBOM must be delivered;
- whether updated SBOMs are required after software changes;
- how the government may access or use the information.
This information can influence proposal preparation. A software vendor that relies on hundreds of open-source dependencies cannot necessarily create a reliable component inventory at the end of the acquisition process without understanding its build environment. Effective SBOM generation is usually connected to software development and release management rather than treated solely as contract paperwork.
Federal buyers can use SBOM information as one input into software supply chain risk management. For example, component visibility can support vulnerability analysis, software asset management, incident response, and discussions with vendors about remediation.
SBOMs should not be confused with secure software development attestations. An SBOM describes software composition. An attestation addresses specified development practices or other requirements. Both can contribute to software supply chain assurance, but they provide different types of information.
Creating and Maintaining an Accurate SBOM
The usefulness of an SBOM depends heavily on its accuracy and currency. Software composition changes whenever developers add, remove, or update dependencies. A static inventory created once during an initial federal proposal can quickly become outdated if the product continues to evolve.
For this reason, mature software organizations increasingly integrate SBOM generation into development and release processes. Tools can analyze package managers, source repositories, build systems, container images, and compiled applications to identify components and generate structured SBOM data.
A practical SBOM management process should address several issues:
- determine which software releases require an SBOM;
- identify direct and relevant transitive dependencies;
- use consistent component names and identifiers;
- record accurate version information;
- generate updated inventories when software composition changes;
- retain previous SBOMs when historical release information is needed;
- establish procedures for responding when vulnerabilities affect listed components.
Organizations should also consider how SBOMs are distributed. Some component information may be provided directly to customers, while other SBOMs may be made available through repositories, portals, or other mechanisms established by the software producer or purchaser.
Accuracy is more important than simply producing a large file. Duplicate components, missing versions, unresolved dependencies, or incorrect package identifiers can make automated vulnerability matching less reliable. Contractors should therefore treat SBOM generation as part of software configuration and supply chain management.
The same principle applies when contractors integrate third-party software into a larger solution. An SBOM received from an upstream supplier can improve visibility, but the contractor may still need to understand how that software fits into its own product and whether additional dependencies are introduced during integration.
What GSA Contractors Should Know About SBOMs
SBOMs are most relevant to GSA contractors that develop, provide, integrate, or manage software and software-enabled solutions. This can include commercial software publishers, SaaS providers, cybersecurity companies, system integrators, cloud solution providers, and contractors delivering applications developed specifically for federal customers.
A GSA Schedule contract does not create one universal SBOM requirement for every software product and every order. Contractors need to review the requirements of the applicable solicitation, contract modification, RFQ, or agency order to determine what software supply chain information must be provided.
When an SBOM is required, contractors should verify that the document corresponds to the software version actually being offered or delivered. Reusing an inventory from an earlier release without checking subsequent component changes can provide the government with inaccurate supply chain information.
Contractors should also understand what an SBOM does not establish. It does not certify that software is secure, prove that a product contains no vulnerabilities, demonstrate compliance with every federal cybersecurity requirement, or replace secure development practices. Instead, it provides structured transparency into software composition that can support those broader security activities.
For federal acquisition purposes, this distinction makes the SBOM particularly useful. Government buyers cannot effectively assess every line of code in every commercial software product they purchase. Component-level visibility gives agencies and contractors a more practical way to understand dependencies and respond when software supply chain risks emerge.
For software vendors working in the GSA and broader federal marketplace, SBOM readiness is therefore increasingly part of effective software supply chain management. Knowing what components are present, where they came from, which versions are deployed, and how quickly that information can be updated gives contractors a stronger foundation for responding to federal cybersecurity requirements and newly discovered vulnerabilities.
