SBOM vs software composition analysis

SBOM vs software composition analysis: which one do you need first?

An SBOM is the inventory, and software composition analysis (SCA) is the analysis that runs against it. Most teams need both, but the order depends on what you owe. A product maker or internal platform team facing the EU Cyber Resilience Act, a customer questionnaire or a federal buyer's demands usually has to produce a machine-readable list of its components first, because nothing can be assessed until the list exists. The CRA's Annex I Part II point (1) requires manufacturers to identify and document components by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Sharing that SBOM with users is a separate choice under Annex II point 9, so an SBOM alone can satisfy a supplier's documentation duty without anyone outside the company seeing it. SCA alone is the right starting point for an internal pipeline where the goal is to stop known-vulnerable or license-incompatible components from shipping, and no external party asks for a document. In that case, a scanner that reads lock files and build manifests and flags findings on each build delivers value before any formal SBOM exists. The limit is that SCA output is only as complete as the dependency resolution behind it. Confirm which manifests and transitive dependencies your tool resolves, and whether it can export the same data as an SBOM later, so the pipeline does not need rework when a customer asks for one.

For regulated buyers, the default is the combined pattern: generate the SBOM from the build, then run SCA against that same SBOM on every release. An inventory without analysis tells a bank or public agency what is inside a product but not whether any of it is exploitable or licensed in a way that blocks use. Analysis without an exportable inventory cannot answer the questions an auditor or procurement team asks, such as which version of a library a given release shipped. Ask any tool vendor or internal team whether the SBOM format is CycloneDX or SPDX, whether it is generated from the build rather than hand-written, and whether SCA findings reference the same component identifiers. Those three answers tell you whether the two halves will stay in sync. Start with an SBOM alone when a contractual or regulatory deadline is near and your immediate gap is documentation. Start with SCA alone when your gap is risk on the next build and no buyer has asked for the file. Start with both when you sell into regulated markets, because the inventory is the evidence and the analysis is what makes the evidence useful. Whichever you start with, agree in writing which component depth, format and update frequency your scope covers, since those choices drive the cost of both.

How the two approaches differ across goal, scope and output

This table compares an SBOM and software composition analysis on goal, the question each answers, what each inspects, its output, formats, typical owner and the regulatory hooks that name them. Read it to see why the two are complementary: the SBOM records what is inside a product, and SCA decides which of those components need attention.

Dimension	SBOM	Software composition analysis (SCA)
Primary goal	Create a machine-readable record of components and their supply chain relationships	Find known vulnerabilities, outdated versions and license risk in the components
Primary question answered	What components are in this product, and how are they related?	Which of those components carry known risk, and does it need action?
What it inspects	Top-level dependencies at minimum under CRA Annex I Part II point (1), with transitive detail where the manufacturer includes it	Declared and resolved components, checked against vulnerability and license data sources the tool uses
Output	A structured inventory file that other tools and users can read	A findings report listing vulnerable or license-flagged components, usually with severity data from the tool's sources
Standard formats	CycloneDX (Ecma standard ECMA-424, version 1.7 released 21 October 2025) and SPDX (ISO/IEC 5962:2021)	Usually proprietary or tool-specific report formats; confirm whether the tool exports CycloneDX or SPDX
Typical owner	Product or software supply chain owner who produces the release artifact, with engineering support	Application security or platform security team, often run inside CI pipelines
Regulatory hook	CRA Article 3(39) defines the SBOM; Annex I Part II point (1) requires one in a commonly used machine-readable format	No SCA-specific duty is named in the supplied CRA text; confirm how the CRA's vulnerability handling duties apply to your tooling
US reference	NTIA Minimum Elements for an SBOM (12 July 2021) defines data fields, automation support and practices	Not defined by the NTIA minimum elements; confirm what your federal buyer expects of analysis output

What an SBOM must contain under the CRA and NTIA

Start with the legal definition, because it sets the floor for what a supplier must hand you. Article 3(39) of the Cyber Resilience Act defines a *software bill of materials* as a formal record containing details and supply chain relationships of the components in a product with digital elements. Annex I, Part II, point (1) goes further for manufacturers: they must identify and document components and vulnerabilities, including by drawing up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies. Ask suppliers which format they produce and whether it lists transitive dependencies, not only the direct ones. A top-level-only file meets the stated minimum but tells you little about where a vulnerable library actually sits.

