Incident Response Plan

Document 05 of 5 · Last reviewed: May 28, 2026

This plan describes how we respond when something goes wrong with keyrotate — a vulnerability is reported, a supply-chain compromise is suspected, or a published release breaks production for users. Because keyrotate is a single-maintainer open-source project, the plan is deliberately simple.

What counts as an incident

• A confirmed security vulnerability in a published release (any severity).
• A suspected compromise of our publishing credentials (npm token, GitHub release token, Homebrew tap write access).
• A published release that corrupts data, leaks secrets, or otherwise causes harm when run as documented.
• A defaced or compromised marketing site.

Things that are not incidents (handled via normal issues / PRs): a missing feature, a confusing error message, a third-party CLI changing its interface, a destination provider returning an unexpected status.

Who responds

Steve Kinzey (@SteveKinzey), the maintainer, is the primary responder. There is no on-call rotation. If you cannot reach the maintainer for a critical issue and the public good is at stake, you may publicly disclose after a 14-day silent period, per the safe-harbor clause in the Vulnerability Disclosure policy.

Response steps

1. Acknowledge the report or alert within 3 business days. Open a private GitHub Security Advisory to track the work.
2. Triage: assess severity (low, medium, high, critical) and validate the report. Document expected blast radius.
3. Contain: if a publishing credential is compromised, rotate it immediately using keyrotate itself. If a malicious release was published, yank it from npm (npm unpublish within the 72-hour window), revoke the GitHub Release, and pull the Homebrew Formula.
4. Fix: produce a patch in a private branch. Verify the fix with a test that fails before the patch and passes after.
5. Release: tag a new version, publish to all distribution channels, push the updated Homebrew Formula.
6. Disclose: publish the GitHub Security Advisory once the fix is available. The advisory lists impact, affected versions, fixed version, workarounds, credit to the reporter, and a short post-mortem.
7. Notify: post the advisory link in GitHub Discussions and to any contact channels you have provided.

Escalation criteria

• Critical: a published release silently leaks secrets, exfiltrates data, or could be used to gain RCE on a user's machine without their consent. Response begins immediately on confirmation; we aim to publish a patched release within 24 hours.
• High: a vulnerability that allows an attacker to bypass intended access controls but requires non-trivial conditions. Targeted within 7 days.
• Medium / low: handled in the normal release cadence; called out in release notes when fixed.

Public running log

Past incidents are listed at the GitHub Security Advisories page for the repository. As of the date at the top of this document, no security incidents have been reported.

Post-mortem disclosure

For every confirmed incident, the published advisory will include a short post-mortem (what happened, why it was not caught earlier, what we changed). The goal is to help the wider community improve, not to deflect blame.