Vendor SBOM Intake: What to Do With the SBOMs Your Suppliers Send

Buying software now comes with a bill of materials attached. The vendor sends an SBOM, and increasingly an AI-BOM, as part of the contract, the security questionnaire or the release package. It arrives as a JSON file in an email, and it lands in a shared drive.

That is usually where a vendor SBOM stops. Nobody reads it after procurement, nobody checks it when the next advisory lands, and nobody can say which of your applications ship the product it describes. The document was produced to satisfy a requirement, and it did. It was never put to work.

This post is about putting it to work: what a supplier BOM should contain, why it is only useful if it is reassessed as intelligence changes, how to handle a finding that persists across the versions a vendor sends you, where AI declarations fit in a policy, and how a vendor release rolls into your own application's BOM with VEX.

What a vendor SBOM should contain

Two formats cover almost every document you will receive. CycloneDX is an OWASP standard with a JSON and an XML encoding, and it can carry software components, AI components such as models and datasets, and VEX statements in one document. SPDX is the ISO-standardized format from the Linux Foundation, with JSON and tag-value encodings, and it is the one you will see most from vendors with a strong license-compliance background.

The format matters less than the content. The useful test is the minimum-elements idea that CISA and, before it, NTIA defined: a short list of fields without which the document cannot be acted on. The baseline fields for each component are:

• Supplier name of the component, not only of the product.
• Component name and version, and a stable identifier such as a package URL or CPE that a tool can match against advisories.
• Dependency relationships, so a transitive package is distinguishable from a direct one.
• Hashes and licenses for each component.
• Author of the SBOM and a timestamp, so you know who produced it and when.

A document that has a component list but no package URLs, or no relationships, is a text file, not an inventory. Most of the work of assessing it will be guesswork about which package the vendor meant. Ask for the fields before you accept the file. For the fuller picture of what a complete SBOM holds, including license inventory, see our earlier post on what a complete SBOM contains.

Two more things to ask for. The SBOM metadata should name the product and its version, in metadata.component for CycloneDX, so intake can be automated. And ask whether the vendor publishes VEX: a per-vulnerability statement of whether the product is affected, not affected, fixed or under investigation. Without it, every CVE in the document is an open question for you to raise.

Why a vendor SBOM goes stale the day it arrives

An SBOM is a snapshot of what the vendor shipped. The risk in that software is not a snapshot. Advisories are published, exploit evidence appears in CISA KEV, a package is flagged as compromised on a registry, a runtime reaches end of life, or your own license policy changes. None of those events change the document, and all of them change what the document means.

So a vendor SBOM that is assessed once at intake and filed is only accurate on the day of intake. The question a security team needs to answer is a running one: given what is known now, what in this product needs attention, and has the vendor answered for it?

That implies three practices:

1. Keep the document as a record, not a report. Store the original bytes unchanged, and treat the assessment as something separate that is regenerated.
2. Reassess on every input change. New advisories, new exploit evidence, compromised-package feeds, end-of-life data, and your own policies are all inputs. A change to any of them should re-run the assessment of every document whose components it touches.
3. Show freshness. Anyone reading the register should be able to see whether a release was assessed with the latest intelligence or whether an input moved since. "Last assessed" without "against what" is not enough.

This is the same discipline you apply to your own dependency findings. The difference is that you cannot fix a vendor's package. You can only establish the fact, decide what to do, and route the question to the vendor.

Handling a finding that spans document versions

Vendors ship new releases, and each one comes with a new document. If every new file resets the findings, you lose the most useful signal there is: a package that stays vulnerable, or stays outdated, across three vendor releases. That is not a finding to re-triage. It is evidence that the vendor has not addressed it, and that is what you raise with them.

The model that works is to identify a finding by the package, the finding type and the key (the CVE, the license, the end-of-life cycle), and not by the exact component version in one file. When the vendor ships the same package at a newer version with the same issue, the finding continues, keeps its first-seen date and shows which versions carry it. A finding that disappears because the package was removed is "no longer declared", which is not the same as "fixed", and the record should say which.

Decisions follow the same rule: decide once, and review when a later version still carries it. The usual reason for an acknowledgment or an exception on a vendor finding is a promise from the vendor to fix it in the next release. A decision that holds for any version of the package should therefore not stand silently when the next release arrives with the issue still present. It should be flagged for review, with the two choices stated plainly: confirm that the decision still holds, or revoke it and the finding is open again.

A good finding record keeps three voices apart on every row: what the vendor said, what your assessment found, and what you decided. Mixing them is how an "acknowledged" finding turns into a "not affected" claim in an audit six months later.

Where AI-BOM declarations fit in a policy

An AI-BOM declares the models, datasets and provider services a product is built on. For a buyer the question is narrower than for software components: is this product built on a provider or model that our organization does not allow, and did that set change between releases without anyone telling us?

That suggests an AI policy with two short lists, prohibited providers and prohibited models, maintained by whoever owns third-party risk, and applied to every AI-BOM that comes in. A declaration that matches raises a finding on the vendor release, in the same register as a vulnerable package, so a vendor built on a prohibited model shows up beside a vendor shipping a vulnerable library.

Two refinements make the policy useful rather than decorative:

• A change in the AI set is itself a finding. If a new version of the vendor's AI-BOM adds a model, removes a dataset, changes a model's version or moves to a different provider, that is a fact to review even when nothing on the prohibited lists matches.
• Unknown is not pass. A model declared with no version, or a name that matches nothing in a catalog, cannot be judged against license or deprecation rules. The honest result is "unknown", not a green check.

Software dependencies declared inside an AI-BOM still get the normal software rules, so one document can produce both kinds of finding.

Rolling vendor releases into your application BOM with VEX

