A vendor gave you an SBOM once at contract signature — what is it still worth a year on?
answer
- snapshot, not a subscription
- one artifact, one moment in time
- vendor has released since then
- proves capability, not current state
- needs per-release delivery to be live
basics
~20 sLittle, as a live inventory. An SBOM describes one build at one moment, so after a year of vendor releases it need not match the version you run. It survives as a baseline and as proof the vendor can produce one.
solid answer
~50 sAn SBOM is a point-in-time inventory of one artifact, not a subscription. The moment the vendor ships a new release, the document describes a build you may no longer run — and nothing inside the document tells you that. So a signature-time copy answers historical questions: what was in that version, and roughly how deep the vendor's visibility into its own dependencies goes. It also proves the vendor's build can emit an inventory at all, which is a real maturity signal about the supplier. What it cannot do is answer `am I exposed to the advisory published this morning`, because you cannot tell whether the listed components are the running components. To make it a control you need delivery for every released version, a refresh obligation triggered by new advisories, and the document tied to the specific version you deployed.
go deeper
Be ready to say in one sentence that an SBOM covers one build at one moment and does not update itself. Knowing that much already separates you from candidates who treat a vendor document as a live feed.
Explain the mechanics: why nothing inside the file signals staleness, why the document must be tied to a released version to be usable later, and why signing changes trust in the copy rather than its freshness.
Show what you would actually do with a stale supplier document — reclassify it as due-diligence evidence, diff it against the next delivery, and specify the delivery and refresh obligations that would make it operational.
Own the framing that a one-time inventory buys supplier assurance while a per-release stream buys incident response, and be able to say which of the two your organisation is paying for across its vendor base.
## What an SBOM is, precisely A software bill of materials (SBOM) is a machine-readable list of the components inside **one artifact, as it was built at one moment**. The two widely used formats are SPDX and CycloneDX. Both name a subject — this container image, this installer, this firmware build — and enumerate what went into it, ideally with versions and identifiers such as a purl (`pkg:npm/[email protected]`). The crucial property for a consumer is the one people skip: **it is an inventory, not a feed**. Nothing in the file changes when the vendor ships next Tuesday. There is no expiry date inside it that makes staleness visible, and no mechanism by which a copy sitting in your procurement folder learns that version 4.2 replaced version 3.9 six months ago. Keep the three artifact kinds straight, because mixing them up is the canonical wrong answer in this domain: | Document | Question it answers | | --- | --- | | SBOM | What is **inside** this artifact | | Provenance | **How** this artifact came to be — what built it, from what source | | Signature | **Who vouches** for it, and that it was not altered | A signature-time SBOM answers only the first, and only for the build it was generated from. ## The three questions a consumer actually has 1. *What is in the thing I am running right now?* 2. *Does the advisory published this morning affect me?* 3. *Where else in my estate does this component run?* A one-year-old document can contribute to none of these with confidence. For (1) and (2) you would be reasoning about the build the vendor shipped a year ago; if you have upgraded since — or if the vendor pushed a hosted update you never chose — your conclusion is about a version nobody runs. Worse, the failure is silent: the analysis completes, produces a tidy answer, and the answer is about the wrong artifact. ## What the one-time copy is genuinely good for It is not worthless, and saying so is the mark of a candidate who has actually done vendor work: - **Evidence about the supplier.** A vendor whose build can emit an inventory has a build that knows its own inputs. That is a maturity signal independent of the contents. - **A baseline to diff.** When the next document arrives, the delta tells you what they added, dropped or upgraded — often more informative than either document alone. - **The shape of the stack.** Which runtime, which frameworks, whether third-party code dominates, roughly how far down their visibility reaches. That shapes what you ask for next. - **Negotiating material.** Once a vendor has produced one, `we cannot produce one` is off the table at renewal. ## What it cannot do, even when fresh - It does not tell you the components are **vulnerable or safe**. That comes from matching the listed components against advisory data, and whether a match is actually exploitable in the product is a separate claim the vendor has to make in a separate document. - It does not tell you the artifact you deployed is the artifact it describes, unless the document is bound to that version — ideally to the artifact's digest, not just a version string. - A **signature on the document** does not refresh it. Signing tells you who vouches for the file and that it has not been tampered with; a perfectly signed inventory of last year's build is still last year's build. - It says nothing about **how** the artifact was built or by whom. That is a different document entirely. ## Turning it from a folder item into a control The fix is contractual and operational, not technical cleverness: - **Per released version**, not per major release and not `on request`. - **An event trigger with a deadline** — a short, counted window after an advisory affects a listed component — rather than a purely calendar cadence. - **Retention and tooling rights**, so you may store it, query it and show it to auditors. A document you may read but not keep is not a control. - **Binding to the artifact**, so you can tell which document describes the build you deployed. ## The interview trap Candidates say `we have the vendor's SBOM` as if it were an inventory of their own estate. It is a snapshot of one of the vendor's builds. Say the word *snapshot* out loud, then say what makes it live.
- Does a signed SBOM stay useful longer than an unsigned one?No. A signature tells you who vouches for the document and that it has not been altered in transit; it says nothing about whether the contents still describe the build you run. Signing raises confidence in the copy, not its freshness. Freshness comes from a delivery obligation per released version plus a way to match each document to the deployed artifact.
- The vendor says their inventory is continuously updated on a portal. What do you check?Ask what event triggers an update, and whether each document is tied to a specific released version. A portal that only ever shows the latest build is useless if you are two releases behind. You want one retrievable document per shipped version, so you can answer questions about the build you actually deployed rather than the one they ship today.
- So is a one-time inventory worthless?No, but reclassify it. It is due-diligence evidence about the supplier — proof their build can enumerate its inputs, a view of the shape of their stack, and a baseline to diff against the next delivery. What it is not is an inventory of what you are running. Treat it as a supplier signal, not as operational data.
It is a receipt for one shopping trip, not a live view of the pantry. Useful proof of what was bought that day; useless for deciding what is on the shelf now.
saying these in an interview costs you the question
- Treats a delivered SBOM as a live inventory of the vendor's product
- Assumes the document updates itself when the vendor ships a release
- Says a signature on the document makes its contents current
- Cannot state what an SBOM describes: one artifact, one build
- Reads an SBOM as a list of the product's vulnerabilities