The NTIA minimum elements, published on 12 July 2021 under Executive Order 14028, are a useful checklist for the content itself. They group expectations into three categories: data fields, automation support, and practices and processes. Data fields cover what each component record carries, automation support covers whether the file can be generated and consumed by tools, and practices and processes cover how often the SBOM is refreshed and how the supplier handles updates. Request a sample SBOM for one of your products and check each category against the NTIA document, then confirm in writing how the supplier keeps that file current after a patch ships.

Be clear about what the CRA does not require. Under Annex II, point 9, sharing the SBOM with users is optional. The manufacturer only has to tell users where to access it if the manufacturer decides to make it available. A supplier can therefore comply with the CRA while keeping the SBOM to itself, which leaves you without the inventory you need to run your own analysis. If you need the file, make delivery a contract term, specify the format and the NTIA data fields, and agree who receives updates when a component changes. Confirm these terms with the supplier and with counsel, since the obligations for your own products and your procurement rights may differ.

What an SBOM finds and misses, and what SCA finds and misses

An SBOM and software composition analysis answer different questions about the same components. The cards below separate what each one reveals from what each one leaves unanswered, so a team can see where a gap would sit in its own program before choosing tools.

What an SBOM reveals

An SBOM is a formal, machine-readable record of the components in a product and how they relate to each other. The CRA requires manufacturers to draw one up in a commonly used, machine-readable format covering at least the top-level dependencies. Check whether your SBOM names each component, its version, its supplier and its dependency relationships, since those are the fields that let a later analysis tool match a component to a known flaw.

What an SBOM misses

An SBOM on its own flags no vulnerabilities. It records what is inside a product but does not say whether any of those components has a known weakness, is outdated, or conflicts with a license policy. Teams that stop at generating the file have an inventory, not a risk view. Ask any SBOM generator whether it performs matching against vulnerability data, and confirm that step is carried out by a separate tool or process.

What SCA reveals

Software composition analysis inspects declared and detected dependencies and reports known vulnerabilities, outdated versions and license conflicts. Its output is only as useful as the component identification behind it. Before relying on results, confirm which manifests, lock files and package ecosystems the tool reads, and whether it reports the transitive dependencies that your builds actually pull in.

What SCA misses

SCA depends on accurate component identification. Code that was copied into a repository, vendored into a directory without a manifest, or compiled in from an unlisted source may never be matched against a vulnerability record. Ask the vendor how it detects vendored or snippet-level code, and test the tool with a deliberately vendored library in a non-production repository to see whether it is reported.

Where the two overlap

Both tools can list components, so a team may assume one replaces the other. They do not. An SBOM is an artifact you hand to customers, auditors and operators, while SCA is an analysis you run against that inventory. When the SBOM is complete and the SCA tool consumes it, the two produce matching component records, and any difference between them is a question to resolve before release.

Which approach a team should start with by situation

