An internal team edits components out of the SBOM it uploads to a customer's procurement portal. How do you stop that?

## Name the problem correctly This is not a completeness problem. A trimmed inventory is a **misrepresentation** — the organisation has made a claim about a product to a customer that it knows to be false. The relevant property is non-repudiation: can anyone, later, establish what was actually shipped and what was actually claimed? Framing it as "our SBOM quality needs work" is how this gets handled as a hygiene ticket rather than as the integrity failure it is. ## Why people trim Before designing controls, understand the pressure, because a control that fights an incentive loses slowly. Teams trim because: - The customer's portal counts findings and gates the deal on the total, so every accurately reported component with an open advisory costs money. - A component is genuinely not exploitable in the product, and deleting the row is the fastest way to stop arguing about it. - The inventory contains something commercially awkward — an old runtime, a component from an unwelcome origin. - The document was assembled by hand in the first place, so editing it feels like normal work rather than falsification. Only the second has an honest alternative in the same channel: a documented exploitability statement says "present, and here is why it does not affect the product" without touching the inventory. If your organisation does not use that channel, deletion is the only tool people have, and they will use it. ## Preventive controls: take away the hands 1. **Generate in the pipeline, not on a laptop.** The inventory is produced by the same run that produces the artefact, from that run's inputs. 2. **Bind it to the artefact.** The document names its subject by content digest. A document that cannot be tied to a specific released build cannot be checked against anything, and a trimmed one is indistinguishable from a legitimate one for a different build. 3. **Retain it as an immutable, addressable artefact**, stored where the shipping team cannot rewrite it. 4. **Deliver by reference, not by attachment.** The portal upload — or the customer-facing service that feeds it — fetches the stored document. The moment a human downloads, opens and re-uploads a file, every other control is decorative. 5. **Sign it.** A signature establishes who vouches for the document, so the customer can verify that what they hold is what you published, and so the publisher cannot later disown it. Signing without anyone verifying changes nothing, so the customer-facing instruction to verify is part of the control. ## Detective controls: assume the preventive ones leak Preventive controls fail quietly — an exception path for the one customer whose portal needs a different format, an urgent release with the pipeline broken. So: - **Independent re-derivation.** Someone outside the team that ships pulls a sample of released artefacts and derives an inventory independently, then diffs it against what was delivered. A systematic omission shows up as the same components missing across releases. - **Diff successive deliveries.** A component that disappears between two versions with no corresponding change in the build is a question worth asking automatically. - **Make the reviewer's finding land somewhere with teeth.** An audit finding that routes back to the team that caused it, with no escalation path, produces a nicer-looking document next quarter rather than a truer one. ## The organisational layer, which is the real question The reason this sits with a lead rather than an engineer is that all of the above costs money and none of it works against a sustained incentive to lie. - **Someone must own the claim.** Decide who signs — a named role, not a service account — and make it clear that the signature is an assertion the company will be held to. Regimes such as the EU Cyber Resilience Act place obligations on the *manufacturer* to document what a product contains, which means an inventory you shipped may be a statement you have to stand behind long after the deal closed. - **Fix the customer-facing conversation.** If you can only pass a procurement gate by understating the inventory, escalate that to the commercial relationship instead of solving it in a text editor. A supplier that explains why a component is present and unexploitable is in a far better position than one caught having removed it. - **Decide the blast radius.** If trimming has already happened, the question is which customers received which documents and whether corrected ones must be issued — an unpleasant call that belongs to someone who can make it, not to the team that made the edit. The short version of the strategy: make the truthful path the *easy* path, make the untruthful path structurally hard, and check anyway.