What To Do

Getting Started

SaaS / Commercial Software Consumers

Organizations that consume software primarily through SaaS platforms and commercial packaged applications engage with the SBOM ecosystem through vendor management — evaluating vendor SBOM practices, requiring SBOM delivery in contracts, and acting on SBOM-derived information when vulnerabilities are disclosed. The steps below establish a structured approach to SBOM-aware vendor management.

1. Establish a software asset inventory

   Effective SBOM consumption requires an accurate record of the software your organization runs. The appropriate tooling scales with organizational size:

   • Under approximately 50 staff: A maintained list in spreadsheet or simple database form — capturing vendor, product, and version for each software asset — is a viable starting point for associating received SBOMs with deployed software.
   • 50–200 staff: A structured database or entry-level IT Asset Management (ITAM) tool provides the queryability needed to cross-reference software assets against SBOM data and vulnerability disclosures at the speed those tasks require.
   • Above 200 staff: A dedicated ITAM platform — such as ServiceNow, Freshservice, or Snipe-IT — is appropriate. Integration with ticketing systems allows SBOM-derived vulnerability findings to feed directly into remediation workflows.

2. Request SBOM information from vendors

   When evaluating or renewing software vendors, ask specifically about their SBOM practices:

   • Do you provide a Software Bill of Materials with every product release?
   • What SBOM formats do you support — SPDX, CycloneDX, or both?
   • Is SBOM delivery included with the software, or provided through a separate channel or portal?
   • How are SBOMs updated when component changes occur between major releases?
   • Do you provide VEX (Vulnerability Exploitability eXchange) statements when vulnerabilities are disclosed affecting your product?
   • What is your process for issuing an updated SBOM following a security disclosure?

3. Require SBOM delivery in vendor contracts

   Vendor contracts should specify SBOM delivery as part of the software procurement. Contract language should address:

   • Delivery of an SBOM in a supported format (SPDX 2.3 or later, CycloneDX 1.4 or later) with each product release
   • The delivery channel and timeline for SBOM updates when component changes occur
   • The vendor’s obligation to issue a VEX statement or impact assessment when a disclosed vulnerability affects components in a delivered SBOM

4. Monitor vendor SBOM and VEX communications

   Establish a process for receiving and acting on SBOM-related communications from vendors:

   • Subscribe to vendor advisory channels that publish SBOM-relevant updates and VEX statements
   • When a vulnerability is disclosed in a software category in your environment, contact vendor support to request SBOM-backed confirmation of impact status
   • Document vendor responses and retain them alongside the relevant SBOM records

Technical / Development Org

Organizations with a dedicated security team, DevSecOps capability, or internal engineering function engage directly with SBOM artifacts across the full receiving workflow. The steps below cover the receiving side. For the tooling landscape across open-source and commercial options, see SBOM Tooling.

1. Build your asset inventory

   Effective SBOM correlation requires an accurate inventory of the software deployed in your environment. Map software assets across hardware, software, and firmware — capturing vendor, product, and version — and establish a linkage between SBOM records and the specific deployed instances they describe. An SBOM is most valuable when it can be associated with a specific system in a specific state.

2. Obtain SBOMs from your suppliers

   Request SBOMs from software vendors and upstream suppliers. Determine where each vendor publishes SBOMs — product downloads, customer portals, APIs, or the Transparency Exchange API (TEA)^[12] — and establish a retrieval process for each. Verify SBOM integrity using signatures or hashes where available.

3. Ingest into an SBOM-aware analysis tool

   Use tooling that can ingest both SPDX and CycloneDX formats, correlate SBOM components against live vulnerability feeds, and support VEX/CSAF ingestion to filter false-positive findings. See SBOM Tooling for the current open-source and commercial landscape.

4. Monitor and respond

   Continuously correlate your SBOM inventory against new vulnerability disclosures. Consume VEX and CSAF documents from your suppliers to prioritize remediation based on actual exploitability.^[1] Maintain SBOM records with version and receipt date to support audit and incident response.

---

Escalation Paths

Structured escalation when a supplier does not deliver an SBOM or cannot respond to a vulnerability inquiry.

Organization with an internal security function

Most SBOM receiving problems originate from tooling gaps or distribution channel mismatches rather than refusal. A structured four-step path resolves most situations.

