To test SBOM quality in an RFP, ask vendors to export a real SBOM from your sample repository and check it against the NTIA minimum elements: seven data fields, machine-readable formats, and agreed practices for frequency, depth, and known unknowns. A vendor that says "we support SBOM" has told you nothing yet.
What the minimum elements actually say
The 2021 NTIA report groups the minimum elements into three areas. Data fields are Supplier, Component Name, Version, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp. Automation support means machine-readable formats, and the report lists SPDX, CycloneDX, and SWID tags. Practices and processes cover Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.
CISA's site now references a 2026 version of the minimum elements. We could not retrieve that document, so check it directly if you need the current text. The 2021 list is still a sound basis for RFP questions.
Eight questions
- Which formats can you export, and which versions? Compare the answer with what your downstream tools can read. CycloneDX, for instance, is published as ECMA-424, and its site listed version 1.7 when we checked.
- Export an SBOM for our sample repository. Which of the seven data fields are populated for every component?
- How do you identify a component: by name and version only, or also by package URL or hash? Identifiers matter because they let other tools map the same component to vulnerability data.
- How deep does the dependency graph go? The NTIA text says a minimum SBOM lists all top level components with enough detail to find transitive dependencies, and going further gives more information.
- When a build changes, is a new SBOM generated automatically? The report says a new build or release needs a new SBOM.
- How do you mark parts of the graph you could not resolve? The report calls these known unknowns and says the author must identify them explicitly.
- Can we import SBOMs from our own suppliers and combine them with ones you generate?
- Who can access exported SBOMs, and can we restrict sharing to specific customers?
What good output looks like
Run the export on a repository you know well. Pick one with a lockfile, a few transitive dependencies, and one unusual package such as a vendored library or a container base image.
Then check:
- Does the component count roughly match what you expect from the lockfile?
- Are versions exact, not ranges?
- Are licenses present where the package declares one?
- Does the relationship data show which package pulled in which?
- Does the tool say what it could not see, such as a binary with no manifest?
An SBOM that lists 40 components when your lockfile has 400 is a coverage problem, not a format problem.
Scoring tip
Score three things separately: completeness (did it find everything), correctness (are the fields right), and usability (can your other tools consume it). A tool can be strong on one and weak on another. For ideas on turning this into numbers, see how to build a weighted scoring rubric.
Safeguard generates SBOMs from dependency scanning, and you can try a sample at https://gold.safeguard.sh/scan before you write your own test.
Sources
Quick check
Is an SBOM the same as a vulnerability report?
No. An SBOM lists components. A vulnerability report matches those components against known flaws. Good SBOM data makes the second one more accurate.
Do we need both SPDX and CycloneDX?
Not always. Choose the one your consumers need, and ask whether the tool can convert between them.
Last reviewed: 19 October 2026.
