Responsible Vulnerability Disclosure
Also Known As
responsible disclosure
coordinated disclosure
CVE disclosure
TL;DR
The practice of privately reporting security vulnerabilities to vendors before publishing, allowing time for a fix.
Explanation
Responsible (coordinated) vulnerability disclosure balances the public's right to know about vulnerabilities with the vendor's need for time to fix them. A researcher discovers a vulnerability, privately reports it to the vendor with a technical description, agrees on a disclosure timeline (typically 90 days, e.g., Google Project Zero's policy), and publishes a CVE after the fix is released. For PHP projects, provide a SECURITY.md file with a private reporting channel (security@domain.com), acknowledge reports within 48 hours, and maintain a CVE assignment process.
Common Misconception
✗ Publicly disclosing a vulnerability immediately puts pressure on vendors to fix it faster. Immediate public disclosure before a fix is available puts all users at risk. Responsible disclosure gives vendors a reasonable window (typically 90 days) to patch before details are made public.
Why It Matters
A clear vulnerability disclosure policy tells researchers how to safely report findings — without one, researchers may disclose publicly, contact the wrong people, or give up and leave the vulnerability unreported.
Common Mistakes
- No security.txt or disclosure email — researchers cannot find a contact and publish instead.
- Legal threats to researchers reporting in good faith — destroys trust and deters future reports.
- No acknowledgement within 24-48 hours — researchers assume the report was missed.
- No timeline commitment — researchers cannot plan responsible disclosure without a fix timeline.
Code Examples
✗ Vulnerable
# Missing security.txt — no disclosure channel:
# GET /.well-known/security.txt → 404
# Researcher finds SQL injection, has nowhere to report
# Options: disclose publicly, sell to broker, or give up
# All worse than a working disclosure channel
# Correct /security.txt:
# Contact: security@example.com
# Expires: 2027-01-01T00:00:00z
# Preferred-Languages: en
✓ Fixed
# Responsible Disclosure — security.txt (RFC 9116)
# Place at https://yourapp.com/.well-known/security.txt
Contact: security@yourapp.com
Expires: 2025-12-31T00:00:00.000Z
Encryption: https://yourapp.com/pgp-key.txt
Preferred-Languages: en
Policy: https://yourapp.com/security-policy
# Response process:
# 1. Acknowledge receipt within 48 hours
# 2. Confirm vulnerability within 5 business days
# 3. Target fix: critical = 7 days, high = 30 days, medium = 90 days
# 4. Coordinate disclosure date with reporter
# 5. Credit reporter in changelog/CVE (if they want)
# 6. Publish CVE if CVSS >= 4.0
# Do NOT: ignore reports, threaten legal action against good-faith researchers
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
79
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 44
Amazonbot 14
Google 3
Ahrefs 2
Unknown AI 2
ChatGPT 1
Also referenced
How they use it
crawler 65
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟡 Medium
⚙ Fix effort: Low
⚡ Quick Fix
Add a security.txt file at /.well-known/security.txt with your security contact, policy URL, and preferred disclosure timeline — it's the standard way security researchers contact you
📦 Applies To
any
web
🔗 Prerequisites
🔍 Detection Hints
No security.txt; no responsible disclosure policy; security contact buried or missing; researchers unable to report vulnerabilities
Auto-detectable:
✓ Yes
securitytxt.org
owasp-zap
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: Medium
Context: File