SBOM vs SCA: How the Inventory and the Analysis Fit Together

Teams buy a software composition analysis (SCA) tool, export its component list, call it an SBOM and assume both the regulatory box and the vulnerability problem are solved, when an SBOM and SCA answer different questions for different audiences. A software bill of materials is an artefact: a formal, machine-readable record of the components and supply chain relationships in a piece of software. SCA is a process and a class of tools that identifies components and continuously analyses them for vulnerabilities, malicious packages and licence risk. One produces evidence you can hand to a customer or regulator; the other produces findings you act on. This guide compares them on purpose, generation accuracy, exchange, regulation (the EU Cyber Resilience Act and US Executive Order 14028 and its follow-on policy), threat model and failure modes, then shows how to operate both from one pipeline. It is for product security, application security and supply chain leads. SCA mechanics are covered in the Software Composition Analysis (SCA) Guide and SBOM formats in the SBOM Guide; this page focuses on how the two relate.

Key takeaways

• An SBOM is a document, SCA is an activity. EO 14028 defines the SBOM as a formal record of components and their supply chain relationships; SCA is what you do with that record (or with your source and binaries) every day.
• SCA tools are one way to generate an SBOM, not the only one. CISA's SBOM types document says Source SBOMs are typically generated with SCA tools, while Build, Analysed, Deployed and Runtime SBOMs come from build systems, binary analysis and instrumentation, each with different blind spots.
• Keep vulnerability data out of the SBOM you ship. The NTIA minimum elements recommend tracking vulnerability data in separate structures because the component list is largely fixed while vulnerability knowledge changes daily; use VEX for exploitability statements.
• Regulation asks for the artefact and the process. CRA Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components, including an SBOM covering at least top-level dependencies, from 11 December 2027.
• Consumers need SCA too. A supplier's SBOM is only useful if you continuously match it against vulnerability and malware data, which is SCA run on someone else's inventory.

The short answer

If you produce software, you need SCA in development to find and fix risky dependencies before release, and you need an SBOM per release as a durable record to share with customers and regulators. If you consume software, you need SBOMs from suppliers (or Analysed SBOMs you generate from their binaries) and an SCA or SBOM analysis platform that keeps checking those inventories against new advisories. Neither replaces the other: an SBOM with no analysis is a filing exercise, and SCA with no exported SBOM leaves you unable to prove to anyone else what you shipped.

"Does SCA generate an SBOM?" Usually yes, and most SCA tools export SPDX or CycloneDX. "Can you have an SBOM without SCA?" Also yes: build plugins, package managers and container tooling can emit SBOMs directly, and a supplier's SBOM can arrive with no SCA involved on your side. The useful question is whether the SBOM is accurate enough for the decisions it supports.

What each one is

SBOM: the inventory document

EO 14028 (signed 12 May 2021) section 10(j) defines an SBOM as "a formal record containing the details and supply chain relationships of various components used in building software". The NTIA minimum elements report (12 July 2021) sets seven baseline data fields (supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data, timestamp), three automation formats (SPDX, CycloneDX, SWID tags) and six practices: frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes. SPDX 3.0 (ISO/IEC 5962:2021 covers the 2.x line) and CycloneDX 1.7 (released October 2025, standardised as ECMA-424) are the formats in common use. An SBOM is versioned with the release it describes.

SCA: the analysis process

SCA tools resolve the dependency tree of source repositories, build outputs or images, assign identifiers (package URLs, CPEs, hashes), then match those against vulnerability databases, malicious package feeds and licence data, and drive remediation through pull requests, policy gates and tickets. The output is a set of findings with severity, exploitability context and owners. It changes every day even if the code does not, because the advisory data changes.

Side-by-side comparison

Generation accuracy: where SBOMs come from

Most of the disagreement about SBOM quality is really about which lifecycle stage generated it. CISA's community document on SBOM types describes six, and SCA is directly involved in at least two.

