SBOM Guide: Software Bill of Materials for Security Programmes

What an SBOM Actually Is

An SBOM is a structured, machine-readable list of the components that make up a software artefact. The components are usually open-source or third-party libraries, but an SBOM can also describe internal first-party packages, container layers, operating-system packages, and embedded firmware. Each component entry carries identifying metadata: the name, the version, the supplier or publisher, a unique identifier such as a CPE or a Package URL (purl), one or more cryptographic hashes, the license, and the dependency relationship that links it back to the parent component. Run on the software you ship, an SBOM answers the question, what is actually inside this build, with enough precision for a downstream consumer or auditor to do something with the answer.

The reason SBOM exists as a defined artefact, rather than a generic spreadsheet of dependencies, is that the supply chain is recursive. A first-tier dependency pulls in a second-tier dependency, which pulls in a third-tier dependency, and the vulnerability you actually need to remediate is often six levels deep. An SBOM written to a defined standard is the only durable way for a buyer, an integrator, an SOC, or a regulator to walk the dependency graph quickly and decide whether a newly disclosed CVE applies to the software they are running.

An SBOM is not a security finding list. It does not say which components have known vulnerabilities, what severity those vulnerabilities have, or whether they are exploitable in your specific deployment. An SBOM tells you what is in the build. The vulnerability picture comes from running the SBOM against a vulnerability data source (the National Vulnerability Database, the GitHub Security Advisory database, OSV, vendor advisories) and from layering on a VEX document that asserts which advertised vulnerabilities are actually exploitable in the deployed configuration.

The NTIA SBOM Minimum Elements

The NTIA Minimum Elements for a Software Bill of Materials (published 12 July 2021 in response to U.S. Executive Order 14028) is the reference baseline that every SBOM standard, tool, and procurement clause traces back to. The minimum set is small on purpose. If a buyer asks for an SBOM and you produce a document that meets these elements, you have met the floor.

The CISA SBOM-at-a-Glance and the wider CISA SBOM resources extend the NTIA baseline with deployment, distribution, and consumption guidance, but the data-field set stays very close to the NTIA original. If a procurement clause asks for an SBOM, expect a quiet expectation that your document meets the NTIA minimum elements and is delivered in either SPDX or CycloneDX.

SPDX vs CycloneDX: Which Format to Pick

The two dominant machine-readable SBOM formats are SPDX (Software Package Data Exchange, stewarded by the Linux Foundation and standardised as ISO/IEC 5962) and CycloneDX (stewarded by OWASP). Both formats meet the NTIA minimum elements. Both are widely supported by build-time tools, package managers, and container scanners. Choosing between them is not a moral question; it is a question of which fits your existing tool chain and your buyer's expectation.

A reasonable default for a security-led programme that prioritises vulnerability data and VEX is CycloneDX. A reasonable default for a license-compliance-led programme or a regulated industry that explicitly cites ISO/IEC 5962 is SPDX. Many enterprise programmes generate both for the same artefact and let the consumer pick. The key point is that the format choice is downstream of the data: as long as the underlying generator is producing the NTIA minimum elements correctly, converting between SPDX and CycloneDX is a transformation, not a regeneration.

Where SBOM Sits Next to KEV, EPSS, and CVSS

SBOM by itself is an inventory. It only earns its place in the vulnerability management stack when it is paired with a vulnerability source and the prioritisation signals that turn a list of CVEs into a queue of work. The four signals together form the modern risk-based vulnerability management read.

The SBOM is the entry point. You walk the SBOM, look up each component-version pair in the vulnerability data, get back a list of CVEs, then enrich each CVE with CVSS, EPSS, and KEV. The output is a per-finding queue with severity, likelihood, exploitation evidence, and the supplier responsible for fixing it. That is the queue your VM programme actually works.

Our CVSS scoring explained, EPSS score explained, and CISA KEV catalog operational guide cover each of those signals in detail. The vulnerability prioritisation framework covers how the signals weight against each other in a defensible policy. The SBOM is what gives all four of them something to score.