The last step is the one that gives the register a purpose. Your application is built from your own repositories and ships with vendor products that have their own bills of materials. A customer, an auditor or a regulator asks for one BOM for the product. The honest answer is one document that holds both sides and keeps them apart.

Keeping them apart matters. A component you analyzed in your own code and a component a vendor declared in a file are different kinds of evidence, and the export should mark each with its source, so a vulnerable library in a vendor product is never mistaken for one in your code. In CycloneDX this fits as one assembly per repository and one per vendor release, each with its own dependency graph and no invented edges between them.

VEX is where the discipline is tested. Each vulnerability in the exported BOM can carry an analysis state. Two rules keep the document trustworthy:

• Never claim "not affected" on evidence you do not have. An imported document cannot answer reachability or exposure. If a finding is open, the statement should say it is open. If it closed because the advisory listed the shipped version as fixed, say resolved. If it closed for any other reason, say why, not what.
• Keep the vendor's statement and yours as separate entries. The vendor's VEX for a CVE and your assessment of the same CVE are two statements with two issuers. Merging them hides who said what.

Your own decisions (an acknowledgment, an exception, an accepted vendor answer) ride along as metadata with the reason, who decided and when it expires. They are not verdicts about the software, and the document should not present them as one.

A vendor SBOM intake checklist

What to do with the next file a supplier sends:

1. Check the format and version. CycloneDX or SPDX, a schema version your tooling reads, and no DOCTYPE or external entities in XML.
2. Score it against minimum elements before you look at the components. A sparse document goes back to the vendor with the missing fields named.
3. Record supplier, product and release from the document's own metadata, and keep the original bytes.
4. Assess the components against known vulnerabilities, malicious-package intelligence, your license policy, end-of-life data and your AI policy.
5. Link the release to the applications and services that run it. An unlinked vendor release counts in no application BOM and nobody owns it.
6. Send the vendor the list that needs an answer: the findings with confirmed or probable exploit threat, or critical severity, that carry no vendor statement.
7. Keep it under reassessment, and route material changes (a new finding, a rise in exploit threat, a decision that needs review) to the person who owns the vendor.
8. Export the application BOM with VEX on each release and keep it with the release artifacts.

This is a supply chain security practice and a compliance practice at the same time. DORA, the Cyber Resilience Act and ASVS all expect you to know what third-party software you run and what is wrong with it. A register that is reassessed is how you show it.

How Heeler handles vendor SBOMs

BOM Hub, in Catalog, is Heeler's register of the SBOM and AI-BOM documents your suppliers give you. Import reads CycloneDX 1.2 to 1.7 in JSON or XML and SPDX 2.2 and 2.3 in JSON or tag-value, up to 50 MB, and prefills the supplier, product and version from the file's metadata. The original is stored unchanged. Each version is scored against the CISA 2026, NTIA 2021, G7 AI-BOM 2026 and OWASP AI-BOM minimum-elements profiles, and its components are assessed with the same vulnerability, malicious-package, license and hygiene intelligence Heeler applies to your own code.

A monitored release is reassessed when an advisory, a feed, the catalog or your policy changes, and the register shows whether each release is up to date or stale. A material change arrives as an in-app notification and as a BOM Hub workflow trigger.

A finding is one record across document versions: it shows when it was first seen and which versions carry it. A decision applies to any version of the package or to this version only, and a later version that still carries the finding asks for review. The Findings tab keeps the vendor's VEX statement, Heeler's assessment and your decision apart, with a "Needs vendor response" toggle and a CSV export. See Findings and Decisions.

AI declarations are judged by the AI policy page in Administration, where administrators list prohibited providers and models. A release links to an application or service, and the Export BOM menu on that application produces a CycloneDX 1.6 or CSV document with an assembly for each analyzed repository and each linked vendor release. Application BOM with VEX embeds the vulnerability status of every finding, keeps Heeler's and the vendor's statements as separate entries, and never writes not_affected on Heeler's own evidence. See Application BOM.

For suppliers that publish through the Transparency Exchange API, an administrator binds a product to a remote TEA 1.0 product, and a daily poll brings new releases in as proposals to confirm. From CI, heelercli has bom import, status, list, show, findings, search, compare, download and export commands:

• heelercli bom import vendor/acme-support-4.2.cdx.json --supplier "Acme" --product "Acme Support" --version 4.2 --wait
• heelercli bom export --application "Checkout" -o checkout-bom.cdx.json

FAQ

What is a vendor SBOM?

A vendor SBOM is a bill of materials a supplier provides for software you buy rather than build, listing the components the product contains. It is written by the vendor in CycloneDX or SPDX and describes what was shipped, not what is currently known to be wrong with it.

What is the difference between an SBOM and an AI-BOM?

An SBOM declares software components; an AI-BOM declares the models, datasets and AI provider services a product is built on. CycloneDX can carry both in one document, and a mixed document is assessed under both software rules and AI policy rules.

Why does a vendor SBOM need to be reassessed?

Because the document does not change when the risk does. New advisories, exploit evidence, compromised-package reports and end-of-life dates all change what the same component list means, so an assessment from the day of intake is only accurate on that day.

What is VEX and why does it matter for a vendor BOM?

VEX is a per-vulnerability statement of whether a product is affected, not affected, fixed or under investigation. A vendor's VEX answers the questions its SBOM raises, and your own exported BOM should carry VEX statements that say only what your evidence supports.

Should a decision on a vendor finding carry over to the next release?

Yes, but it should be reviewed, not assumed. A decision that holds for any version of a package should be flagged when a later version still carries the finding, so someone confirms it or reopens the finding.

Vendor SBOMs are only worth collecting if they are kept under assessment and tied to the applications that run them. Heeler's BOM Hub does that: import the file, score it, assess it against live intelligence, carry findings and decisions across versions, and export one application BOM with VEX. Get a demo