An SBOM report, short for Software Bill of Materials, is a structured inventory of every component in a software application, including:
For DevSecOps teams, security engineers, and compliance officers, an SBOM report is the foundation of software supply chain visibility.
This article covers what a complete SBOM report needs to include, which format to use and when, and how to turn a static inventory into an active part of your vulnerability management and compliance workflow.
An SBOM report is a formal, machine-readable document that lists every component your software depends on, including first-party code, open-source libraries, and third-party packages, along with the metadata needed to identify, track, and assess each one.
The concept borrows from manufacturing, where a bill of materials lists every part in a physical product. In software, the equivalent is a complete dependency graph: what’s in the application, where it came from, what version is running, and what license governs its use.
But there’s a real difference between an SBOM that exists and one that’s operationally useful.
Many organizations produce SBOMs as a compliance checkbox, as a file that validates against a schema and satisfies an audit request. That’s not the same as an SBOM that’s integrated into your build process, kept current with every release, and actively used for vulnerability tracking.
The gap between those two states is where most software supply chain risk actually lives.
A practical SBOM report needs a set of core fields for each component. Missing or placeholder values in any of them weakens the report’s usefulness.
| Field | What it captures |
| Component name | The name of each library, package, or module in the application |
| Version number | The exact version running, not a range or “latest.” |
| Supplier information | The organization or maintainer that produced the component |
| Unique identifiers | Standard identifiers such as PURL, CPE, or other package references that make components easier to track across tools |
| Dependency relationships | How components relate to each other, including direct and transitive dependencies |
| Licensing data | The license governing each component’s use |
| Timestamps / SBOM metadata | When the SBOM was generated and the metadata needed to understand its provenance |
Version numbers and dependency relationships matter more than the rest.
An SBOM that lists component names without pinned versions tells you almost nothing about your actual exposure. The same library, at two different versions can have entirely different vulnerability profiles.
Transitive dependencies, or the dependencies of your dependencies, are where most real-world supply chain risk hides. A complete SBOM surfaces both.
Following SBOM best practices means treating these fields as required, not optional.
Two formats dominate SBOM generation: CycloneDX and SPDX. They’re not interchangeable as each has a distinct origin, a primary use case, and a different set of tooling built around it.
CycloneDX is an open-source SBOM standard developed by OWASP and built specifically for application security and software supply chain risk management.
It also has strong support for VEX (Vulnerability Exploitability eXchange) workflows, which let you record not only which vulnerabilities exist in your components but also whether they’re exploitable in your specific application context.
If your primary audience is a security team, or if your regulatory context demands documented vulnerability analysis alongside inventory, CycloneDX is often the right pick.
SPDX (Software Package Data Exchange) is an ISO/IEC 5962-standardized SBOM format maintained by the Linux Foundation. It originated in license compliance and has been around longer than CycloneDX, which means it has a long track record and broad adoption across the software supply chain.
It’s often the format of choice when the primary audience is a legal or procurement team reviewing license obligations before a software acquisition or vendor assessment.
In practice, many teams benefit from generating both, depending on the context.
Security reviews and vulnerability disclosure workflows often call for CycloneDX. License audits and supplier assessments often call for SPDX. The format question is worth resolving early, ideally when you’re setting up SBOM standards for your organization, because retrofitting format support into existing pipelines is more work than building it in from the start.
| CycloneDX | SPDX | |
| Primary focus | Security and vulnerability tracking | License compliance and software supply chain documentation |
| Maintained by | OWASP | Linux Foundation (ISO/IEC 5962) |
| VEX support | Strong | More limited for VEX-centric workflows |
| Best for | Security teams, regulatory vulnerability disclosure | Legal/procurement teams, license audits |
| Output formats | JSON, XML, Protocol Buffers | Tag-value, RDF/XML, JSON, YAML |
Generating an SBOM is the easy part. The harder part is keeping it current and feeding it into your actual security workflow, not just letting it sit in a repository.
An SBOM report becomes a vulnerability management tool the moment you cross-reference its component inventory against known vulnerability databases and CVE records.
Every component with a pinned version can be checked against published vulnerability data, giving you a real-time picture of which parts of your application are exposed and how severely. Without that cross-referencing step, an SBOM is an inventory, not an intelligence tool.
The most common failure mode for SBOM programs is stale data. An SBOM generated at initial release and never updated doesn’t reflect the dependencies you added in the last three sprints, the library you upgraded two weeks ago, or the transitive dependency that quietly introduced a new vulnerability.
Automating SBOM generation as part of your CI/CD integration means every build can produce a current, accurate inventory without anyone having to remember to run it.
That’s what turns an SBOM from a point-in-time snapshot into a living asset. The right SBOM tools make that automation straightforward to implement.
SBOMs have moved from a security best practice to a common procurement, risk management, and regulatory expectation across several frameworks. If you’re operating in any of these contexts, SBOM generation is becoming harder to treat as optional.
SBOMs matter because modern software relies heavily on open-source and third-party components, and high-profile attacks like SolarWinds highlighted how invisible dependencies can create real, exploitable risk. Regulators and enterprise buyers responded by demanding more transparency into what ships inside software products.
Federal software supply chain guidance raised the profile of SBOMs in U.S. government procurement, and agencies may request or contractually require current SBOMs depending on the acquisition and risk context.
FDA cybersecurity guidance has also made SBOMs an expected part of many cyber device and medical device software submissions, where software transparency is relevant to review.
PCI DSS 4.0 strengthens requirements around software inventory, bespoke and custom software, and third-party components, which makes SBOMs useful evidence even though the standard does not explicitly require a formal SBOM.
| Regulation/framework | Scope | SBOM relevance |
| Federal software procurement guidance | U.S. federal government software suppliers | SBOMs may be requested or contractually required, depending on agency needs |
| FDA premarket cybersecurity guidance | Cyber devices and relevant medical device software submissions | SBOMs are often expected as part of software transparency documentation |
| PCI DSS 4.0 | Organizations handling payment card data | Inventory and component tracking requirements that SBOMs can help support |
The trend is clear: SBOMs are becoming a standard expectation across regulated industries and security-conscious procurement environments. Building the capability now, before a customer or mandate forces the issue, puts you in a stronger position than scrambling to produce documentation retroactively.
Generating an SBOM once is a solved problem. Generating one that’s accurate, up to date, and integrated into your existing security workflow is where most teams need support, and that’s what Kiuwan Insights helps with.
Software composition analysis (SCA) is the process of identifying all open-source and third-party components in a codebase, mapping their licenses, and flagging known vulnerabilities. SCA tools often generate SBOMs as a core output.
Kiuwan Insights is a software composition analysis platform that can generate and export SBOMs as part of existing SCA and CI/CD workflows. Rather than relying on a manual scan at the point of release, teams can use it to keep SBOM data aligned with the actual state of the codebase. That reduces the most common failure mode: the SBOM that exists on paper but hasn’t been updated since the initial scan.
Here’s what Kiuwan Insights delivers for teams managing SBOM reporting and software supply chain compliance:
For development teams, security engineers, and compliance officers who need SBOM reporting that holds up under scrutiny, Kiuwan Insights turns a compliance requirement into a security asset.Try Kiuwan for free to see how it integrates with your existing pipeline.