Practical rules follow. Ship a Build SBOM for each release because it best reflects the artefact. Use SCA on source to catch problems before the build, and use SCA in Analysed mode to check supplier binaries against the SBOM the supplier sent. Respect the NTIA "known unknowns" practice: the default interpretation of SBOM data is that it is incomplete, so the author should state explicitly where a component's direct dependencies are fully listed. A Source SBOM exported from an SCA dashboard and passed off as the release inventory is the most common accuracy failure.

Exchange and regulation

• EU Cyber Resilience Act (Regulation (EU) 2024/2847): Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components in products with digital elements, including by drawing up an SBOM in a commonly used and machine-readable format covering at the very least top-level dependencies. Annex VII point 8 places the SBOM in the technical documentation, provided to a market surveillance authority on reasoned request; Annex II point 9 applies only if the manufacturer decides to make the SBOM available to users. Per Article 71(2), the Regulation applies from 11 December 2027, with Article 14 reporting obligations from 11 September 2026. The vulnerability handling requirements are where SCA does the work. See the EU Cyber Resilience Act Guide.
• US EO 14028: section 4(e)(vii) called for guidance including "providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website", and section 4(f) led to the NTIA minimum elements.
• OMB M-26-05 (23 January 2026): rescinds M-22-18 and M-23-16. Agencies may adopt contract terms requiring a current SBOM on request (for cloud platforms, covering the runtime production environment), the secure development attestation form becomes optional, and agencies must still maintain a complete inventory of software and hardware. US federal SBOM delivery is therefore a contract decision rather than a blanket requirement, as of the memo date.
• Exchange practice: share SBOMs under access control (an NTIA practice), sign them, and pair them with separately published VEX statements so consumers' SCA tools can suppress non-exploitable findings. See the VEX Guide and the Supplier SBOM Request Template.

Threat model and failure modes: SBOM

• Threat it addresses: slow response to a newly disclosed component compromise. When the XZ Utils backdoor (versions 5.6.0 and 5.6.1) was disclosed, the question was simply "where do we ship or run these versions?", which a release-indexed SBOM store answers in minutes.
• Stale documents: SBOMs generated once and never regenerated for patch releases.
• Shallow depth: only direct dependencies, or an image SBOM that misses statically linked or vendored code.
• Tampered or forged SBOMs: unsigned documents with no provenance tie to the artefact. Sign the SBOM in the same workflow as the build and link it to provenance. See the SLSA and Build Provenance Guide.
• Over-sharing: embedding live vulnerability status in a document sent to many customers, which both goes stale and discloses your backlog.

Controls: Build SBOM per release, signed; validation against the schema and minimum fields on ingest; versioned store keyed by artefact digest; access-controlled distribution.

Threat model and failure modes: SCA

• Threat it addresses: shipping or running known-vulnerable and malicious dependencies (ATT&CK T1195.001 Compromise Software Dependencies and Development Tools).
• Misidentification: manifest-only scanning misses transitive and vendored components; CPE matching produces false positives. Prefer lockfile and build resolution with package URLs.
• Alert floods: CVSS-only queues that developers learn to ignore; combine KEV, EPSS, reachability and VEX. See the Reachability Analysis Guide.
• CVE-only coverage: a newly published malicious package has no CVE; install-time controls and malware feeds are needed. See the Malicious Package and Dependency Confusion Guide.
• Scope gaps: SCA run only on first-party repositories, never on supplier SBOMs or production images.

Controls: gate new critical or exploited findings in pull requests, scan images and supplier SBOMs, record triage decisions as VEX, and track fix SLAs.

Where identity fits

Both pipelines run on non-human identities. The CI job that generates and signs the SBOM needs a signing identity, ideally keyless and short-lived through workload federation rather than a long-lived key. SCA tools hold repository tokens with write access to open fix pull requests, and SBOM platforms hold API keys for ingestion; these should be scoped per project and rotated. A stolen publishing token, not a code flaw, is the root cause in many recent package compromises, which neither an SBOM nor SCA prevents. See the Securing the SBOM management platform itself page and the npm Trusted Publishing and Provenance Guide.