If you place a product with digital elements on the EU market, the Cyber Resilience Act makes the SBOM a documentation duty that attaches to the product itself. Annex I Part II point (1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies. Article 3(39) defines the SBOM as a formal record of components and their supply chain relationships, so the file has to show relationships, not only a flat list.

First deliverable: a machine-readable SBOM for each product version, generated in your build and kept with the release record.
Driving obligation: Annex I Part II point (1), read with the Article 3(39) definition.
Analysis step: the SBOM does not tell you which components are vulnerable, so plan a matching process that runs on every release.
Sharing decision: under Annex II point 9, you only tell users where to access the SBOM if you decide to make it available, so record that decision and its reasons.

Confirm with your legal and product security leads which product lines and versions are in scope, and how your build will produce the file.

What you receive from each approach

This table compares the concrete outputs of an SBOM program and a software composition analysis engagement. Read it to see which artifact answers which question, and what to request in writing before work starts.

Deliverable	SBOM (inventory)	SCA (analysis report)
Primary output	A machine-readable file listing components, versions and supplier data, in CycloneDX or SPDX	A findings report listing known vulnerabilities and license issues across the same components
Format and version	Ask for the named format and specification version in writing, since CycloneDX and SPDX publish multiple versions	Usually a report or dashboard export; ask for a machine-readable export such as SARIF or CSV if you need to ingest it
Required data fields	NTIA minimum elements: supplier, component name, version, unique identifiers, dependency relationships, author, timestamp	Component identity, matched vulnerability identifiers, severity, license type and affected version ranges
Dependency depth	CRA Annex I requires at least top-level dependencies; request transitive depth explicitly if you need it	Analysis is only as deep as the inventory it reads, so confirm whether transitive packages are scanned
Prioritization	None by itself; an SBOM records what is present, not whether it is exploitable	Severity ranking, reachability or exploitability notes where the tool supports them, and remediation guidance
Remediation tracking	Not included; the SBOM changes only when the product is rebuilt or regenerated	Ticket or status tracking for each finding, with suppression rules and documented reasons for any accepted risk
Update cadence	Ask how often the SBOM is regenerated, for example per build or per release	Ask how often vulnerability data is refreshed and how often the report is rerun against deployed versions
Buyer responsibility	Decide whether to publish the SBOM, since CRA user information duties apply only when the manufacturer chooses to share it	Triage findings, decide fixes or accepted risk, and keep records that show the decision

What drives SBOM and SCA cost and effort

SBOM and SCA costs split into generation, tooling, pipeline integration, triage, license review and upkeep, and each one is paid by a different party. The biggest swings come from how many products and pipelines you run, how deep the dependency trees go, and how many findings need a person to decide.

SBOM generation and format work

Generating an SBOM is usually the first recurring duty, and it falls to whoever builds the product: your engineers, a build vendor or DeployOpen under a fixed-scope engagement. Effort rises with the number of languages, package managers and binaries you ship, because each ecosystem reads dependencies differently. Ask whether the output is CycloneDX or SPDX, whether it covers transitive dependencies, and who validates the file before release.

Tooling setup and licensing

Tooling is a one-time setup cost plus any recurring subscription, depending on whether the SCA product is open source, commercial or bundled with a code platform. Self-hosted scanners need a vulnerability database kept current, which is an ongoing operational task. Check the license terms of each tool, whether the vendor charges per developer, per repository or per scan, and whether vulnerability feeds are included or sold separately.

CI pipeline integration

Wiring generation and scanning into build pipelines is largely a one-time engineering task, but every new repository, service or build target adds a small recurring share. Each pipeline needs credentials, artifact storage and a rule for what fails a build. Cost climbs fastest in organizations with many monolithic repositories or inconsistent build systems, so ask for a pipeline inventory before estimating effort.

Vulnerability and finding triage

Triage is the recurring cost that most programs underestimate. Scanners report known vulnerabilities in components you may never execute, so someone must decide reachability, severity and fix priority for each finding. The volume depends on dependency depth and how strict your policy is. Ask how the tool suppresses duplicates, whether it accepts VEX-style statements and who signs off on a risk acceptance.

License review and policy decisions

License review is a human task owned by legal or the open-source program office, and it recurs with every new dependency or upgrade. Policy decisions, such as which licenses are blocked or require approval, are one-time work that needs periodic revision. Costs rise when products mix copyleft and permissive components or ship to customers in several jurisdictions. Confirm who owns the policy and how exceptions are recorded.

Ongoing maintenance and upgrades

Ongoing maintenance covers keeping scanners, databases, SBOM generators and pipeline templates current, plus regenerating SBOMs whenever a component changes. This is the work most likely to stall after launch, which leaves SBOMs stale and findings unreviewed. When requesting a quote, ask who handles upgrades, how often vulnerability data is refreshed, and whether the scope includes retainer support or a one-time handover.

Why an inventory without analysis covers only half the job

An SBOM tells you what is inside a product, but not whether any of it is exposed. A component list answers the question of which libraries, versions and suppliers ship in your software. It does not say whether a given version carries a known vulnerability, whether that vulnerability is reachable in your build, or whether the license of a component conflicts with how you distribute it. That gap is why the EU Cyber Resilience Act places its vulnerability handling duties on the manufacturer, not on the inventory. Annex I Part II requires manufacturers to identify and document vulnerabilities and components, and the SBOM is one input to that work. Confirm with your legal and product teams which of the CRA's duties apply to your products and which component records you will need to keep to meet them.

OWASP frames SBOMs as a means of achieving software transparency, and its component analysis guidance names CycloneDX and SPDX as the standards that carry the inventory. Transparency is the goal; the inventory is the record that makes it possible. Analysis is what turns that record into decisions, such as which findings need a fix, which need a documented justification, and which can be closed because the vulnerable code path is not used. The NTIA minimum elements treat automation support and practices and processes as part of an SBOM program, not just the data fields. When you ask a tooling vendor or a supplier for an SBOM, ask what they run against it, how often the list is refreshed, and who owns the response when a new advisory lands against a listed component.

Vulnerability exploitability is the next step after inventory and analysis, and it is handled by VEX, which states whether a known vulnerability affects a product. That topic has its own comparison, so this page only marks the boundary: an SBOM plus a software composition analysis run tells you where risk may sit, while a VEX statement records a considered judgment about whether it applies. Until you have both, expect questions from customers and auditors that the inventory alone cannot answer.

How much does SBOM and SCA work cost, and what do we need to provide?

How much does an SBOM engagement cost and how long does it take?

No supplied figure gives a price or duration for SBOM or SCA work, so the reliable answer comes from the written scope and quote. Cost follows the number of products, the number of build pipelines, how many components and direct dependencies each product has, and whether the SBOM must be generated from build outputs or reconstructed from source. Ask for the scope in writing, the deliverables (for example, one SBOM per product release in a named format), the systems you must grant access to, and what is one-time setup versus recurring regeneration. Fixed-scope work is agreed in writing before it starts, so the quote should state its own timeline.

Can our own engineering team generate SBOMs without outside help?

Yes, if your team has the build access and ownership to produce SBOMs as part of the build. The Cyber Resilience Act requires manufacturers to draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies (Annex I, Part II, point 1), so the content and format are the minimum to meet. The work itself depends on whether generation runs inside each build pipeline, which needs engineers who own the pipeline configuration, and on whether someone maintains the output as dependencies change. Your team should confirm which fields the NTIA minimum elements require and which automation support the chosen tools provide before committing.

Should we choose CycloneDX or SPDX for our SBOM?

Both are recognized standards, so choose by the tooling your consumers and scanners read. CycloneDX is published as Ecma standard ECMA-424, with version 1.7 released on 21 October 2025, and SPDX is recognized as the international standard ISO/IEC 5962:2021. OWASP names both as SBOM standards in its component analysis guidance. Ask your largest customers, auditors and internal scanner vendors which format they ingest, and confirm that your SCA tooling imports and exports it. Converting between formats is possible, but it adds a step you must test and maintain.

Does the Cyber Resilience Act require us to publish our SBOM?

No. Under the Cyber Resilience Act, sharing the SBOM with users is optional. Annex II, point 9 requires manufacturers to tell users where to access the SBOM only if the manufacturer decides to make it available. The SBOM still has to exist and be kept as part of the technical file and vulnerability handling duties, so the decision is about distribution, not creation. Decide with legal and product counsel whether to publish, to whom, and under which terms, and record that decision as part of the product's compliance evidence.

Do we still need software composition analysis if we already have an SBOM?

Yes. An SBOM is an inventory, and an inventory does not say whether a listed component has a known vulnerability, is outdated, or carries a license that conflicts with your distribution model. Software composition analysis compares the components against vulnerability data and license information, then reports what needs action. Budget for the analysis tool, its data feeds, and the people who triage findings, because those recur as new vulnerabilities are published. Ask any provider to show how findings are matched to components and how suppressed findings are recorded.

What do we need to provide before an SBOM or SCA engagement can start?

Expect to provide build and repository access, a list of products and release branches in scope, the current dependency manifests and lock files, the CI/CD configuration, and a named owner who can approve changes. Engagements are typically fixed-scope, so agree in writing which products, environments and formats are covered. Ask the provider how credentials are handled, whether work happens inside your cloud account or on-premises network, and who receives the output. These inputs drive effort more than the tooling does.

What recurring costs should we plan for after the first SBOM?

The main recurring costs are regenerating SBOMs for each release, refreshing vulnerability and license data, triaging new findings, and keeping pipelines working as dependencies and tools change. The NTIA minimum elements group automation support and practices as separate categories, which means the process must keep running, not just produce one file. Ask for the cadence of updates in the quote, who triages findings, and whether ongoing support is priced as a retainer or as separate work. Retainers cover ongoing support, upgrades and continuous testing when they are part of the agreed scope.

How to combine SBOM generation and SCA in one program

The practical starting point is generating the SBOM from the build itself, not from a manual list kept by developers. Run the SBOM step in the same pipeline that produces the artifact, so the inventory reflects what actually shipped, including transitive dependencies that no one typed into a manifest. Record the format you chose (CycloneDX or SPDX) and the tool that produced it, because an auditor or customer will ask how the file was made and whether it can be regenerated. Confirm with your SBOM tool vendor which dependency resolution method it uses for your languages and build systems, since that determines whether the inventory is complete.

Once the SBOM exists, run SCA against that file on every release rather than against the source tree alone. Feeding the SBOM into the analyzer keeps the two artifacts tied together: the same component versions are checked for known vulnerabilities and license conflicts, and a finding can be traced back to a specific build. Route each finding to a named owner, usually the team that owns the affected service, and set a rule for what happens when no fix exists yet, such as documenting a compensating control. Ask your SCA provider which vulnerability databases it draws from and how often they refresh, since a stale database makes a clean scan misleading. Keep the SBOM current with each version by storing one per release and comparing it with the previous one, so that new or changed components are visible.

The combined program still needs human triage. Scanners report matches between component identifiers and vulnerability records, and those matches can be wrong when a package is vendored, renamed or patched downstream. A reviewer should confirm that a flagged component is really shipped and reachable before anyone spends engineering time on it, and should record the decision when a finding is dismissed. This is a defensive exercise: its purpose is to reduce the time between a disclosed component flaw and a remediated release. Decide in advance who signs off on accepted risk, and make sure that decision is written down in a form your compliance team can review.

How DeployOpen scopes and delivers SBOM and SCA work

The sequence turns an SBOM and composition analysis from a one-off report into a repeatable pipeline output that the client owns, runs and can show to an assessor. Each step ends with a written deliverable or a check that the client can verify.

Define scope and obligations in writing
DeployOpen and the client agree in writing which products, repositories and release trains are in scope, who the SBOM is for (internal teams, customers, or both), and which obligations drive the work, such as the CRA duties for products with digital elements or NTIA minimum elements for federal buyers. The client confirms with its legal or regulatory contacts which duties apply, since DeployOpen does not make that determination. The signed scope document, with deliverables and agreed acceptance criteria, closes this step and must exist before any build work begins.
Inventory current build and dependency sources
The team maps every point where components enter the software: package manifests, lock files, container base images, vendored code, build plugins and any firmware or embedded libraries. DeployOpen records which of these the client already controls and which come from external registries. The output is a source inventory listing each repository, build system and package ecosystem, with owners named. The step closes when the client has reviewed and approved the inventory, so that no in-scope component source is left unmapped.
Choose SBOM format and generation tooling
DeployOpen compares the candidate formats, CycloneDX and SPDX, against the client's consumers, tooling support and any format the client's customers request. The decision is recorded with its reasons so that future upgrades do not silently change the output. Generators are selected per ecosystem and configured to cover at least the top-level dependencies that the CRA's Annex I Part II expects. The step closes with a documented format choice and a tested generator configuration on a sample build.
Integrate generation into the client's pipelines
DeployOpen adds SBOM generation to the client's own CI/CD system in the client's infrastructure, so that each build produces a machine-readable file tied to a specific version and commit. Configuration is kept in the client's repositories and reviewed by their engineers. Build artifacts and SBOM files are stored where the client's retention rules apply. The step closes when several consecutive builds have produced valid SBOM files that the client's team has inspected.
Connect composition analysis and triage rules
The SBOM feeds a software composition analysis tool, chosen and hosted under the client's control, that matches components against vulnerability and license data. DeployOpen sets severity thresholds, license allow and deny lists, and a documented triage workflow that states who reviews each finding and how exceptions are approved. Known false positives are recorded with a reason, not silently suppressed. The step closes with a tested alert path and a written triage procedure that the client's owners have accepted.
Document evidence and map it to obligations
DeployOpen assembles the evidence set: the scope document, format decision, generator configuration, pipeline change records, sample SBOMs, triage logs and exception approvals. Each item is mapped to the relevant obligation or control, such as the CRA requirement to identify and document components, so that the client can show how the work was done. DeployOpen prepares this evidence for compliance assessments, but it does not issue audit reports or certifications, and the client's assessors decide what the evidence proves. The step closes when the client confirms the evidence pack is complete and retrievable.
Hand over, train and agree ongoing support
DeployOpen runs a handover session with the client's build, security and product teams, covering how to read SBOMs, how to act on composition findings and how to update configuration. The client receives runbooks and a list of open items. Ongoing work such as generator updates, format changes, new product lines and periodic re-validation can be covered by a separate retainer, with its own written scope. The step closes when the client accepts the handover and any retainer scope is agreed in writing.

SBOM vs software composition analysis