TLP Is Not a Suggestion

The TLP exists so that people who distrust one another commercially can still share what they know about an active threat. It was created in 1999 by the United Kingdom's National Infrastructure Security Co-ordination Centre, standardized by the Forum of Incident Response and Security Team (FIRST) in 2015, and revised to version 2.0 in August 2022 after a working group of more than 50 incident responders rewrote the definitions for clarity (FIRST release, CERT-EU primer). 

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) adopted 2.0 for US government sharing, the Information Sharing and Analysis Centers (ISACs) adopted it for sector sharing, and FIRST membership is conditional on using it.

The TLP’s four labels are simple, and the simplicity is the point (Table 1).

^{Table 1: The four labels of the TLP and what they mean}

The mechanism for breaking the discipline is the same in each case. Privileged information left the circle it was given to, and the people outside that circle paid for it (Table 2).

^{Table 2: Examples of vulnerability disclosures that violated embargoes, and the resulting impact}

A pattern runs through this table: The damage lands outside the circle of trust. In every case, the early recipients were fine. Red Hat's customers and the Tier 2 clouds were not. The embargo survives not because it is enforced but because the people inside it mostly choose to honor it.

Heartbleed deserves one more sentence because it is the closest analog to the current situation. Nobody leaked an exploit. A small group received early warning through informal channels, used it well, and then told everyone that they had used it well — while the rest of the industry was still reading the advisory. That is the first-to-defend posture in its purest form, and the oss-security archive shows exactly how the distributors who carried the actual patching burden felt about it.

None of this requires silence. It requires sequencing. The seven practices below are not new; they are what the standard already asks for, restated for a marketing calendar.

1. The source sets the label and the clock. If you received it under TLP:AMBER, it stays AMBER until the source says otherwise. A leak elsewhere does not change your label. The maintainer may choose to accelerate; you do not get to choose for them.

2. Protect first, publish second, in that order, and with a gap. Push the signature, the rule, the virtual patch. Tell your customers privately that they are covered. There is a critical dimension that exists, however, with this process. Mitigation partners must still abide by embargo restrictions to not divulge sensitive vulnerability details prior to the public release. In practice, this means that customers must not have access to the raw detection logic. Additionally, any evidence samples that resulted from new detection should be minimal and not reveal data that could be used for full exploit reconstruction (see number 4). The public post waits for the vendor advisory, and it links to the advisory rather than replacing it.

3. Confirm existence only once the source has. Once the maintainer has announced a release, saying that “This is real, patch at 14:00 UTC” is useful amplification. Saying “We reproduced it” before the fix exists tells attackers the leaked details are good enough to work from.

4. No reconstructions, no proofs of concept, no root cause before the fix. This is the line that was crossed with PHP2Shell. It does not matter whether the publisher is a vendor or an individual with a following.

5. No CVE numbers before the CNA publishes them. Circulating identifiers before CVE.org has assigned them puts your guess into other people's advisories. It was wrong at least once for PHP2Shell.

6. When you are first and wrong, say so in the same place you were first. Corrections buried in an update log do not undo the advisories that copied the original.

7. Measure the team on coverage at patch time, not on the timestamp of the blog post. If the KPI is to be first to publish, the behavior follows the KPI. Change the KPI.

And a note for the vendors who do this well, because they exist. Confirming this leak was real, withholding details, and shipping detection guidance alongside the maintainer's advisory is the right shape. The discipline is not about saying nothing. It is about saying nothing that the people writing exploits could not already have worked out for themselves.

The TLP has no teeth because it was never meant to need them. It is a promise that competitors make to one another so that the people they both serve are safer than either could make them alone. Every leak in Table 2 was committed by someone who had been trusted with that promise, and every one of them ended with a smaller circle, a slower briefing, or a program that nearly got shut down. The customers who paid were never the ones who broke the protocol.

There will be a postmortem on how PHP2Shell leaked. That is worth doing. The more useful question for the industry is how many of us, upon seeing the leak, reached for a keyboard before reaching for the standard. 

If being first to defend means being first to publish, the protocol loses a participant and the next embargo is shorter. If it means being first to protect your customers and last to talk about it, the protocol gains one, and the next embargo holds. Pick the one you would want the other vendors on the list to pick.