Distribution and confidentiality
What the Regulation requires — and does not
Requires: that the SBOM be in the technical documentation, held at the disposal of market surveillance authorities.
Does not require: publishing it, nor systematically providing it to customers.
Does provide, however: that the information to the user state, where applicable, where the SBOM can be obtained (Annex II). The wording therefore presupposes that the question has been settled and can be answered.
The debate: does an SBOM help the attacker?
The argument against publication is that an SBOM reveals the exact composition of the product and makes targeting easier. It deserves examination, not dismissal.
What weakens it:
- a motivated attacker determines a binary’s composition by analysis, without your help;
- component vulnerabilities are public by construction;
- the asymmetry works against you if you do not know your own composition as well as the attacker does.
What strengthens it:
- a dated public SBOM makes it easy to spot products that have not been updated;
- it facilitates mass targeting by automated market scanning;
- it may reveal trade-secret information — architecture, suppliers, technical choices.
A reasonable position: the SBOM is not a secret, but broad distribution without accompanying VEX is poor practice. Publishing a raw inventory without saying what is exploitable transfers the noise to your customers.
Disclosure levels
| Level | Recipient | When |
|---|---|---|
| Internal | Teams, steering platform | Always |
| Authorities on request | Market surveillance, notified body | Mandatory |
| Customer under NDA | Large account, regulated sector | On contractual request |
| Customer via authenticated portal | Installed base | Recommended standard policy |
| Public | Everyone | Explicit decision, product by product |
The authenticated portal is the right default balance: it satisfies legitimate customer demand, logs access, and allows the SBOM to be supplied with the VEX statements and advisories, which is far more useful than an inventory on its own.
Contract clauses
On the customer side, what must be written:
- the format and version supplied;
- the depth covered, and an honest completeness declaration;
- the update frequency — per shipped version, or at a defined interval;
- access arrangements: portal, on request, with or without authentication;
- confidentiality and a prohibition on redistribution;
- the relationship with security advisories and VEX statements.
On the supplier side, the mirror clauses you require are in Contract clauses.
Confidentiality on the authority side
The Regulation frames the use of information obtained by authorities, notified bodies and ENISA: it is handled with respect for trade secrets and intellectual property rights, and used only so far as necessary to carry out their tasks.
That does not remove the need to mark transmitted documents explicitly and to log exchanges.
The decision matrix
| Criterion | Towards restriction | Towards openness |
|---|---|---|
| Nature of the product | Security component, critical product | Consumer product |
| Installed base | Small and identified | Large and anonymous |
| Customer demand | Absent | Contractual and recurring |
| Maturity of your VEX practice | Low: publishing would create noise | High: publishing reduces enquiries |
| Positioning | Composition secrecy is an advantage | Transparency is a commercial argument |
The decision is taken per product, documented, and reviewed annually. It belongs jointly to Legal and product management, not to engineering alone.