VEX: When the Advertised Vulnerability Is Not Actually Exploitable

VEX, the Vulnerability Exploitability eXchange, is the document that sits next to the SBOM and asserts, for one or more advertised vulnerabilities, whether they are actually exploitable in the specific software product. VEX is needed because component-level vulnerability data is generous. A CVE that lives in one function inside one optional module of a dependency will be reported against every product that includes the dependency, even when those products never call the affected function.

CISA defines four VEX status values for each (product, vulnerability) pair: not affected, affected, fixed, and under investigation. A not-affected status carries a justification (component not present, vulnerable code not in the execute path, vulnerable code cannot be controlled by adversary, vulnerable code cannot be reached, inline mitigations already exist) so a downstream consumer can audit the assertion.

The CycloneDX VEX format embeds VEX data inside or alongside the SBOM. The OASIS CSAF (Common Security Advisory Framework) profile for VEX expresses VEX in a vendor-style advisory document that consumers ingest the same way they ingest other security advisories. Both formats are interchangeable for the purpose of asserting exploitability. Pick the one that matches your existing advisory pipeline.

Operationally, VEX matters most for vendors shipping software to other organisations. Without VEX, every minor SCA finding in your software produces a customer ticket asking why the product still flags as vulnerable. With VEX, the customer sees an authoritative not-affected assertion alongside the CVE and the queue does not move to their VM team in error. Our dedicated VEX guide covers the four CISA status values, the five not-affected justifications, the CSAF VEX and CycloneDX VEX formats, the producer and consumer workflows, and a four-week rollout in detail.

Generating SBOMs: Build-Time vs Binary Analysis

There are two broad ways to produce an SBOM. Build-time generation, where the SBOM is produced from the build manifest while the artefact is being assembled, gives the most accurate and complete result because the build system knows every package it is installing and at what resolved version. Binary analysis, where the SBOM is produced after the fact by inspecting an already-built binary, container, or installed system, is necessary for software you did not build yourself but is inherently lossy.

The default expectation for first-party software you ship is build-time generation inside CI. The default expectation for third-party software you operate is asking the vendor for the SBOM and supplementing with binary analysis where the vendor does not yet publish one. EO 14028 and the OMB memos that followed it explicitly favour vendor self-attestation plus SBOM, which is the procurement-side push for vendors to ship their own.

Ingesting SBOMs Into the Vulnerability Programme

Generating an SBOM is the easier half. Ingesting one as a buyer (your customer SBOMs, your vendor SBOMs, your upstream open-source SBOMs) and acting on the data is the part where most programmes stall. The ingestion problem has three layers: parsing, scoping, and lifecycle.

The output of ingestion is a per-finding queue tied to the right asset and the right engagement. That queue then runs through the standard VM lifecycle: triage, prioritisation, SLA assignment, remediation, retest, closure. The same queue your scanner-led findings flow through, with the SBOM-derived findings sitting alongside them.

SBOM as Audit Evidence Under EO 14028, NIS2, DORA, and FDA

Multiple regulatory regimes now treat the SBOM as a primary or supporting audit artefact. The exact wording varies, but the operating posture is similar: produce SBOMs for the software you ship, ingest SBOMs for the software you operate, retain history, and be able to demonstrate that an SBOM-derived vulnerability moves through a defensible remediation lifecycle.

Audit evidence sits on the artefacts and on the lifecycle. The SBOM itself is the evidence that the inventory exists; the timestamped chain of regeneration, ingestion, VEX assertions, finding triage, and closure is the evidence that the inventory is being acted on. Both have to be on the record.

Common SBOM Failure Modes

The artefact is straightforward; the operating discipline is where programmes break. These are the failure modes that show up most often in real audit conversations.

