What the TLP label in CycloneDX 1.7 does, and what it does not

The field

In October 2025, CycloneDX 1.7 gave the bill of materials a machine-readable way to say who may pass it on. The release added distributionConstraints to the document metadata. The structure contains one thing, a Traffic Light Protocol classification that, in the schema’s words, “controls the sharing and distribution of the data that the BOM describes.” It takes five values, CLEAR, GREEN, AMBER, AMBER_AND_STRICT and RED, and CLEAR is the default.

The vocabulary is FIRST’s TLP 2.0, the labelling incident responders have used on advisories since the 2000s and which FIRST tightened in 2022, when CLEAR replaced the older WHITE. Ecma adopted 1.7 as ECMA-424’s second edition in December 2025, so the label ships in the standard rather than in an extension. [EDITOR: the originating request is believed to be specification issue 595. Verify the number and summarise the thread’s reasoning here before freeze.]

What it solves

Sharing state used to be ambient, a footer in the transmittal email or a suffix in a filename, and it was lost at the first re-save. Anyone who has watched a TLP:AMBER PDF get forwarded knows the old enforcement model was hope.

Inside the document, the label survives copying, and tooling can act on it. A portal can refuse AMBER content at an anonymous endpoint, a pipeline can block an export that crosses a tenant boundary, and an aggregator can show it honoured the marking. The 1.7 release also put the label in the right place, document metadata, because pass-it-on permission is a property of the document as shared, not of any field inside it.

What it is not

No BOM specification models content sensitivity today, and none claims to, the 1.7 label included. Three boundaries mark what the field leaves untouched.

A content-sensitivity model. The label scopes the whole document and says nothing about which fields are dangerous in combination. Our own worked fragment shows the shape of the problem. A named path, a blocking counterparty and a negotiated TLS 1.3 exchange are three mundane fields that jointly locate the exchange that has not migrated, and the counterparty that blocks it. One document-level label can’t price a combination, and combinations are what make a CBOM sensitive.

A redaction profile. One estate answers to several audiences, and the regulator’s copy is not the supplier’s copy. TLP marks one document. Nothing in the schema derives the regulator’s view from the internal record or says which fields leave and which stay.

The distinction a redaction vocabulary starts from arrived this July from another direction. CISA’s 2026 Minimum Elements requires unknown information to be identified explicitly, which separates unknown from withheld. A record that can’t tell those apart corrupts the risk arithmetic and the reader’s trust at once.

Handling guidance. A label travels with the document, and every control that gives it force belongs to the receiver. Storage, access, logging, retention, and what happens when someone queries ten thousand records at once, none of that is in the schema. None of it should be, because an inventory format isn’t a security policy. The silence is correct, and it is the reason handling needs a document of its own.

Where CERT-In got further

One regulator has gone past the label. India’s CERT-In, in version 2.0 of its Technical Guidelines from July 9, 2025, treats BOM repositories as sensitive systems in their own right. Section 5.3 requires role-based access control and a split between public and private BOM views, with access logging under clause 5.3.6.

That is the furthest any published guidance takes BOM handling, and it still stops at category level. It defines no field-level sensitivity and no audience-specific redaction, and it says nothing about aggregation, the exposure that appears only when records are queried together. The three boundaries above stay open under the strictest guidance in print.

What we intend

We intend to do the next piece of this on cbomprofile.org, as a family-level annex rather than a Profile version. The material to build on is already public – 1.7’s sharing label and CERT-In’s repository handling, plus CISA’s unknown-versus-withheld distinction. An annex that ignored any of them would be reinventing work that exists.

The annex we intend has no version number and no date in this post, and that’s the point of calling it intent. One date does explain the timing, though. Under Executive Order 14412, CISA has until March 19, 2027 to publish minimum-elements guidance for cryptographic bills of materials. Positions we want reflected in it need to be public and citable well before then, which is why this post exists now rather than next spring.

What to do today

None of this waits for the annex, and none of it waits for us. Set distributionConstraints on every CBOM you emit, even when the honest value is CLEAR. Split public and private views the way CERT-In already requires. And record a withheld value as withheld, never as unknown, so the data you publish stays trustworthy when redaction becomes a requirement rather than a question.