SBOM requirements: who is actually asking, and for what

SBOM requirements arrive from three directions, and confusing them produces a lot of unnecessary work. Government procurement rules require suppliers of software to federal agencies to provide component inventories. Sector regulators — notably in medical devices and, increasingly, in products sold into the European market — impose their own obligations. And, most commonly for ordinary software companies, enterprise customers write the requirement into contracts and vendor questionnaires.

The third route is the one most teams actually meet, and it has a useful property: the requirement is whatever the contract says. Rather than trying to satisfy an abstract standard, read the clause. It usually specifies a format, a delivery mechanism, an update cadence on new releases, and sometimes a commitment to notify on newly discovered vulnerabilities — and those specifics are far easier to build against than a general aspiration.

What SBOM requirements usually cover

• Minimum data elements — supplier, component, version, identifiers, dependency relationships, author and timestamp.
• Format, named or left open between the two established standards.
• Delivery: on request, with each release, or through a portal.
• Update cadence, and whether an SBOM is required for patch releases as well as feature releases.
• Depth: direct dependencies only, or the full transitive tree, which is a materially different obligation.
• Handling of proprietary components, where the requirement and your confidentiality interests can conflict.
• Sometimes an accompanying statement of exploitability for known vulnerabilities.

Confidentiality is a legitimate negotiation

An SBOM reveals your dependency choices, which is commercially sensitive and, in the wrong hands, an attack map. That is not a reason to refuse — it is a reason to agree the terms: sharing under the existing confidentiality provisions, delivery through a controlled channel rather than email, and restrictions on onward distribution. Customers with mature programmes expect this conversation; the ones who do not have one usually accept the first reasonable proposal.

Answer the requirement you actually have. Teams read about federal procurement rules and build a programme sized for them when their real obligation is a clause in three enterprise contracts. Start from the clauses you have signed, and generalise only when a second requirement genuinely differs.

Vulnerability disclosure usually rides along

A requirement to supply an SBOM is frequently paired with one to notify the customer when a component in it is found to be vulnerable, within a stated period. That is the more demanding half, because it implies monitoring the components you shipped rather than only the ones in your current build. Check whether the clause creates that obligation before agreeing to it, and if it does, make sure the released SBOMs are retained where the monitoring can reach them.

Keeping the commitments straight

Ettex Docs holds the standard SBOM and disclosure language you are willing to agree to, with version history, so each contract negotiation starts from a known position; Ettex Records keeps the per-customer commitments alongside the SBOMs actually delivered and when; and the artefact itself is the software bill of materials described in cyclonedx.

To be clear: this is documents and records, not legal or compliance advice. What a specific regulation requires of a specific product is a question for counsel and for the regulator’s own guidance, and the rules in this area have been changing steadily.