These questions come from the trenches, the kind of conversations happening in vendor management meetings, procurement reviews, and risk assessment sessions where someone finally asks what everyone's thinking: "We're collecting SBOMs, but what are we supposed to do with them?"
CISA and 15 international partners just published updated minimum elements for Software Bills of Materials (SBOMs), adding 10 new data fields to the 2021 baseline. The revision includes cryptographic hash values, license information, and clearer supplier terminology. More than 90 comments shaped the final guidance. Yet the fundamental challenge remains: the gap between creating these inventories and actually using them to manage risk.
Here's what practitioners are asking.
Q1: We've started requesting SBOMs from vendors. What should we actually check first?
Start by determining if you can answer a single question: if a new vulnerability emerges tomorrow, can you determine from the SBOM whether your software is affected?
The updated guidance requires transitive dependencies, meaning you should see not just the direct libraries but the dependencies of those dependencies. This matters because that's where most vulnerabilities hide. If the SBOM only lists top-level components, you can't make a definitive call on exposure.
Check for component-level detail: producer name, version, and now cryptographic hash values. The hash lets you verify you're looking at the exact build. Without it, version numbers alone can be ambiguous, especially with open-source components that get forked or modified.
Then ask: does this SBOM tell me what I don't have? The guidance explicitly states that if a vulnerable component doesn't appear in the SBOM, you should be able to conclude it's not present. That only works if the SBOM is complete and accurate.
Q2: Our procurement team wants to make SBOMs mandatory in contracts. Is that premature?
It's not premature to require them. The European Union's Cyber Resilience Act already mandates SBOMs as part of technical documentation for products with digital elements, and Germany, India, and Japan have published their own technical requirements. Regulatory pressure is building globally.
But don't stop at "vendor must provide SBOM." Specify the minimum elements you need. Reference CISA's baseline explicitly in your contract language. Require machine-readable formats (SPDX or CycloneDX, typically). Set expectations for update frequency, particularly for SaaS products where code changes constantly.
The harder question is what happens after delivery. If you don't have a process to ingest, store, and query SBOMs, you're just collecting files. Build the consumption workflow before you mandate the requirement, or you'll end up with a folder full of JSON files no one reads.
Q3: We received an SBOM with hundreds of components. How do we know if it's actually complete?
You probably can't verify completeness without tooling. Manual review of a modern application's dependency tree is impractical. Enterprise software can include thousands of components when you account for transitive dependencies.
Look for obvious gaps first. Does the SBOM include only a dozen components for a complex application? That's a red flag. Are all the "Supplier Name" fields (now "Component Producer" in the updated guidance) populated? Missing producer information suggests auto-generated output that wasn't reviewed.
The new baseline adds fields about the SBOM document itself, metadata that describes who created it, when, and using what tool. Check those fields. If the SBOM was generated by a recognized tool and recently updated, that's a positive signal. If it's months old or lacks generation details, question its accuracy.
Longer-term, you'll need automated validation. CISA acknowledges that validating SBOM accuracy is one of four areas flagged for future work. Until that guidance arrives, consider requiring vendors to attest to completeness as part of your contract terms.
Q4: What's the point of collecting license information for each component?
License data helps you manage legal risk, not just security risk. If a component is released under GPL-3.0, and your vendor incorporated it into proprietary software, you might have a compliance problem. If you're in a regulated industry with restrictions on certain open-source licenses, you need to know what's in the stack.
The updated baseline now requires the license under which each component is available. This wasn't in the 2021 version. It reflects a broader understanding that supply-chain risk includes legal and operational dimensions, not just vulnerability management.
From a procurement perspective, license information also reveals maintenance risk. Components under abandoned or obscure licenses may not receive security patches. That's a signal to dig deeper on the vendor's update practices.
Q5: Our vendor says SBOMs don't matter because they patch vulnerabilities quickly. Are they wrong?
They're answering a different question. Fast patching is critical, but it doesn't eliminate the need for transparency about what's in the software.
Here's the disconnect: an SBOM is an inventory. It tells you what's there. What you do with that information, vulnerability correlation, license compliance, incident response, requires additional processes and tooling. Your vendor might patch quickly, but if you don't know what components are running in your environment, you can't validate their claim or make informed decisions during an incident.
Jeff Williams, CTO of Contrast Security and founder of OWASP, points out that almost every application includes a library with an embedded vulnerability, but most of those libraries are never called. They're "dependencies on dependencies" that don't present any risk. An SBOM alone doesn't tell you which vulnerabilities are reachable or exploitable in your specific deployment.
That's the real gap. SBOMs provide the ingredient list, but you still need to understand how those ingredients are combined and which ones actually matter in your risk context.
Q6: Should we be building SBOMs for our own internally-developed software?
Yes, especially if you're subject to regulatory requirements or if your software gets deployed in critical infrastructure. The updated guidance explicitly covers all software types, including open-source code, AI systems, and SaaS.
For internal development, SBOMs serve a different purpose than vendor-supplied ones. You're not evaluating a third party; you're creating a record of your own build. That record becomes essential during incident response. When a vulnerability in a widely-used library is disclosed, you need to know which of your applications are affected. Without an SBOM, you're searching codebases manually or relying on developer memory.
The guidance acknowledges that frequent code changes in cloud environments and continuous-delivery pipelines create challenges. Generating an SBOM with every commit might overwhelm your teams. Focus on production releases and major builds. Automate generation as part of your CI/CD pipeline so it's not a manual lift.
Q7: What should we do with SBOMs once we have them?
This is the question that exposes the adoption gap. Collection is step one. Consumption is where most organizations stall.
You need a system to store SBOMs in a queryable format. When a new CVE is published, you should be able to search across all your SBOMs to identify affected software. When a vendor notifies you of a patch, you should be able to confirm which components changed.
CISA flags correlating SBOM data with security advisories, specifically Vulnerability Exploitability eXchange (VEX) documents, as future work. VEX documents describe whether a vulnerability is exploitable in a specific product context. Pairing SBOMs with VEX data would close the loop between "what's in the software" and "what actually matters for my risk."
Until that guidance arrives, build the workflow manually. Map SBOMs to asset inventory. Tag them by criticality. Establish a process for reviewing them when vulnerabilities are disclosed. Otherwise, you're just accumulating artifacts.
Where to go for more
CISA's updated minimum elements are available now, co-authored by the NSA, FBI, and cybersecurity agencies in 13 other countries. The document includes explicit guidance for cloud, SaaS, and AI systems, though AI-specific fields are still flagged for future development.
If you're building SBOM requirements into procurement contracts, reference the baseline by name and specify machine-readable formats. If you're generating SBOMs internally, automate the process and integrate it into your release workflow.
The hard part isn't creating the list. It's building the muscle to use it when it counts.
