A software supply chain is every step and component involved before software reaches its users: source code, outside libraries, build tools and the delivery channel. An SBOM (software bill of materials) is a list of the components in a piece of software, like the ingredients on a food label, saying what it contains, which versions and who produced them. This article explains why an SBOM is the basis of software supply chain security, the minimum data it should hold, the CycloneDX and SPDX formats, and the SLSA framework.
Where the software supply chain is exposed
Modern software uses code the team wrote itself for only part of the product. Much of the rest is open-source libraries, vendor components and the tools used to build it. A vulnerability or malicious code hidden in one part follows that part into every product that uses it.
- Outside components: a library may carry a vulnerability or be altered by someone with bad intent.
- The build system: an attacker who reaches the system that builds the software can change its output even when the source code is unchanged.
- Delivery: the file the user receives may not match the file the developer actually built.
- New connection points: outside servers and tools plugged into a system, such as MCP servers, are another kind of outside component. See What Is MCP? Architecture, Security Risks, and Technical Defenses.
What an SBOM is and what it is for
CISA describes an SBOM as a nested inventory. Software consists of components, each component may have subcomponents, and those may have subcomponents of their own. A component can come from the first party, meaning the author of the SBOM, or from a third party.
The clearest benefit comes when a new vulnerability is announced. The organization can search its SBOMs and see at once which software uses the affected component, instead of asking vendors one by one. CISA says this data supports decisions about known and newly discovered vulnerabilities, and can be mapped to security advisories or to the organization's list of approved software.
An SBOM does not solve every software security problem. CISA calls it a necessary step toward risk-informed decisions. Once you know which component is vulnerable, you still need steps to prioritize and fix it; see the vulnerability management program.
The minimum data an SBOM should hold
In 2021 the NTIA (the US agency for telecommunications and information policy) published minimum elements for SBOMs, setting 7 data fields for each component: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp.
On 29 July 2026 CISA, with the NSA, the FBI and partner agencies from many countries, published the 2026 Minimum Elements for a Software Bill of Materials (version 2.1 of the document). It updates and replaces the 2021 NTIA version. A draft appeared on 22 August 2025 and took comments until 3 October 2025. The new version sets 17 data fields, divided into data about the SBOM itself (SBOM Metadata) and data about each component (Component Data). It also adds a set of practices (Practices and Processes).
The list below shows the 10 data fields added since the 2021 version.
- SBOM Author Signature: a digital signature that identifies the author.
- SBOM Data Format Name and Version: for example CycloneDX or SPDX, and the version of that format.
- SBOM Tool Name and Tool Version: the tool used to generate or amend the SBOM.
- SBOM Generation Context: the lifecycle phase in which the SBOM was generated, for example before build or after build.
- SBOM Version: an identifier saying which revision of the SBOM document this is.
- Component Hash Value and Hash Algorithm: a hash is a value computed from a file's contents; if the file changes, the value changes. It is used to check that a file matches what is recorded.
- Component License: the license under which the component is available.
The practices section has 6 elements: coverage, frequency, distribution and delivery, machine-processable data, accommodation of updates to SBOM data, and explicitly identifying unknown information. The CISA document states that it creates no new requirements; it refines how organizations should generate and request SBOMs.
The document applies to SBOMs for all kinds of software, including open source, AI software and SaaS (software delivered as a cloud service). AI software and SaaS may need extra data, which is outside this document's scope. A footnote in the document says CISA and G7 partners issued separate guidance, Software Bill of Materials for AI – Minimum Elements, in May 2026.
SBOM formats: CycloneDX and SPDX
An SBOM has to be stored in a form programs can read, so tools can search and analyze it at scale. Two standard formats are in common use.
- CycloneDX: developed by the OWASP Foundation and Ecma International and published as the ECMA-424 standard, 2nd edition (December 2025), which defines CycloneDX v1.7. It can be stored as JSON, XML or Protocol Buffers (a binary data format) and supports VEX (a statement of whether a published vulnerability actually affects this product).
- SPDX: described on spdx.dev as an international open standard (linked to ISO/IEC 5962:2021). The site shows SPDX 3.0 as the current version, and it does not say which version the ISO standard covers.
Either format can be used. What to check is whether the tools in use produce all the minimum data above, and whether the receiving side's tools can read the format.
SLSA: making built software trustworthy
SLSA (Supply-chain Levels for Software Artifacts) is a set of guidelines that can be adopted step by step to guard against tampering at every stage from source code to delivered file, such as unauthorized code changes, files not built by the expected CI/CD platform, and attacks on the build platform. Producers use it to harden their supply chain, and consumers use it to decide whether to trust a package. According to slsa.dev the current version is 1.2, with a Build Track (levels L1 to L3) and a Source Track (focused on producing and verifying source).
The core of the Build Track is provenance: data that identifies an output file by its hash and describes how it was produced. There are 3 Build levels.
- L1, provenance exists: the build system generates provenance, but authenticity and accuracy are not guaranteed.
- L2, provenance can be authenticated: the recipient can validate the provenance signature, and the build runs on a hosted service rather than a person's machine.
- L3, provenance cannot be forged: each build is isolated and cannot reach the build system's secrets, so users of the build system cannot forge the provenance.
L3 ensures that a well-intentioned build runs securely, but it does not stop a producer from running a risky build. Software that meets no level yet is called SLSA 0.
Using SBOMs and SLSA in an organization
CISA lists three key actions: request SBOMs that meet the updated minimum elements, use tools to generate, ingest and analyze SBOM data, and generate SBOMs that meet the minimum elements. In practice the work splits as follows.
- Software the organization buys or commissions: put an SBOM requirement in contracts and procurement criteria, specify the format and delivery schedule, and check that your tools can read that format.
- Software the organization builds: generate an SBOM from the build pipeline every time a new version is released, and store it with the released file. SCA tools need to know which components the software uses, which is the same kind of data as in an SBOM. See DevSecOps: How to Use SAST, DAST and SCA.
- Storage and search: keep every SBOM in one searchable place so you can search immediately when a new vulnerability appears, then hand the finding to the normal patching process. See Patch Management Best Practice.
Common mistakes
- Assuming an SBOM makes you safe: an SBOM is a list of data, and if nobody compares it with new vulnerabilities it does not reduce risk.
- Generating an SBOM once and never updating it: software changes with every version, so an old SBOM no longer matches what is in use.
- Accepting an SBOM without checking it is complete: some fields, such as producer name or version, are missing or vague, so the component cannot be searched for.
- Counting only open-source libraries: forgetting components vendors embedded, firmware and the SaaS services in use.
- Keeping SBOMs only with the development team: the security team cannot reach them on the day of an incident.
- Using an SBOM instead of protecting the build system: an SBOM says what is inside, not whether it was altered during the build, so SLSA-style practices are needed alongside it.
Start today
- List the important software: start with systems that face the internet or hold sensitive data.
- Ask key vendors for an SBOM: start with a few vendors and see whether the data covers the 17 minimum fields.
- Generate an SBOM for one system you build: use a tool that supports CycloneDX or SPDX and compare the result with the minimum data.
- Search for one component: pick one library and find which systems use it, timing yourself to learn how quickly you can answer.
- Assess the SLSA Build level of your main build pipeline: is it SLSA 0, or L1 to L3?
- Restrict access to the build system: allow only the people who need it, and keep its secrets away from steps ordinary users can edit.
To see how your software and vendor management measures up, try the self-assessment.
Scope and accuracy
The details of the 2026 Minimum Elements come from the full PDF and the CISA announcement page, read on 27 October 2026. The CycloneDX, SPDX and SLSA versions come from each project's official site on the same day. These versions and requirements can change, so check the latest edition before writing them into a contract. The CISA document itself says it is not advice for compliance, regulatory or legal purposes.
References and further reading
- CISA: 2026 Minimum Elements for a Software Bill of Materials: the document's announcement page.
- CISA: 2026 Minimum Elements (PDF): the table of 17 data fields and the practices.
- CISA: SBOM: CISA's SBOM resources.
- NTIA: Minimum Elements for an SBOM (2021): the original 7 minimum elements.
- SLSA: About: what SLSA is and which tracks it has.
- SLSA: Build requirements: the requirements for Build L1 to L3.
- CycloneDX: Specification overview: versions and data formats.
- Ecma International: ECMA-424: CycloneDX as an Ecma standard.
- SPDX: Specifications: SPDX versions and ISO status.