Coordinated vulnerability disclosure: how to run a disclosure program

What is coordinated vulnerability disclosure?

Coordinated vulnerability disclosure (CVD) is the practice of handling a newly found vulnerability privately between the finder and the vendor until a fix or mitigation is available, then publishing it. The CERT Guide to Coordinated Vulnerability Disclosure describes it as gathering information from vulnerability finders, coordinating the sharing of that information between the relevant stakeholders, and disclosing the vulnerability and its mitigations, including to the public.

For a product vendor, CVD has two halves. The outward half, receiving reports and publishing advisories, is what this page covers. The inward half, verifying, fixing and releasing, is the vulnerability management lifecycle. Both are usually run by a PSIRT.

CVD vs full disclosure vs bug bounty

	Coordinated disclosure	Full disclosure	Bug bounty
What it is	Private report, fix, then publication at an agreed time	The finder publishes details immediately, with or without telling the vendor	A program that pays for valid findings
Who controls timing	Vendor and finder together, sometimes with a coordinator	The finder	The program's terms, usually following CVD
Risk to users	Lowest: details are public once a fix exists or a deadline passes	Highest: attackers learn of it when defenders do	As for CVD
Cost	Staff time to triage and respond	Unplanned emergency work	Staff time plus rewards and often platform fees

A bug bounty is not an alternative to a vulnerability disclosure program (VDP). It is an incentive layered on top of one. Every vendor needs a way for anyone to report a vulnerability; a bounty only decides whether some reports get paid.

What goes into a vulnerability disclosure policy

A vulnerability disclosure policy is the public document that sets the terms of your program. ISO/IEC 29147, the international standard for vulnerability disclosure, makes one element required, a preferred contact mechanism, and recommends several more. A complete policy covers:

• How to report. A dedicated address or web form, and a way to send sensitive details securely, such as a published encryption key.
• What to include. Affected product and version, steps to reproduce, impact, and how to reach the reporter.
• Scope. Which products, versions and services are covered, and which test methods are off limits, such as denial of service or accessing other users' data.
• Safe harbor. A commitment not to pursue legal action against good-faith research that follows the policy.
• What reporters can expect. When you will acknowledge the report, how you will keep them updated, and your target time to a fix.
• Disclosure timeline. When details become public, and what happens if a fix takes longer.
• Publication. Where advisories appear and whether you assign CVE IDs.
• Recognition. Whether and how you credit reporters, and whether you pay bounties.

Keep the policy short and specific. Reporters read it to decide whether reporting to you is safe and worth the effort.

security.txt: make your contact easy to find

A policy only works if researchers can find it. RFC 9116, published in April 2022, defines security.txt, a small text file served at /.well-known/security.txt over HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Required: Contact and Expires. RFC 9116 recommends an expiry less than a year ahead, so the file does not go stale.
• Optional: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical and Hiring.
• Signing: the RFC recommends an OpenPGP cleartext signature, with Canonical set.

Put a reminder in the calendar before the Expires date. An expired file tells researchers nobody is reading.

Embargoes and disclosure timelines

The embargo is the period between the report and publication. The most cited norm is Google Project Zero's policy: vendors get 90 days to make a patch available, and details are published 30 days after the patch ships. A vendor that needs a little more time can ask for a grace period, to at most 104 days in total. When a vulnerability is already exploited in the wild, the deadline drops to 7 days.

Your own policy can set different terms, and many reporters accept them. What matters is that the timeline is written down, that you keep reporters informed, and that you ask for an extension before the deadline rather than after. An advisory published on schedule with a mitigation is better than silence.

CVE IDs and CNAs

Most advisories carry a CVE ID so customers and tools can match them. IDs are assigned by CVE Numbering Authorities (CNAs), organizations authorized to assign IDs within an agreed scope. Many software vendors are CNAs for their own products, which lets them assign the ID and publish the record on their own schedule. If you are not, a CNA whose scope covers your product, or a CNA of Last Resort, assigns it.

Multi-party coordination

Some vulnerabilities affect many vendors at once: a flaw in a widely used library, a protocol or a chip. Then a coordinator helps reach every affected vendor and agree one publication date.