1. Direct technical conversation. Contact the producer’s product security team with a specific description of the SBOM gap — missing fields, unsupported format, unavailable delivery channel. Most issues are resolved at this level.
2. Documented commitment. Request a written commitment to deliver a conforming SBOM within a defined timeframe. Retain the correspondence as the basis for either resolution or escalation.
3. Account-level escalation. If the producer does not deliver within the committed timeframe, escalate to the account team and the producer’s executive sponsor. Frame the issue in operational terms: the absence of the SBOM creates a gap in vulnerability correlation for deployed software.
4. Procurement consequences. If the gap remains unresolved, it becomes a contract matter: clause invocation, tier downgrade, or renewal decision.

Good-faith receiving practice means not treating minor SBOM imperfections as equivalent to non-delivery, not demanding artifacts the producer cannot reasonably generate, and not attributing consumer-side processing issues to the producer.

Organization with an MSP as security operator

When a vendor cannot provide SBOM information or fails to respond to a vulnerability inquiry, escalation runs through the MSP. The customer’s managed services agreement should specify what the MSP will do in these scenarios. Expected MSP obligations include:

• Notification within a defined timeframe when a vulnerability is disclosed affecting software categories in the customer’s environment
• A determination of actual impact, supported by SBOM-based analysis, within a defined follow-up window
• A documented recommendation for remediation or mitigation

If the MSP agreement does not cover these obligations, that gap should be addressed at the next contract review. If an MSP is unable to conduct SBOM-informed vulnerability assessment, that is a capability question. If they are unwilling, it is a procurement decision.

Small organization without a dedicated IT function

For small organizations, escalation for SBOM-related issues typically means escalating directly with the vendor when they are unable to provide SBOM information or respond to a vulnerability inquiry.

1. Contact vendor support and request the SBOM for the version in use, or request the vendor’s VEX statement or impact assessment for the disclosed vulnerability.
2. If the vendor does not respond within a reasonable timeframe, escalate to the account manager or executive contact. If SBOM delivery was specified in the vendor agreement, frame this as a contract compliance matter.
3. If the vendor is unable to confirm which components are in their software, document that response. Treat it as a vendor risk indicator in the next renewal evaluation.
4. For critical infrastructure operators or regulated entities, CISA regional advisors can provide guidance on vendor software risk when internal resources are limited.^[13]

---

Maturing Your Approach

The sections below are for organizations formalizing their SBOM receiving program — whether that means assigning responsibilities across a small team or building out a structured enterprise capability.

Roles and Responsibilities

Single IT/security owner — small organization

In small organizations without a dedicated security team, SBOM-related responsibilities consolidate onto one or two people. The table below identifies the minimum SBOM receiving activities and assigns them a home.

Activity	Who owns it	Minimum action
Software asset inventory	IT/security owner or MSP	Maintain a current record of software vendors, products, and versions. SBOMs cannot be associated with deployed assets without accurate inventory.
Requesting SBOMs at vendor evaluation and renewal	Whoever evaluates vendors	Include SBOM availability questions in vendor evaluation. Specify SBOM delivery requirements in contracts.
Receiving and storing vendor SBOMs	IT/security owner or MSP	Establish a storage location for received SBOMs. Record vendor, product version, SBOM format, and receipt date for each artifact.
Monitoring for vendor SBOM and VEX updates	IT/security owner or MSP	Subscribe to vendor advisory channels. Review VEX statements when issued for software in your environment and document the response.
Acting on vulnerability findings from SBOM data	IT/security owner	When a vulnerability is disclosed affecting a component in a received SBOM, initiate the relevant remediation or vendor contact process.
SBOM record retention	Owner + IT/security owner	Retain received SBOMs and associated VEX statements with version and date. Make records accessible for audit or regulatory review.

Small internal team with MSP — 5–20 employees

Activity	Who owns it	Minimum action
Software asset inventory	MSP	Confirm inventory is current and covers software title and version. Verify it supports SBOM association at that level of granularity.
Requesting SBOMs at vendor onboarding	Business owner + MSP	Include SBOM availability and format support in vendor evaluation criteria. Specify delivery requirements in contracts.
Receiving and ingesting vendor SBOMs	MSP	MSP should have a defined process for receiving, validating format and completeness, and storing SBOMs from vendors in the customer’s environment.
Vulnerability correlation against SBOM data	MSP	MSP should correlate received SBOMs against current vulnerability feeds and communicate findings to the customer within a defined timeframe.
VEX intake and triage	MSP	MSP should ingest vendor-issued VEX statements and use them to filter and prioritize vulnerability findings before customer communication.
SBOM record retention	MSP + business owner	Define retention requirements. Confirm the MSP agreement specifies that SBOM and VEX records are available to the customer on request.

Development organization

