Ask an SBOM management vendor how it generates SBOMs, which formats it reads and writes, how it shares them, how it links components to vulnerabilities, and what it cannot do. Good answers are specific and testable in a trial. Vague answers about coverage are a warning sign.
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. The tooling market ranges from simple generators to platforms that store, compare and act on those inventories. These questions work on any of them, and we name no vendors.
Which questions matter most?
1. What do you generate, and what do you only import? Some tools build an SBOM from source or an image. Others only ingest files you supply. You need to know which, because a tool that cannot generate leaves you dependent on suppliers for every file.
2. Which formats do you read and write? The two common ones are SPDX and CycloneDX. Ask about versions, and whether export is lossless. Round-trip a real SBOM and diff it.
3. How deep does transitive resolution go? A shallow tree hides the library three levels down that carries the CVE. Ask for a test on a project you know has a messy graph.
4. What ecosystems and artifact types are covered? Language packages, container layers, binaries and firmware are different problems. If you ship devices, ask specifically about firmware.
5. How do you match components to vulnerabilities? Ask about identifiers (purl, CPE), which advisory sources feed the match, and how often data refreshes. Ask how false matches are handled.
6. Do you support VEX? CISA describes a Vulnerability Exploitability eXchange document as an attestation, a form of advisory indicating whether products are affected by known vulnerabilities. Support for reading and producing VEX lets you say "not affected" with evidence instead of leaving every finding open.
7. How are SBOMs shared and access controlled? Customers and auditors will ask for yours. Look for per-recipient access, expiry, and an audit trail of who downloaded what.
8. What is the update model? An SBOM is a snapshot. Ask how it is regenerated per build, how versions are retained, and how you diff two releases.
9. Where does the data live and what leaves your network? Some tools scan locally and upload only results. Others need your source. Choose against your own rules, and ask about regional hosting and air-gapped options if you need them.
10. What are the honest limits? Ask what the tool does badly. A vendor who can name gaps, such as coverage of a language, or no runtime view, is easier to trust than one who cannot.
How should you test the answers?
Do not rely on a demo repository. Bring one project you know well, with known quirks. Generate the SBOM, then check three things by hand: pick ten components at random and confirm versions, pick one deep transitive dependency and confirm it appears, and pick one known vulnerable package and confirm it is flagged with the right fix version.
Then try the sharing flow as if you were the customer receiving it. The experience of the person on the other end is often where products feel unfinished.
The older NTIA material on software component transparency remains a good vocabulary reference. It covers SBOM options and decision points, tool classification and use cases from the point of view of those who make, buy and operate software.
What to do
- Write your requirements: formats, ecosystems, hosting, sharing and audit needs.
- Pick one real project and one container image as the test set.
- Send the ten questions to each vendor in writing and keep the answers.
- Run the same test set through each tool and compare outputs, not slides.
- Verify ten components, one deep dependency and one known vulnerability by hand.
- Test export and import in both formats with a third-party tool.
- Score vendors on gaps they admitted, not only on features they claimed.
Quick check
Is an SBOM the same as a vulnerability scan?
No. An SBOM is an inventory of components. A vulnerability scan matches that inventory against advisories. Many tools do both, but they are different outputs.
Why ask about VEX?
A VEX statement can record that a product is not affected by a known vulnerability, which cuts noise for you and for your customers.
Sources
- Software Bill of Materials (SBOM), CISA, fetched 18 October 2026
- Software Bill of Materials, NTIA, fetched 18 October 2026
Last reviewed: 18 October 2026.
