vulnerability response

Vulnerability response

Status: shipped.

This page lists the steps from a private report to a published fix. The reporter steps are in SECURITY.md.

Steps

1. Report. The reporter uses GitHub private vulnerability reporting, or emails gleb@tcivie.com with "[eepview security]" in the subject.
2. Acknowledge in 3 days. The maintainer confirms receipt and names a point of contact.
3. Triage in 7 days. The maintainer reproduces the problem, rates the severity, and checks if it breaks a promise in Security requirements. The maintainer tells the reporter the result.
4. Fix. The maintainer works in a private fork or a private advisory branch. The fix has a regression test that fails before the fix. See Testing policy. The goal is a fix or a plan in 30 days.
5. Advisory. The maintainer publishes a GitHub Security Advisory. It names the affected versions, the fixed version and the workaround if there is one.
6. CVE. The maintainer requests a CVE through the GitHub Security Advisory, for any issue that is not trivial.
7. Release. The maintainer ships the fixed version. See Release and support.
8. Credit. The reporter is named in the advisory and in the release notes, if the reporter agrees. The reporter chooses the name.
9. Review. The maintainer adds the finding to the security review. The maintainer asks if the cause shows up elsewhere.

Rules

• Never discuss an unfixed vulnerability in a public issue, pull request or discussion.
• Publish the advisory after the fix is ready. Agree the date with the reporter.
• A report that is not a vulnerability becomes a normal issue, with the reporter's consent.

Limits

• One maintainer handles every step. See Access continuity.
• eepview has no release yet. The first fixes ship with the first release.

History

• 2026-10-03 — Add the vulnerability response process — #30.