For organizations with engineering teams and a formal security function, cross-functional reach is the defining challenge. Procurement, ITAM, security, legal, engineering, and privacy all have legitimate stakes in SBOM receiving, and the most common failure is assigning the program to a single team that cannot deliver it alone.

The SBOM ingestion infrastructure should sit with the team that runs the rest of the security tooling — the AppSec or DevSecOps platform team — not with procurement. Procurement runs the request side and feeds metadata into the system, but the operating infrastructure belongs in security.

Policy ownership should be senior enough to mediate between competing department interests. A cross-functional steering group meeting quarterly with clear authority is a common structural solution.

Activity	Primary owner	Contributing roles
Define SBOM receiving policy and standards	Security / AppSec leadership	Legal, OSPO, Procurement, Privacy
Vendor onboarding and SBOM delivery clauses in contracts	Procurement / Vendor management	Security, Legal, ITAM
Day-to-day SBOM ingestion and format validation	Security tools / DevSecOps platform team	ITAM, Engineering
Vulnerability triage from SBOM data	Vulnerability management / SecOps	Engineering, Product Security
VEX and CSAF intake and analysis	Vulnerability management / Product Security	Engineering
License and OSS compliance	Open Source Program Office or Legal	Engineering, Procurement
ITAM record linkage	ITAM / SAM team	Security tools team
Audit and regulator-facing evidence	Risk / GRC / Compliance	All of the above

---

Phased Program Model

Small Organization

Phase 1 — Foundation

• Build and maintain a software asset inventory covering all vendors, products, and versions in your environment.
• Identify the five to ten vendors most critical to operations or handling the most sensitive data. These are your Tier 1.
• Request SBOM availability information from each Tier 1 vendor. Determine what formats they support and how SBOMs are delivered.
• Establish a storage location for received SBOMs with version, format, and receipt date recorded for each artifact.

Phase 2 — Operationalize

• Add SBOM delivery requirements to Tier 1 vendor contracts at next renewal. Specify accepted formats (SPDX 2.3 or later, CycloneDX 1.4 or later) and the delivery channel.
• Subscribe to SBOM-related and security advisory communications from each Tier 1 vendor. Establish a process for reviewing VEX statements when issued.
• Develop a vendor questionnaire covering SBOM availability, supported formats, delivery process, and VEX practices. Use it at onboarding and renewal for all critical vendors.

Phase 3 — Scale

• Extend SBOM delivery requirements to all vendors handling sensitive data, not only Tier 1.
• Add SBOM availability and format support as standard criteria in all vendor onboarding.
• If using an MSP, confirm that SBOM ingestion and VEX monitoring are included in the managed services agreement and that findings are reported on a defined schedule.

Phase 4 — Mature

• Establish a vendor SBOM quality baseline: SBOM delivered with each release, in a supported format, with VEX statements issued for disclosed vulnerabilities.
• Evaluate whether your asset inventory and SBOM storage approach should advance to a structured ITAM platform or dedicated SBOM management tool. See SBOM Tooling.
• If operating in a regulated sector, confirm that your SBOM records and vendor documentation satisfy current audit requirements.

Enterprise / Development Org

Phase 1 — Foundation

• Establish policy: accepted formats, minimum required fields, vendor tier definitions, and retention rules.
• Stand up a receiving stack and ingest first-party SBOMs first to validate the pipeline.
• Identify the top 10–20 critical Tier 1 vendors and begin outreach.
• Build asset-record linkage: SKU-level for now, instance-level for Tier 1.

Phase 2 — Operationalize

• Onboard Tier 1 and Tier 2 vendors across at least one full release cycle.
• Correlate SBOM inventory against vulnerability management and begin VEX/CSAF intake.
• Engage the OSPO and legal team on license compliance.
• Connect ITAM/SAM records and align SBOM linkages with procurement records.

Phase 3 — Scale

• Onboard Tier 3 vendors using tier-appropriate contract clauses.
• Generate analyzed SBOMs internally for vendors that cannot or will not produce them. Record the generation method and date.
• Add VEX-based suppression to triage and track SBOM quality scores per vendor.
• Evaluate commercial platforms against the existing open-source stack.

Phase 4 — Mature

• Adopt the Transparency Exchange API where supported.
• Use SBOM quality as a vendor scorecard input affecting renewal and tier decisions.
• Integrate signing and provenance verification into ingestion.
• Evaluate whether the scope should extend to non-software BOMs.

Timelines

For an enterprise development organization, the full progression typically takes two to three years. Programs that compress it tend to over-invest in tooling before process is established. For a small organization, Phase 1 through Phase 2 is achievable within a quarter when ownership is clearly assigned.

---

Metrics

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

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