Vulnerability Disclosure
Vulnerability disclosure is the coordinated process of receiving, triaging, fixing, and publishing security reports so defenders learn before attackers exploit them.
Definition
Vulnerability disclosure is a policy and workflow for external researchers to report security flaws privately, for the vendor to acknowledge and remediate them within agreed timelines, and for the details to be published with credit after a fix is available.
Context and scope
Use it for any product with external attack surface, and publish the policy where researchers can find it, typically at /.well-known/security.txt.
Common misconceptions
- A bug bounty program is required; a disclosure policy and a working intake channel come first
- Researchers should stay silent indefinitely; coordinated disclosure includes a publication date
- Legal threats are an effective response; they push reporters to sell or publish exploits
Anti-patterns
- Listing a security email that nobody monitors
- Acknowledging reports but never communicating status or timelines
- Publishing a fix without an advisory, leaving customers unable to assess exposure
Related concepts
Related examples
Authoritative source
https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
A channel and a promise
Disclosure starts with a reachable channel and a stated promise: reports are welcome, acknowledged within a set time, handled confidentially, and published with credit after remediation. Without that promise, researchers either give up or go public, and the vendor loses the chance to fix first.
How it works
Publish /.well-known/security.txt with a contact, a policy URL, and a preferred language. When a report arrives, acknowledge it, assign an owner, reproduce the issue, and agree on a timeline. Triage severity using exploitability and impact, not just a score. Keep the reporter informed at each state change, and offer a CVE when the issue affects a widely used product.
After the fix ships, publish an advisory that names affected versions, the impact, and the remediation. Credit the reporter unless they prefer anonymity. A short embargo protects users; an indefinite embargo protects only the vendor’s reputation.
When to use it
Every organization with a public API, website, or shipped software should have a policy. Regulated industries may also need a Product Security Incident Response Team and contractual notification timelines. Bug bounties can be added later to increase volume, but they do not replace the basics.
Trade-offs
Fast disclosure pressures vendors and can expose users before patches deploy. Long embargoes reduce risk of exploitation but frustrate researchers and may lead to leaks. Paying for reports attracts attention but can also attract low-quality submissions. Safe-harbor language encourages research while requiring legal review.
Example and misconceptions
A researcher reports an IDOR that exposes invoices. The vendor acknowledges in two days, ships a fix in three weeks, and publishes an advisory with a CVE. A second researcher, finding no monitored contact, posts the same bug publicly, and customers learn from a tweet.
The common misconception is that disclosure is a legal formality. It is an operational capability that shortens exposure and builds trust.
Related concepts: Threat Modeling, Incident Command, and Supply Chain Security.