What is a vulnerability disclosure program?
A vulnerability disclosure program (VDP) is the front door for security researchers. It is a published commitment that says: if you find a security problem in our products, here is how to tell us, here is what we will do with it, and here is how we will treat you.
Without one, researchers have to guess. They email sales, open a public GitHub issue, or post on social media, and the vulnerability becomes public before you have a fix.
What goes in a vulnerability disclosure policy?
The policy is the document at the heart of a VDP. It should cover:
- Scope: which products, versions and domains are covered, and what is explicitly out of scope
- How to report: a dedicated email address or form, with an encryption key if you accept encrypted reports
- What to include: affected version, reproduction steps, impact
- What reporters can expect: acknowledgement within a set time (for example 3 business days), status updates, and a target time to a fix
- Safe harbour: a commitment not to take legal action against good-faith research that follows the policy
- Disclosure: how and when you will publish, usually as a security advisory once a fix is available, and whether you credit reporters
- Coordination window: how long you ask the reporter to wait before publishing on their own, commonly 90 days
Publish the policy at a stable URL and point to it from the Policy field of your security.txt.
Coordinated vulnerability disclosure (CVD)
Coordinated vulnerability disclosure is the practice a VDP implements. The reporter and vendor agree to keep the details private until a fix is available, then disclose together. It replaced the older term “responsible disclosure”, and it is the model described in ISO/IEC 29147 and used by CERTs and national authorities.
When a vulnerability affects several vendors, for example a flaw in a widely used open source library, a coordinator such as a national CSIRT can manage the timeline between them.
VDP vs bug bounty
| Vulnerability disclosure program | Bug bounty | |
|---|---|---|
| Pays researchers | No | Yes, per valid finding |
| Purpose | Make reporting possible and safe | Actively attract testing |
| Who needs one | Every vendor | Optional, once a VDP is mature |
| Typical platform | Your own policy and inbox | HackerOne, Bugcrowd, Intigriti |
A bug bounty without a VDP behind it is backwards. Start with the VDP.
Is a vulnerability disclosure policy required?
For many organisations, yes:
- The EU Cyber Resilience Act (Annex I, Part II) requires manufacturers of products with digital elements to “put in place and enforce a policy on coordinated vulnerability disclosure” and to provide a contact address for reporting vulnerabilities. See our CRA guide.
- US federal agencies are required by CISA Binding Operational Directive 20-01 to publish a VDP, and federal procurement increasingly expects one from suppliers.
- The UK Software Security Code of Practice expects vendors to have a vulnerability disclosure process. See UK Software Security Code of Practice.
Running a VDP with sbomify
A VDP only works if the rest of the loop exists. sbomify covers the policy itself and the pieces after the report lands:
- A generated disclosure policy: the CRA compliance wizard produces a vulnerability disclosure policy for each product and publishes it as a public page on your Trust Center
- security.txt published from your Trust Center, with your contact, policy URL and CSAF provider
- SBOM-based triage, so you can see which products and releases contain the affected component
- VEX to record “not affected” decisions once, and share them
- Security advisories for the disclosure step, published on your Trust Center and as CSAF 2.0