Skip to content
Back to Maintenance & LTS

Vulnerability Response

The end-to-end process when a vulnerability is reported or discovered — from triage to fix to disclosure.

Why

A vulnerability report is a time bomb — every hour it's unfixed is an hour an attacker could exploit it, and if you mishandle the response (ignore the report, fix it silently, disclose before a patch is available) you make it worse. A defined response process converts panic into a checklist: acknowledge within 24h, triage severity, develop a fix on a private branch, coordinate disclosure with the reporter, ship the patch, then publish a CVE/advisory. The process also prevents the two failure modes: ignoring reports (the vuln sits for months until someone exploits it) and panicking (a rushed fix breaks production and creates a bigger incident). A rehearsed process is what makes the median response time 2 days instead of 2 months.

When

Whenever a vulnerability is reported (security@, Huntr, GitHub Security Advisory) or discovered internally.

How

1. Acknowledge the report within 24h (automated reply + human follow-up within 48h)
2. Triage: confirm it's a real vuln, assign severity (CVSS), determine affected versions + exploit conditions
3. Develop the fix on a private branch (security/vuln-<id>); do NOT push to main until ready
4. Write a regression test that reproduces the vuln, then fix until the test passes
5. Coordinate disclosure with the reporter: agree on a disclosure date (typically 90 days, or sooner if exploited)
6. Ship the patch to all affected versions (current + active LTS) as patch releases
7. Publish a security advisory (GHSA/CVE) with: description, affected versions, fix version, CVSS, workaround
8. Post-mortem: how was it found, could it have been caught earlier (fuzzing, SAST, dependency audit)?

Example

# Vulnerability response (GitHub Security Advisory)
# 1. Acknowledge (automated + human)
# security@ auto-reply: "Received, triaging within 48h. Reference: VULN-2024-042"

# 2. Triage (private advisory)
# .github/advisories/vuln-2024-042.yml
summary: "Prototype pollution in merge()"
severity: high           # CVSS 7.5
affected: ">=1.0.0 <1.2.3"
cvss: 7.5

# 3. Fix on private branch
git checkout -b security/vuln-2024-042
# add regression test, fix, commit
git commit -m "fix(security): prevent prototype pollution in merge() [VULN-2024-042]"

# 4. Coordinate disclosure (email to reporter)
"We plan to publish the advisory on 2024-04-15 (90-day window).
Patch will be in v1.2.3. OK to proceed?"

# 5. Ship + disclose
git tag v1.2.3  # patch release
# Publish GHSA + CVE-2024-12345
# Advisory: https://github.com/ez4code/app/security/advisories/GHSA-xxxx

Common Problems

  • ⚠Ignoring a report because it came from an unknown researcher — most real vulns are found by researchers you've never heard of.
  • ⚠Fixing silently without disclosure — the vuln is patched but users don't know to upgrade, so they stay vulnerable.
  • ⚠Disclosing before the patch is available — you've handed attackers an exploit with no defense for users.

Best Practices

  • ✓Acknowledge every report within 24h and triage within 48h — silence is the response that guarantees the worst outcome.
  • ✓Use coordinated disclosure (90-day window) with the reporter — this fixes users before it informs attackers.
  • ✓Publish a security advisory for every fixed vuln — users can't upgrade if they don't know the fix exists.