Coordinated vulnerability disclosure as a capability

A vulnerability programme is invisible until the day it is tested. That day usually opens with a message from someone you have never spoken to, in a mailbox nobody was quite sure who owned, describing a flaw in a product you shipped two years ago. What happens in the next few hours tells you whether you have a capability or a hope.

Disclosure and handling are two different machines

Coordinated vulnerability disclosure is usually pictured as one thing. It is two, and conflating them is the first blind spot.

ISO/IEC 29147:2018 covers disclosure: the interface with the outside world. How you receive a report, how you talk to the researcher who sent it, how and when you inform users. ISO/IEC 30111:2019 covers handling: the internal work of verifying the report, judging its severity, developing and testing a fix. One is a conversation with a stranger. The other is a process running inside your organisation.

A programme that has the disclosure half without the handling half acknowledges reports it cannot act on. A programme with the handling half and no disclosure half fixes things quietly while the researcher, losing patience, goes public on their own timeline. Both halves have to exist, and they have to be wired to each other.

The front door is a human problem

The disclosure side, the 29147 half, is more a human problem than a technical one. It needs an intake channel a researcher can actually find and a human actually answers, an acknowledgement that lands before the researcher concludes they are being ignored, and then the harder part, a relationship carried through the awkward middle: the embargo, the disclosure timeline, the disagreement over severity, the moment the reporter wants to publish and the fix is not ready.

Handled well, the coordinating authority becomes an ally in containment and the researcher a collaborator. Handled badly, the same set of facts becomes a public account of an organisation that could not get out of its own way. Legal and communications are in this from the first hour rather than summoned at the end.

The handling side runs on wiring a policy cannot describe

The 30111 half is internal, and it looks like paperwork only until a report arrives that starts a clock. What matters then is whether the report reaches whoever can judge it in hours rather than days, whether coverage holds through the weekends and holidays when reports tend to surface, and whether the path from triage to a tested fix is one people have walked before. None of that assembles itself under time pressure.

Why this rarely survives being done on the side

Seen whole, the problem has a clear shape, and so does the reason it seldom survives being built on the side of a desk. It is a standing capability rather than a document: something that spans engineering, product security, legal, communications and leadership, runs without pause, and still competes for attention with the thirty other things a team is already behind on.

The individual pieces are learnable. The difficulty is that the subtleties, what counts as exploitation, how a reporter relationship holds under time pressure, how to know with confidence what is inside your own products, are exactly the places a well-intentioned solo effort quietly breaks. And it breaks at the moment of the first real report, which is the worst possible moment to find the gap.