A customer contract requires an SBOM with every release — what does agreeing commit you to?
answer
- a standing deliverable, not a one-off file
- per shipped artifact, per release
- built from the build, not the manifest
- format, version and channel agreed in writing
- regenerate on patches, keep them for years
basics
~20 sIt commits you to producing an SBOM for every shipped artifact, in the format the customer named, delivered through an agreed channel, regenerated for every patch release, and retained long enough to answer questions about old releases.
solid answer
~50 sIt turns a one-off file into a standing per-release deliverable. Concretely: an SBOM per shipped artifact rather than per repository, generated by the release build itself so it describes what actually shipped rather than what the manifest said, in an agreed format and spec version (SPDX or CycloneDX) with an agreed identifier scheme such as purl, delivered through an agreed channel — alongside the artifact, in a portal, or attached to the release — and regenerated for every patch, because a rebuilt artifact with an old SBOM is worse than none. It also creates a retention duty and a support duty: someone has to still have the release-6-of-last-year SBOM, and someone has to answer the customer's questions about a component in it. Before signing, pin the format, the delivery channel, the scope of 'every release', and how long you keep them.
go deeper
Be ready to say what an SBOM inventories and that a per-release clause means the build produces one every time, for every shipped artifact, in an agreed format.
Explain why a build-time or artifact-derived inventory differs from one read off a manifest, and why format, spec version and identifier scheme have to be pinned rather than assumed.
Show that you would negotiate the scope of 'every release', name the pipeline owner, and arrange durable storage and a retention window before anybody signs the schedule.
Own the portfolio view: one customer's format and delivery terms become the default for every future deal, so decide once what the company will commit to rather than letting each contract invent its own.
## What the clause really says A line in a customer's security schedule such as 'Supplier shall provide a Software Bill of Materials for each release' looks like a document request. It is not. It is an operating commitment with a recurring cost, and the mistake juniors make is treating it as something the security team produces once, by hand, to unblock a deal. An SBOM is an inventory of what is inside an artifact — its components, their versions, their suppliers and how they relate to each other. It is not a statement about how the artifact was built, and it is not a statement that anyone vouches for it; those are provenance and signatures respectively, and they are separate obligations that a different clause would have to ask for. Agreeing to this clause means committing to produce the inventory, repeatedly, for things you ship. ## The five things 'yes' actually costs **1. Per artifact, per release.** Customers receive artifacts, not repositories. If a release ships three installable packages, that is three SBOMs, each describing what is inside that package. A single repo-level dependency list is a different, weaker document, and a customer who tools against it will notice. **2. Generated by the build, not by reading a manifest.** A manifest or a lockfile describes what the source declared. The shipped artifact may contain vendored code, statically linked libraries, base-layer packages and build-time-injected components that no manifest lists. Producing the SBOM from the release build, or from the built artifact, is what makes the document true. Producing it from the source declaration satisfies the letter of the clause and quietly misleads the customer. **3. A format and a version, agreed in writing.** SPDX and CycloneDX are the two formats a customer will name. They are not interchangeable in detail, and converting between them loses fidelity. Pin the format, the spec version, and the identifier scheme used for components — package URL (purl) is the ecosystem-native identifier and is what makes an SBOM machine-matchable against advisories; CPE is the older scheme most vulnerability databases were built around. If the customer names no format, propose the one you already produce and get it written down. **4. A delivery channel.** 'Provide' has to mean something operationally: published alongside the artifact, attached to the release, dropped in a customer portal, or handed over on request within N days. Un-agreed delivery is where this clause fails in practice — the SBOM exists in a build output somewhere and nobody can find it when asked. **5. Freshness and retention.** Every patch release produces a new artifact and therefore a new SBOM; shipping a hotfix and leaving last month's inventory attached is a false statement about what the customer is running. And the customer will eventually ask about a release from a year ago, so the SBOMs have to outlive the CI system's default artifact retention. Storing them with the released artifact, addressed by that artifact's digest, is the durable arrangement; leaving them in a build job's outputs is not. ## What to settle before signing Scope is the cost lever. 'Every release' — does that include internal pre-release builds, or only the packages the customer receives? 'Each product' — the one they bought, or the whole portfolio? Getting a one-sentence written interpretation agreed before signature is cheaper than discovering the broad reading during an audit. Then name the owner. This is a release-pipeline responsibility, not a security-team favour: the release build produces the document as an ordinary step, and the clause is satisfied by automation that keeps working when nobody is paying attention. ## The tell of a weak answer A candidate who says 'sure, we can generate one' has answered a capability question. The clause is not a capability question. The interviewer is checking whether you understand that a one-line contractual sentence creates a per-release step, a storage duty, a retention window and a human on the other end of the customer's follow-up questions — and that you would negotiate the scope of that sentence before somebody signs it.
- The schedule does not name a format. What do you propose and why?Propose the format your release pipeline already emits — SPDX or CycloneDX — and pin the spec version plus the component identifier scheme in the contract. Converting between formats after the fact loses fields and invites disputes about completeness, so the cheapest answer is the one you already automate and can keep producing without a new project.
- Does an SBOM generated from the source manifest satisfy the clause?Only on paper. A manifest describes what the source declared; the shipped artifact can also carry vendored code, statically linked libraries and base-layer packages the manifest never mentions. Generating from the release build or from the built artifact is what makes the inventory describe what the customer actually received.
- The customer asks for the SBOM of a release from two years ago. Are you obliged?That depends entirely on a retention window you should have negotiated. If the contract is silent, the customer's expectation will be 'as long as we run it', which is usually the support life of the release. Set the window explicitly, store the SBOMs with the released artifacts rather than in build-job outputs, and say no to indefinite retention if you cannot fund it.
It is closer to agreeing to print an ingredients label on every box than to writing one recipe document: the label has to come off the same line as the product, every batch.
saying these in an interview costs you the question
- Treats it as a one-time document rather than a per-release deliverable
- Promises a format the release pipeline does not actually emit
- Generates from the manifest and calls it what shipped
- Never agrees where or how the document is delivered
- Says an SBOM also proves how the artifact was built