What Is an SBOM and Why Your Company Needs One

An SBOM (Software Bill of Materials) is a complete list of the components an application is built from: libraries, their versions, suppliers, licenses and dependencies. CISA compares it to an ingredients list. A company needs an SBOM to answer within minutes whether it is affected by a new vulnerability, and to require transparency from software vendors.

Why everyone is talking about SBOMs

A modern application almost always includes many open-source components, and most of them get into the build not directly but as transitive dependencies. When a critical vulnerability is found in a popular library, the first question is "do we have it, and where?". Without an SBOM, the answer takes days of manual searching; with an SBOM, it is a query against an inventory.

Log4Shell (CVE-2021-44228) is a telling example: the Log4j library is used in products from many different vendors, and organizations had to find urgently where it was present. For more on this risk, see our article on attacks on the software supply chain.

After supply chain attacks, SBOM requirements started appearing in regulation. US Executive Order 14028, "Improving the Nation's Cybersecurity," signed on May 12, 2021, made software supply chain security a separate section and tasked agencies with defining the minimum elements of an SBOM; in July 2021, NTIA published the report "The Minimum Elements For a Software Bill of Materials." US requirements do not apply directly in Central Asian countries, but international vendors, large customers and banks increasingly ask for SBOMs.

What an SBOM contains

• The name and version of each component
• The supplier or author
• Unique identifiers (purl, CPE) and hashes
• Dependency relationships, including transitive ones
• Licenses

The more complete the data, the more precisely it can be matched against vulnerability databases. An SBOM without versions and identifiers is of little use for automated analysis.

Formats: CycloneDX and SPDX

The two main open standards are CycloneDX and SPDX.

• CycloneDX: developed by the OWASP Foundation and Ecma International; standardized as ECMA-424 (published December 10, 2025). Beyond SBOMs, it describes SaaSBOM and HBOM, and supports JSON, XML and Protobuf formats. Historically focused on security.
• SPDX: a Linux Foundation project and the international standard ISO/IEC 5962:2021. It describes provenance, licenses and security data, and has traditionally been strong in license compliance.

Most tools support both formats, so choose the one your customers ask for and, ideally, be able to produce both.

How to generate an SBOM

Doing it by hand is not an option, because dependencies change with every build. SBOMs are generated automatically in CI/CD by SCA-class tools. For example, Sonatype Lifecycle and SBOM Manager produce an SBOM with every build, match components against vulnerability databases and your company's policies, and store SBOMs for all versions of a product. For an overview of alternatives, see our article comparing SCA solutions.

Practical rules for generation:

• Generate the SBOM at build time, not after the fact from the repository, so it reflects the real versions of the artifacts.
• Keep an SBOM for every release: a vulnerability may be found in a version that has been in production for a long time.
• Check the SBOM against vulnerability databases continuously, not just once, because new CVEs appear after release.

How to use an SBOM for security

1. Responding to new CVEs: instantly find the affected applications.
2. Policies: ban components with critical vulnerabilities or prohibited licenses.
3. Software acceptance: require SBOMs from contractors and vendors.
4. Audit and compliance: evidence of supply chain control.

CISA notes that an SBOM works together with VEX, a statement of whether a specific product is affected by a known vulnerability. This helps filter out vulnerabilities in components that are unreachable in your product, so you do not waste time on empty tickets. An SBOM also combines well with other AppSec tool classes: SCA covers composition, while SAST and DAST cover your own code and application behavior.

SBOM for the frontend

A separate blind spot is client-side JavaScript loaded in the browser from third-party CDNs. A classic SBOM generated at build time does not see it, because the script is attached at runtime. A Frontend SBOM addresses this; for example, DPA FAST Analyzer produces one.

Common mistakes when working with SBOMs

• An SBOM for show. The file was generated once for an audit and then forgotten. An outdated SBOM is more dangerous than none, because it creates a false sense of control.
• Only direct dependencies. Most problems arrive through transitive components, so an SBOM without dependency relationships says little.
• No response process. An inventory by itself does not close vulnerabilities. You need application owners, remediation deadlines and prioritization based on whether the vulnerable code is actually reachable.
• Different formats across teams. If each team generates SBOMs its own way, the data cannot be combined into one picture. Agree on a format and a storage location.
• Ignoring containers and images. Operating system and base image components are also part of the product you ship.

Where to start with SBOMs

There is no need to cover all applications at once. A practical sequence:

1. Choose several critical applications and enable automatic SBOM generation in their builds.
2. Agree on the format (CycloneDX, SPDX or both) and on a storage location accessible to the security team.
3. Connect matching against a vulnerability database and set up notifications for new findings.
4. Define policies: which vulnerabilities and licenses are unacceptable, and who decides on exceptions.
5. Add an SBOM requirement to contracts and to the acceptance process for contractor software.
6. Gradually expand coverage to the remaining applications and container images.

This approach delivers first results quickly without overloading the teams. It fits well into the overall secure development roadmap, and tool choices are easier to validate in a small pilot.

SBOM and the supply chain

An SBOM answers the question "what is inside?", but it does not guarantee that there is no malicious code inside. That is why it is complemented by controls over what gets into the build at all: an artifact repository with component checks, blocking of suspicious packages, and admission policies. Together these measures form supply chain control: you know the product's composition and do not let known-dangerous components in. For organizations that ship software to their own customers, an SBOM also becomes a trust signal: it shows that the product's composition is known and under control.

Who should own the SBOM

Formally, the SBOM is generated automatically, but it still needs an owner. This is usually the security team or the development platform team: they define the format, the storage and the policies, while product teams are responsible for fixing findings in their applications. A clear division of responsibility matters: without it, SBOMs pile up in storage and nobody responds to alerts. It is also worth deciding in advance who receives the SBOM externally, in what form (customers, regulators, partners), and which data in it may be disclosed.

Practical example: what to do when a new CVE appears

Imagine a critical vulnerability is announced in a popular library. Without an SBOM, the team posts questions in development chats, waits for replies, and discovers along the way that some applications are built from outdated instructions. With an SBOM, the process looks different:

1. The security team searches all stored SBOMs for the vulnerable component and version, and gets a list of affected applications and releases.
2. The list is ranked by severity: internet-facing services and systems with sensitive data go first.
3. For each application, it is determined whether the vulnerable code is reachable; the VEX status "affected / not affected" helps here.
4. Owners receive tasks with the version to upgrade to and a remediation deadline.
5. The new build is checked against policy: a component with the vulnerable version no longer passes into a release.

The difference between "searching for several days" and "getting a list in a few minutes" often determines whether you close the vulnerability before attackers do.

Frequently asked questions

Sources

• CISA: Software Bill of Materials (SBOM)
• CycloneDX: Specification Overview
• SPDX: About the specification
• CISA: Apache Log4j Vulnerability Guidance