The Consumer: Receiving and Using SBOMs

An SBOM Consumer is any organization or individual that receives SBOMs and uses them to make decisions about the software they depend on.

For example, a vulnerability scanner can cross-reference the components listed in an SBOM against a database like the National Vulnerability Database (NVD) to flag known issues.

Typically, SBOMs are not consumed directly but are first processed in a system and enriched with additional information. For example, if a consumer wants to use SBOMs to identify vulnerabilities in a software’s supply chain, the SBOM—without extensions such as VEX—initially contains only a neutral list of components. It is only through the (automated) querying of known vulnerabilities for the components used that added value is created, from which action can be derived.

In addition to their use in vulnerability management, SBOMs can also help consumers address other use cases, such as license compliance, technical debt management, or supplier transparency. Details on the use cases can be found here. For more on how SBOMs are created and shared, see Producer and Distributor.

How to Get Started

Solo Operators and Small Businesses

Approximately 1–50 employees and no dedicated IT or IT‑Security functions. Includes freelancers.

1. Identify the software being used.
   This can include purchased software, software developed in‑house, or software to be sold as a product.
   Small businesses usually maintain this overview as lists or simple spreadsheets, optionally enriched with basic metadata (vendor, version, purpose, and owner).

2. Set up an analysis system.
   SBOM files are difficult for humans to read. Use lightweight analysis tools to ingest SBOMs and enrich them with vulnerability and license data. Suitable tools can be found here.
   For very small setups, a single desktop tool or a small self‑hosted service is often sufficient.

3. Define a handoff‑point.
   Define how SBOMs should be received (e.g., email, shared folder, or download portal).
   At this level, manual import into the analysis system is acceptable, but document who is responsible and where files are stored.

4. Perform basic risk triage.
   For each new or updated SBOM, check for critical and high vulnerabilities/licenses in components you actually use.
   Prioritize actions (update, replace, isolate) based on severity and exposure, not just the number of findings.

5. Document decisions and actions.
   Keep a simple log of what was done for each SBOM (e.g., “updated component X”, “accepted risk with mitigation Y”).
   This supports audits, insurance questionnaires, and future incident response.

Mid‑Sized Companies

Approximately 50–500 employees and only a small or fractional IT team.

1. Identify the software being used.
   This can include purchased software, software developed in‑house, or software to be sold as a product.
   Mid‑sized companies usually maintain this information in a structured database or entry‑level IT Asset Management (ITAM) tool to enable cross‑referencing with contracts, owners, and environments.

2. Set up an analysis system.
   SBOM files are difficult for humans to read. Use analysis systems to process SBOMs and enrich them with vulnerability, license, and end‑of‑life data. Suitable tools can be found here.
   Integrate the tool with your asset inventory so each SBOM is linked to a specific product, environment, and responsible team.

3. Define a handoff‑point.
   Define standard channels and formats for receiving SBOMs (e.g., CycloneDX or SPDX via email, ticket attachment, or a dedicated intake form).
   Assign ownership (e.g., product security or platform team) for validating and ingesting incoming SBOMs.

4. Specify which information should be delivered.
   Define minimum SBOM requirements for suppliers: format (CycloneDX/SPDX), coverage (including transitive dependencies), key fields (component name, version, supplier, identifiers like PURL/CPE, hashes, licenses, timestamp), and update triggers (new releases, patches, or at least every 90–180 days).
   Optionally require vulnerability status information (e.g., VEX/CSAF) where available.

5. Require SBOM delivery in vendor contracts.
   Include SBOM obligations in procurement documents, RFPs, and contracts: format, frequency, quality expectations, and consequences for non‑delivery.
   Add clauses for updated SBOMs after releases and for notification of newly discovered critical vulnerabilities affecting delivered components.

6. Establish processes for handling SBOMs.
   Define a repeatable workflow: ingest → validate → enrich → triage → assign → remediate/accept → document.
   Integrate this workflow with your ticketing system so findings become actionable tasks with owners and due dates.