• CERT/CC, at Carnegie Mellon University's Software Engineering Institute, coordinates multi-vendor cases and publishes the CERT CVD guide.
• National CSIRTs in the EU. Under NIS2, each Member State designates a CSIRT as its CVD coordinator. It acts as a trusted intermediary between reporters and vendors, negotiates disclosure timelines, handles vulnerabilities that affect several entities, and accepts anonymous reports.
• ENISA's European Vulnerability Database (EUVD), set up under NIS2, has been operational since May 2025 and publishes information on publicly known vulnerabilities, including EU coordinated ones.

ISO/IEC 29147 also covers the case where you are both: a vendor whose product contains another vendor's vulnerable component, who has to report upstream and advise your own customers.

After a report arrives

1. Acknowledge within the time your policy promises, and give the reporter a tracking ID.
2. Verify the report and rate its severity.
3. Find what is affected: every product, release and supported branch that contains the vulnerable code or component.
4. Fix and release for each affected branch, keeping the reporter updated.
5. Publish the advisory, with a CVE ID, affected versions, remediation and credit. Machine-readable advisories use CSAF, and VEX tells customers which products are not affected.

The full process, with roles, timelines and metrics, is in the vulnerability management lifecycle.

Regulation is making CVD policies mandatory

The EU Cyber Resilience Act requires manufacturers to "put in place and enforce a policy on coordinated vulnerability disclosure" and to provide a contact address for reporting vulnerabilities, including those in third-party components (Annex I, Part II). These obligations apply from 11 December 2027; see what the CRA requires. NIS2 Article 21(2)(e) lists vulnerability handling and disclosure among the security measures essential and important entities must take. In the US, Executive Order 14028 directed software supply chain guidance that includes participating in a vulnerability disclosure program.

A report is only as useful as your record of what you shipped

Every report raises the same first question: which of our releases contain this? CRACI runs your GitHub Actions builds on its own runners and records the packages each job actually fetched, including transitive dependencies, packages restored from CI caches and dependencies no lockfile lists. Build history shows which past builds contained a vulnerable dependency, so you know the period you were affected, and the inventory view shows which software versions are deployed to which products.

CRACI aggregates SBOMs across builds and repositories and re-evaluates monitored SBOMs continuously, so once a vulnerability in an open-source component is published, you see everywhere it appears. Security teams triage findings and send them to the teams that own the fix, CRACI supports VEX, and policy gates can block builds that contain a specific CVE once it is fixed. See vulnerability tracking.

Coordinated vulnerability disclosure: frequently asked questions

What is coordinated vulnerability disclosure?

Coordinated vulnerability disclosure (CVD) is the process in which the person who finds a vulnerability reports it privately to the vendor, the vendor fixes it, and the details are published once users can protect themselves, usually at a date the parties agree. Coordinators such as CERT/CC or a national CSIRT step in when a vendor is unreachable or several vendors are affected.

What is the difference between a VDP and a bug bounty?

A vulnerability disclosure program (VDP) tells anyone how to report a vulnerability and what to expect, without paying for findings. A bug bounty pays researchers for valid findings, usually within a defined scope and often through a bounty platform. Most organizations start with a VDP; a bounty is an optional addition on top of it, not a replacement.

What should a vulnerability disclosure policy include?

At minimum, how to report: a contact address or form. ISO/IEC 29147 also recommends saying what a report should contain, how to communicate securely, what reporters can expect and when, what is in scope, how you publish advisories and how you credit reporters. Most policies add a safe harbor statement and a disclosure timeline.

What is security.txt?

security.txt is a plain text file defined in RFC 9116 and served at /.well-known/security.txt. It tells researchers where to report vulnerabilities. It must contain a Contact and an Expires field and can link to your policy, encryption key and acknowledgments page.

How long is a typical disclosure deadline?

90 days is the most widely cited norm. Google Project Zero gives vendors 90 days to make a patch available and publishes details 30 days after the patch, with a 7-day deadline when a vulnerability is already exploited in the wild. Your own policy can set different terms, and coordinators negotiate case by case.

Is a coordinated vulnerability disclosure policy mandatory?

Increasingly, yes. The EU Cyber Resilience Act requires manufacturers of products with digital elements to put in place and enforce a CVD policy and to provide a contact address for reports, and NIS2 lists vulnerability handling and disclosure among required security measures. Elsewhere, customers and procurement rules often ask for one.

Do I need to be a CNA to get a CVE ID?

No. A CVE Numbering Authority (CNA) assigns CVE IDs within its own scope, and many vendors become CNAs for their own products. If you are not one, a CNA whose scope covers your product, or a CNA of Last Resort, can assign the ID.