Everything you ever learn about a vulnerability in software you use passes through this machinery first. Whether a flaw gets an identifier, whether the patch notes mention it, whether the person who found it is credited or threatened, and how long the window between discovery and your update actually was, are all decided by a set of conventions that most users never see and that no law fully governs.
The word was the first argument
Through the 1990s the default position among researchers was full disclosure: publish the details immediately, on the theory that vendors fix what is public and ignore what is private. Vendors argued that publication armed attackers before defenders could patch.
In October 2001 Scott Culp, then at Microsoft, published an essay titled "It's Time to End Information Anarchy," and the term responsible disclosure came into wide use shortly after. The objection to that phrase is structural rather than stylistic: it locates responsibility entirely with the reporter. A vendor that sat on a report for a year was never described as having disclosed irresponsibly.
The field settled on coordinated vulnerability disclosure, which names the joint activity and leaves the blame unassigned. CERT/CC uses it, and it is the framing behind the two ISO standards that cover this ground: ISO/IEC 29147 on how to receive and publish vulnerability information, and ISO/IEC 30111 on the internal handling process that has to exist for 29147 to be more than a mailbox.
Finding an address to send it to
For years the practical obstacle was banal. A researcher with a finding could not locate anyone to tell. Generic security mailboxes bounced, support desks closed the ticket as a product question, and the first substantive reply sometimes came from a legal department rather than an engineer.
RFC 9116 standardised the answer as a plain text file at /.well-known/security.txt. Two fields are required. Contact gives a mailbox, form, or phone number. Expires gives a date after which the file should not be trusted, and it is required because a stale contact is worse than no contact at all: a reporter who emails a dead address believes they have reported, and stops.
The optional fields carry most of the useful signal. Policy links your disclosure terms. Encryption points at a key so the report can be sent encrypted, which for a pre-patch exploit is the difference between a private report and a broadcast. Acknowledgments links your credit page, which tells a reporter whether previous ones were treated well. Preferred-Languages saves a round trip. The file can be signed with OpenPGP, and key discovery for that has its own conventions, covered in Web Key Directory.
The clock is the only leverage
Published deadlines exist because without one, "we are working on it" and "we are not going to fix this" produce identical observable behaviour. The reporter cannot distinguish them and has no way to escalate. A date converts vendor silence from a free option into a cost.
| Policy | Default window | Notable terms |
|---|---|---|
| CERT/CC | 45 days from report | Adjusted for severity, active exploitation, or a vendor engaging in good faith |
| Google Project Zero | 90 days, plus 30 days after a patch ships | 7 days when the flaw is being exploited in the wild; the grace period is meant to give users time to update before details land |
| Trend Micro ZDI | 120 days | Longer window reflecting that reports are acquired and often affect enterprise software with slow patch cycles |
A disclosure deadline is not a threat aimed at the vendor. It is the mechanism that lets a reporter distinguish a slow fix from no fix, using the only resource they control, which is their own future publication.
Where CVE numbers come from
The identifier you eventually see in a changelog is issued through the CVE Program, with MITRE as secretariat and the actual assignment delegated to CVE Numbering Authorities. A CNA has a defined scope, and a great many vendors are the CNA for their own products.
That arrangement puts the party with the flaw in charge of whether the flaw gets an identifier. CNA rules and the existence of a CNA of last resort are the counterweights, but a vendor that would rather describe a security fix as a stability improvement has a straightforward path to doing so.
The identifier is not paperwork. Vulnerability scanners, dependency tools, and software bills of materials all track by CVE. A patched bug with no CVE is invisible to every inventory downstream, which means the organisations running the vulnerable version have no automated way to learn they need to upgrade. The scoring layer on top has its own problems, covered in CVSS and CVE scoring.
What bounty programs fixed, and what they introduced
Bug bounty platforms solved real problems. There is a working address, a triage team that understands the report, a payment, and usually a written statement that the company will not pursue legal action against good-faith research. For a researcher deciding whether to spend an evening on a report, that combination is decisive.
The problem sits in the terms. Many programs make non-disclosure the default or a condition of payment, so accepting the reward removes the researcher's ability to publish. The disclosure process becomes a purchase, and the transaction can end with the bug fixed, the reporter paid, and no public record that it ever existed. Users of the affected version during the vulnerable window never find out they were exposed.
A second pattern is scope management. A finding declared out of scope, or reclassified as informational, is one that needs neither a payment nor an identifier. When you are reading a program's terms, one clause tells you most of what you need:
Does the policy state a maximum period after which the researcher may publish, whether or not a fix has shipped? If it does not, the program has purchased silence with no expiry date.
Safe harbour is still the unresolved part
Computer misuse statutes criminalise unauthorised access, and the party defining "authorised" is usually the party receiving the report. Researchers have been threatened with the US Computer Fraud and Abuse Act, the UK Computer Misuse Act, and their equivalents elsewhere, for work that consisted of noticing something and saying so.
Two developments narrowed the US exposure. In Van Buren v. United States (2021) the Supreme Court held that "exceeds authorized access" does not cover improper use of data a person is otherwise entitled to access, which removed a reading that had criminalised terms-of-service violations. In 2022 the Department of Justice announced a charging policy declining to pursue good-faith security research.
A charging policy is not immunity. It binds prosecutorial discretion in one country, does nothing about civil claims, and can be revised. This is why an explicit safe harbour clause in a vendor's own disclosure policy carries real weight, and why its absence is worth reading as a deliberate choice rather than an oversight.
What to do with this
As someone choosing software, the presence of a current security.txt, a published policy with a stated timeline, a safe harbour clause, and a credits page with names on it tells you something about the engineering organisation behind the product. All four are cheap to produce. A vendor that has none of them has usually not thought about what happens when a stranger finds a flaw, which is a fact about their development process and not only about their paperwork.
As someone running a service, the list is short. Publish security.txt with an Expires date you will actually renew. State a window and honour it. Write the safe harbour clause. Do not condition payment on silence. Request or assign an identifier even when the bug is embarrassing, because the people running your old version need it more than your changelog does.
All of this scaffolding exists for one reason: the person who finds a flaw and the person who can fix it are almost never the same person, they usually have no prior relationship, and one of them is arriving with bad news. Coordinated disclosure is the set of conventions that lets that conversation happen without either party having to trust the other's good will in advance. Related reading: the market that competes for the same findings and reproducible builds, which addresses the separate question of whether the patch you received is the patch that was published.