Decision criteria

Worked scenario: a medical imaging software vendor

A vendor ships a desktop viewer and a cloud service to hospitals in the EU and the US. It runs an SCA tool on pull requests and exports a CycloneDX file from the SCA dashboard monthly, which it sends to customers as "the SBOM".

1. Problem found: a hospital's Analysed SBOM of the viewer installer lists an image codec library absent from the vendor's file, because it is vendored in source and not in any manifest the SCA tool parsed.
2. Fix the artefact: the vendor generates a Build SBOM in CI for every release, adds the vendored library with a declared version and hash, marks dependency completeness explicitly, signs the SBOM and stores it keyed by the installer digest.
3. Fix the process: SCA keeps gating pull requests, now also scans the Build SBOM nightly so new advisories reach the right release, and records not_affected decisions as VEX.
4. Fix the exchange: customers receive the SBOM and a separate VEX feed through an access-controlled portal; the cloud service SBOM covers the runtime production environment.
5. Outcome: the regulator-facing artefact and the engineering findings are now separate, accurate and linked by artefact digest.

How to implement both

1. Choose one format and one identifier scheme: CycloneDX or SPDX, package URLs plus hashes, so SBOMs and SCA findings join cleanly.
2. Generate Build SBOMs in CI: start in non-blocking mode for one product line, validate against schema and minimum fields, then make generation a release requirement.
3. Point SCA at both source and SBOMs: pull request scanning for developers; scheduled analysis of every stored SBOM (yours and suppliers') for operations.
4. Separate findings from evidence: keep vulnerability status in the SCA platform and VEX, not in the shipped SBOM.
5. Sign and distribute under access control: sign SBOMs with the build identity, publish through a controlled channel, and log access.
6. Rehearse: run a quarterly "are we affected?" drill against a past advisory and time the answer. Roll back policy gates to warn mode if they block releases without a decision path.

Detection and measurement

Log SBOM generation failures in CI, unsigned SBOM uploads, SBOM downloads by external parties, and SCA policy overrides with the approver's identity.

Common failure patterns

• The SCA export as the release SBOM: a Source SBOM that misses vendored, statically linked or runtime components.
• Vulnerability lists inside shared SBOMs: stale within days and a disclosure of your backlog.
• SBOMs collected, never analysed: supplier files sit in a folder with no SCA matching, so the purchase-time inventory never raises an alert.
• No known-unknowns statement: consumers assume completeness the author never claimed.
• SCA without malware coverage: CVE matching passes a freshly published credential stealer.
• Unsigned SBOMs: no way to tie the document to the artefact it claims to describe.

Framework mapping

Practitioner checklist

• Every release has a signed Build SBOM, stored by artefact digest.
• SBOMs meet the NTIA data fields and state dependency completeness.
• SCA scans pull requests, built images and every stored SBOM, including suppliers'.
• Vulnerability status lives in SCA and VEX, not in shared SBOMs.
• Analysed SBOMs periodically verify Build SBOM accuracy.
• CRA products have SBOMs in technical documentation ready for authority requests.
• Signing and SCA tokens are short-lived, scoped and owned.
• An "are we affected?" drill is run and timed each quarter.

Standards and references

• Federal Register: Executive Order 14028, Improving the Nation's Cybersecurity
• NTIA: The Minimum Elements for a Software Bill of Materials
• CISA: Types of Software Bill of Materials (SBOM) Documents
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act
• OMB: M-26-05 Adopting a Risk-based Approach to Software and Hardware Security
• CycloneDX: Specification Overview
• SPDX: Specifications

Related NHI Mgmt Group resources: SBOM vs HBOM vs CBOM, SBOM operations, Software Supply Chain Security Guide, OWASP Dependency-Track Guide. This guide summarises regulatory requirements and is not legal advice.