1. Generated once, never refreshed. A six-month-old SBOM that bears no relation to the current build tells you nothing about the current risk surface. Treat the SBOM as a build artefact, not a project deliverable.
2. Missing identifiers. An SBOM entry with a package name and version but no purl, no CPE, and no hash cannot be cross-referenced against vulnerability data automatically. Ingestion silently drops these entries.
3. No relationship graph. Without dependency relationships, the SBOM is a flat list and you cannot answer the question, which parent component pulls in this vulnerable transitive dependency.
4. No VEX, so every component-level CVE turns into a ticket. Component-level vulnerability data is broad. Without VEX assertions for the false positives, the SBOM-derived queue floods the VM team and credibility is lost.
5. Vendor SBOMs in formats your toolchain does not support. Some vendors will deliver SBOMs in proprietary formats or in stale standards. Insist on SPDX or CycloneDX in the procurement clause and accept conversions only with provenance preserved.
6. Asset-to-SBOM linkage missing. The SBOM identifies components, not running assets. If the deployment registry does not say which environments run which build, the SBOM cannot drive remediation; it can only describe abstract exposure.
7. SBOMs treated as confidential by default. Some programmes overprotect SBOMs because they assume the document is a roadmap for an attacker. Treat it as the inventory it is. Customers, regulators, and auditors will ask for it; restrict on a need-to-know basis but do not pretend it is a secret.

A Four-Week SBOM Programme Rollout

For an internal team standing up an SBOM programme from a clean start, a four-week rollout gets you to the point where the SBOM is wired into the VM lifecycle and the audit-evidence story holds together.

Four weeks is enough for a clean rollout against a small, well-bounded set of products and a single dominant format. Programmes that try to standardise SBOM across an entire heterogeneous estate in the same window usually slip; pick a beachhead, prove the lifecycle works there, then extend.

Where SBOM Sits in the Wider Security Org

SBOM is a cross-functional artefact. AppSec owns the build-time generation. Vulnerability management owns the ingestion-to-queue side. Product security owns the customer-facing delivery and the VEX assertions. GRC owns the audit-evidence and procurement-clause side. Security engineering owns the platform that runs all of it. CISOs read the programme-level posture from the same record.

Each function reads the same data through a different lens. The dependency that AppSec sees as a CI quality gate is the same dependency that VM tracks as a finding, that product security explains to a customer through VEX, that GRC cites in the audit evidence pack, and that the CISO reads as a top-exposure metric. As long as all five functions read the same record, the SBOM programme stays coherent. The moment those functions read different exports of the same data, the programme starts producing contradictory claims and the audit conversation becomes painful.

• AppSec teams own the SBOM-in-CI side: every build emits an SBOM and every PR review can read the dependency surface it is shipping.
• Vulnerability management teams own the ingestion-to-queue lifecycle and the SLA discipline against SBOM-derived findings.
• Product security teams own the customer-facing SBOM delivery and the VEX assertions that keep customer VM teams from chasing false positives.
• GRC and compliance teams own the procurement clauses, the audit-evidence pack, and the framework mapping under EO 14028, NIS2, DORA, FDA, PCI DSS, ISO 27001, and SOC 2.
• Security engineering teams own the platform that generates, signs, stores, ingests, and serves SBOMs across the programme.
• CISOs read the programme-level SBOM coverage, the top SBOM-derived exposures, and the regeneration cadence as part of the leadership posture, not as a separate report.

SBOM and the Existing SecPortal Stack

SecPortal does not parse SBOM files natively. The product runs SCA against connected repositories using package-manager-native tooling (npm audit, pip-audit, govulncheck) and correlates results against the National Vulnerability Database, which produces the same per-component CVE picture you would get from running an SBOM through an external ingestion tool. For programmes that do operate a separate SBOM pipeline, the SecPortal engagement record carries the SBOM as a stored document, the resulting findings as standard VM lifecycle entries, and the audit evidence on the same activity log that covers scanner-led work.

