# Vendor SBOM Verification, Step by Step: The NTIA Elements and the Vulnerability Match > A vendor hands you a Software Bill of Materials at the procurement checkpoint. Receiving the file is half the checkpoint. The other half is checking it: whether it contains the seven minimum elements a regulator or buyer can actually use, and whether the components inside it carry known vulnerabilities today. Here is the check, step by step, in the order a buyer should run it, with what each gap means and what to do when you find one. - **Published**: 2026-10-26 - **URL**: https://vendorquals.com/blog/vendor-sbom-verification --- # Vendor SBOM Verification, Step by Step: The NTIA Elements and the Vulnerability Match *A vendor hands you a Software Bill of Materials at the procurement checkpoint. Receiving the file is half the checkpoint. The other half is checking it: whether it contains the seven minimum elements a regulator or buyer can actually use, and whether the components inside it carry known vulnerabilities today. Here is the check, step by step, in the order a buyer should run it, with what each gap means and what to do when you find one.* ## Key takeaways - **Two regimes now make the SBOM a requirement, not a courtesy.** FDA section 524B requires an SBOM covering commercial, open-source, and off-the-shelf software components in every cyber device premarket submission, and the EU Cyber Resilience Act requires a machine-readable SBOM in the technical documentation of products with digital elements, with the main obligations applying from December 2027. - **The NTIA minimum elements are the checklist FDA references.** Seven fields, published July 12, 2021 under Executive Order 14028: supplier name, component name, version, other unique identifiers, dependency relationship, SBOM author, and timestamp. An SBOM missing any of them is a file, not evidence. - **The unique identifier is the element buyers skip, and it is the one the check turns on.** Without a purl or CPE per component, no vulnerability database can match what you are holding against what is known. The component list becomes uncheckable the day you receive it. - **The vulnerability match is live data, not a stamp.** An SBOM verified yesterday can be wrong today: vulnerabilities publish hourly. The check is a query against current databases (OSV, NVD), and it is worth re-running whenever a component lands in the news. - **The check is now free and browser-side.** [The Vendor SBOM Checker ->](/tools/sbom-checker) parses a CycloneDX or SPDX file locally, validates the seven elements, and matches every purl-carrying component against Google's OSV database. Nothing is stored. ## What you are holding A Software Bill of Materials lists the components inside a piece of software, machine-readably. The two formats that dominate are CycloneDX (an OWASP project, standardized by Ecma International as ECMA 424) and SPDX (a Linux Foundation standard), and both ship open-source validators. CISA maintains the federal guidance on what an SBOM is and the levels at which it can be generated: from source code, from the build pipeline, or by analyzing the finished artifact. What the vendor owes you at the checkpoint is a file you can check: a stated format, components with names and versions, and the identifier fields that make each component traceable. What you owe yourself is the check. A file that arrives unopened and gets filed is an artifact, not a control. ## Step 1: The format check Open the file and confirm what it is before anything else: - **CycloneDX JSON** carries a `bomFormat` field set to `CycloneDX`. - **SPDX JSON** carries an `spdxVersion` field starting `SPDX-`. - If it is neither, it is a PDF or a screenshot or a spreadsheet, and you send it back: the machine-readable formats exist precisely so that this check can run without a human reading prose. FDA's guidance recommends machine-readable SBOMs consistent with the NTIA minimum elements, and both standard formats can satisfy that. The format question takes ten seconds and settles whether anything that follows can be automated. ## Step 2: The seven NTIA elements, one by one The National Telecommunications and Information Administration published the minimum elements on July 12, 2021, under Executive Order 14028, and FDA's premarket cybersecurity guidance recommends SBOMs "consistent with" them. Here is each element, what it is for, and what its absence means: **Supplier name.** Who is behind each component. Without it you cannot distinguish the vendor's own code from a dependency they inherited, and you cannot know whose advisory to watch when something lands in the news. **Component name.** The common designation. Missing names mean the vendor generated the list without completing it, and you cannot match what you cannot name. **Version.** Enough to tell this build from the last. A component list without versions is an inventory that cannot be aged: the single most common gap, and the one that quietly makes every vulnerability match a guess. **Other unique identifiers.** A purl (package URL) or CPE per component. This is the element the whole vulnerability match turns on: purls are what databases like OSV resolve. Components without one cannot be checked, today or ever, and an SBOM full of them is a list of names you cannot act on. **Dependency relationship.** What depends on what. When a component turns up vulnerable, the relationship data is what tells you whether the vulnerable library sits in a code path your product actually executes, or in a dependency of a dependency that nothing calls. **Author of the SBOM data.** Who produced the document and with what tooling. The difference between "generated by the vendor's build pipeline" and "typed by a sales engineer" is the difference between a bill of materials and a brochure. **Timestamp.** When the SBOM was generated. This is the staleness clock: an SBOM is a photograph of the build at a moment, and every advisory published after that moment applies to the file you are holding until the vendor regenerates it. FDA adds two fields per component on top of the NTIA list: the software level of support and the end-of-support date. Those two answer the question the seven elements do not: is this component alive, or is it a fossil the vendor still ships? ## Step 3: The vulnerability match With the elements checked, match every component against the live vulnerability databases. The practical mechanics: - Components with a purl resolve directly against **OSV** (osv.dev, the open source vulnerability database Google operates), which aggregates advisory data from a wide set of upstream sources including the NIST National Vulnerability Database and GitHub security advisories. - Each match returns the advisory identifiers (GHSA and their CVE aliases), a summary, and severity where published, with links to the full records. - The match reflects today. Vulnerabilities publish continuously, so the honest posture is a re-run when a component makes the news, at the renewal checkpoint, and before any submission that includes the SBOM. The result that matters is not the raw count of vulnerabilities (every mature dependency carries some), it is the shape: which components, how severe, and how deep in the dependency tree the affected ones sit. One critical in a directly-used library outranks a dozen lows in a leaf dependency. ## Step 4: What to do with the gaps Three outcomes, three actions: **The file is incomplete.** Send it back with the specific missing elements named. "The SBOM is missing version data for 14 components and has no dependency relationships" is a request the vendor can act on; "the SBOM is inadequate" is not. **The file checks out, and vulnerabilities exist.** Route them the way your contracts say they should be routed: the vendor's disclosure clock, the patch timeline, and the contract clause that obliges them to tell you when they know. If those clauses do not exist yet, they should: [what your vendor contracts must say about breach response ->](/blog/vendor-contracts-breach-response-clauses). **The file checks out, and a critical sits in a component you actually use.** That is a procurement conversation, not just a security ticket: whether the vendor will patch, when, and what the contract says about the timeline. For regulated products, the postmarket vulnerability plan FDA requires is exactly where this lands. For everyone else, it lands in the next RFP. ## The two regimes that make this mandatory **FDA section 524B** (for cyber devices sold in the United States): the SBOM is a statutory requirement in premarket submissions, covering commercial, open-source, and off-the-shelf components. Our [524B buyer's guide](/blog/fda-524b-compliance-help-guide) covers the full submission picture and how to vet the sellers who offer to produce this for you. **The EU Cyber Resilience Act** (for products with digital elements sold in the EU): a machine-readable SBOM covering at least the top-level dependencies, kept in the product's technical documentation, with the main obligations applying from December 2027. If your vendor sells into Europe, the SBOM question stops being a diligence nicety and becomes a market-access requirement with a date on it. ## Frequently asked questions **What is the difference between an SBOM and a vulnerability scan?** An SBOM is an inventory: what is inside the software, as of a moment. A vulnerability scan is a query: which of those components carry known issues, as of now. The SBOM is the input; the scan is the check. You need both, and the SBOM has to exist before the scan can run. **Can I trust the vendor's SBOM without checking it?** No, and that is not cynicism, it is the design. Regulators reference the NTIA minimum elements precisely because self-attestation proved unreliable: incomplete lists, missing versions, absent identifiers. The check is cheap; the trust is not earned without it. **What if the vendor will not provide an SBOM at all?** Ask in the language they answer to: contract clauses and, where applicable, the regulatory requirement. [How to request an SBOM from a vendor ->](/blog/how-to-request-sbom-from-vendor) **How often should I re-check a vendor's SBOM?** At minimum: at procurement, at renewal, and whenever a component in it makes the news. A machine-readable file is cheap to re-check; the expensive check is the one you have to do by hand. **Does this apply to internal software too?** Yes, but the mechanics differ: for your own builds, the SBOM comes from your pipeline (Syft, Trivy, cdxgen, or build-time recording), and the check runs in CI. The checkpoint described here is the one you cannot generate your way past: software you bought, from a vendor, with no pipeline access of your own. Check a vendor's SBOM yourself, in your browser, nothing stored. [Check an SBOM ->](/tools/sbom-checker) Buying for a regulated vertical? [Send the structured RFP ->](/rfp/medtech-524b) --- *The requirements here reflect the NTIA minimum elements document (July 12, 2021, under EO 14028), FDA section 524B and its premarket cybersecurity guidance chain, the EU Cyber Resilience Act as published, and OSV.dev as operated, as last reviewed; regulations and advisory databases change continuously, so verify current requirements before relying on them. Last verified: October 2026. Have a correction or addition? [Request inclusion or a correction ->]* Source: https://vendorquals.com/blog/vendor-sbom-verification. This page is also served as HTML at https://vendorquals.com/blog/vendor-sbom-verification. --- - [All articles](https://vendorquals.com/blog)