7. Monitor and review.
   Periodically review SBOM coverage, data quality, and time‑to‑remediate for high‑severity issues.
   Use these metrics to refine contract language, supplier expectations, and internal processes.

Enterprises or Regulated Entities

More than 500 employees or regulated entities including healthcare, financial services, or defense. Dedicated and well‑staffed IT and IT‑Security teams.

1. Identify the software being used.
   This can include purchased software, software developed in‑house, or software to be sold as a product.
   Enterprises and regulated entities usually maintain this information in full‑scale ITAM/CMDB platforms, enabling integration with ticketing, change management, and risk registers.

2. Set up an analysis system.
   SBOM files are difficult for humans to read. Use enterprise‑grade analysis platforms to process SBOMs and enrich them with vulnerability, license, EOL, and policy data. Suitable tools can be found here.
   Integrate these tools with existing processes and systems such as ticketing, SIEM, GRC, and change management to support automated workflows and reporting.

3. Define a handoff‑point.
   Standardize secure, automated SBOM intake (e.g., API, artifact repository, or dedicated portal) with clear authentication, access control, and logging.
   Define roles (e.g., product security, supply‑chain security, procurement) responsible for validation, exception handling, and escalation.

4. Specify which information should be delivered.
   Define detailed SBOM requirements aligned with frameworks such as CISA’s Minimum Elements: mandatory fields, transitive dependency coverage, component hashes, unique identifiers, license data, and update cadence.
   Require machine‑readable vulnerability status (VEX/CSAF) where applicable and define expectations for corrections and “known unknowns”.

5. Require SBOM delivery in vendor contracts.
   Embed SBOM obligations into enterprise procurement policies, RFPs, and master service agreements: formats, data quality, delivery triggers, update intervals, vulnerability notification duties, audit rights, and subcontractor flow‑down.
   Include acceptance criteria and the right to reject deliveries that do not meet SBOM requirements.

6. Establish processes for handling SBOMs.
   Implement an end‑to‑end, automated pipeline: standardized ingestion, schema and policy validation, enrichment, risk scoring, assignment, remediation tracking, and evidence retention.
   Align processes with regulatory requirements (e.g., sector‑specific rules, critical infrastructure mandates) and internal governance frameworks.

7. Integrate with vulnerability and incident management.
   Connect SBOM data to vulnerability management and incident response workflows so that newly disclosed CVEs can be rapidly mapped to affected products, environments, and customers.
   Define SLAs for triage, mitigation, and communication based on severity and regulatory obligations.

8. Measure, audit, and improve.
   Define and track KPIs such as SBOM coverage, data quality scores, time‑to‑triage, time‑to‑remediate, and supplier compliance rates.
   Use internal and external audits to verify that SBOM practices meet contractual, regulatory, and risk‑management objectives, and continuously refine requirements and tooling.

How to Measure Success

Metrics can help measure the maturity of the SBOM program. Here are some example metrics.

Small Organization Metrics

Metric	What it measures
SBOM availability coverage	Percentage of Tier 1 vendors from whom a current SBOM has been received
SBOM format compliance	Percentage of received SBOMs in a supported format (SPDX 2.3+ or CycloneDX 1.4+)
Contract SBOM clause coverage	Percentage of critical vendor contracts specifying SBOM delivery requirements
VEX coverage	Percentage of Tier 1 vendors that issue VEX statements when vulnerabilities affecting their software are disclosed
Vulnerability response time	Time from public disclosure of a vulnerability to confirmed impact status across Tier 1 vendors

Enterprise Metrics

Metric	What it measures
Coverage	Percentage of in-scope third-party software with at least one current SBOM in the repository
Freshness	Median age of the latest SBOM per deployed product version
Quality score	Aggregate quality score across received SBOMs
VEX coverage	Percentage of vendor SBOMs accompanied by at least one VEX statement
Vulnerable-component lead time	Time from public CVE disclosure to internal identification of all affected products
KEV coverage	Time from KEV listing to verified mitigation across affected products
Vendor responsiveness	Median time from SBOM request to receipt of updated artifact
Audit readiness	Time to produce an inventory snapshot for a given date and product set