Responsible Vulnerability Disclosure
debt(d5/e1/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list securitytxt.org and owasp-zap as tools — these are specialist/opt-in scanners rather than default linters or compilers. The absence of a security.txt or disclosure policy is not flagged by default tooling; you need to deliberately run a check or audit.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix is explicit: add a security.txt file at /.well-known/security.txt with contact, policy URL, and timeline. This is a single file addition — minimal effort to remediate the missing disclosure policy.
Closest to 'localised tax' (b3). The choice applies_to web contexts and primarily affects one operational concern (how researchers contact you). Once a security.txt and policy are in place, the ongoing maintenance burden is low and localised — it doesn't shape every future development decision, but teams must keep the contact and policy current.
Closest to 'serious trap' (t7). The misconception field explicitly states that developers believe 'publicly disclosing a vulnerability immediately puts pressure on vendors to fix it faster,' when in reality immediate public disclosure before a fix is available puts all users at risk. This directly contradicts widely-held intuitions about transparency and accountability, making it a serious cognitive trap that contradicts how similar openness principles work in other contexts.
Also Known As
TL;DR
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
Why It Matters
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
# 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# 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