Share the SBOM, not the secrets: redaction for customer-facing documents

The strongest objection we hear to sharing SBOMs with customers is not effort — it is exposure. A complete SBOM describes your product's anatomy: internal package names, proprietary modules, sometimes the vendor relationships you'd rather not advertise. Security teams look at that and conclude, reasonably, that a full SBOM in a customer's hands is a reconnaissance document.

The conclusion most vendors draw — share nothing, or share a PDF summary that satisfies nobody — throws away the trust benefits of transparency to avoid the risks of oversharing. There is a middle path, and it is the same one every other disclosure discipline landed on: redaction.

Three verbs: keep, mask, drop

Selective disclosure in SBOMVault comes down to three decisions you can make about any component or field:

1. Keep — the component appears in the shared document exactly as it is. This is the right default for third-party and open-source components: it is what your customer is actually entitled to evaluate.
2. Mask — the component appears, but identifying details are replaced. The customer sees that a proprietary internal library exists, with its license posture and vulnerability status, without learning its name or internal structure. Counts stay honest; secrets stay private.
3. Drop — the component is removed from the shared view entirely.

The discipline matters as much as the mechanism: masking preserves the integrity of the document (totals and risk posture remain truthful), while dropping changes what the document claims. We built the engine so the policy is enforced at export time — every download is re-generated from normalized component data with the policy applied, rather than edited by hand — because the failure mode of manual redaction has always been the field somebody forgot.

Redaction is a policy, not an afternoon

Doing this by hand — exporting JSON, deleting nodes, re-uploading — fails the second time you ship a release, because the manual edit doesn't follow the new SBOM. Redaction has to be defined as a rule set applied automatically to every version, so that the customer-facing view updates when your product does, with the same fields kept, masked, and dropped every time.

That is how it works in our sharing flow: the redaction profile attaches to the share, not to the file. New SBOM, same policy, zero re-work.

The trust argument

Counterintuitively, a redacted SBOM builds more trust than an unredacted one delivered reluctantly. It tells your customer you have an actual disclosure policy — that you know what is in your product, know what is sensitive, and made deliberate decisions about the difference. Procurement teams read that as operational maturity, which is precisely the thing the SBOM request was probing for in the first place.