• Code scanning runs Semgrep SAST plus npm audit, pip-audit, and govulncheck SCA against connected repositories and produces the per-component CVE picture an SBOM-driven scan would produce.
• Repository connections wire GitHub, GitLab, and Bitbucket through OAuth so the same code that produces the SBOM is the code SecPortal runs SCA against.
• Findings management carries each SBOM-derived or SCA-derived finding with CVSS 3.1, persistent identifier, owner, evidence, and remediation status across the lifecycle.
• Document management stores the SBOM file and any VEX document as engagement-attached artefacts under signed-URL retrieval and the standard 50 MB per-file allowlist.
• Continuous monitoring keeps SCA running on a daily, weekly, biweekly, or monthly cadence so the SBOM-aligned picture stays fresh between full SBOM regenerations.
• Activity log captures the timestamped chain of finding state changes, SBOM uploads, document downloads, and team actions that auditors look for as evidence the programme is operating.
• Compliance tracking maps SBOM-derived findings against ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST controls and exports the evidence to CSV.
• AI reports produce the executive summary, technical report, and remediation roadmap views from the same engagement record so leadership reads the SBOM-derived risk alongside everything else.

None of these features parse SBOM files. The SBOM is yours to generate and to ingest. What the platform does is keep the resulting findings, the SBOM document, the lifecycle, the framework mapping, and the leadership read on the same record so the audit conversation collapses into a query rather than a multi-team evidence scramble.

Wider Reading

The SBOM topic intersects with several other parts of the vulnerability management and AppSec programme. The following pages cover the adjacent disciplines from different angles and feed back into the SBOM workflow.

• Vulnerability prioritisation use case for the operational workflow that ranks SBOM-derived findings against scanner-led findings on the same record.
• Vulnerability SLA management for the SLA discipline that turns the SBOM-derived queue into deadlines.
• Vulnerability acceptance and exception management for the deferred-risk side that VEX false positives and structural component constraints feed into.
• Dependency vulnerability triage for the operating workflow that turns SBOM-derived SCA findings into a routed, prioritised, and verified closure on the engagement record.
• DevSecOps scanning for the CI-side pipeline that runs SBOM generation and SCA before merge.
• Security leadership reporting for the cadence that exposes SBOM coverage and SBOM-derived risk to the leadership read.
• Security control drift research for the upstream view of why an SBOM goes stale between regenerations.
• Audit evidence half-life research for the evidence-side analysis of why a stored SBOM stops counting after a defined window.
• SAST vs SCA code scanning for the technical comparison between source-code analysis and dependency analysis inside the same build.
• SLSA framework explained for the build-integrity scaffold that pairs each release SBOM with a signed provenance attestation, so the SBOM proven to belong to a specific build of a specific source.
• Vulnerability management program guide for the wider programme inside which SBOM is one ingestion path.
• ISO 27001, SOC 2, PCI DSS, NIST, and CISA Secure by Design for the framework-side mapping that SBOM-derived evidence flows into. The Secure by Design pledge goal 6 (CVE completeness) reads directly against the SBOM and VEX workflow this guide describes.

Run SBOM-Aligned Vulnerability Management on a Single Record

SBOM is mostly a recordkeeping problem in disguise. The standards are public, the generators are stable, and the format choice is not the bottleneck. What stops most programmes is that the SBOM file lives in one place, the SCA findings live in another, the VEX assertions live in a third, the lifecycle audit trail sits inside a ticketing system, and the framework mapping is in a spreadsheet. Producing the audit evidence pack means reconciling four or five sources at audit time, and producing the leadership read means reconciling them again.

SecPortal is built around a single engagement record where SCA findings, attached SBOM documents, VEX assertions captured as comments or document attachments, finding lifecycle, framework mapping, leadership read, and activity audit trail all sit on the same workspace. The platform does not parse the SBOM file for you. What it does is keep the rest of the programme on one record so the SBOM you ingest somewhere else turns into VM evidence on the engagement record without the multi-tool reconciliation that usually breaks the audit conversation.