Vulnerability Disclosure Policy
Document 03 of 5 · Last reviewed:
If you have found a security issue in keyrotate, thank you for taking the time to report it. This document explains how to do so safely, what we consider in scope, and what to expect after you report.
How to report
Use the GitHub Security Advisories form on the keyrotate repository — it lets you file a confidential report that only project maintainers can see:
If you cannot use GitHub Advisories, email security@keyrotate.dev with the details. Please do not open a public GitHub issue for a security report.
What to include
- A description of the issue and its impact.
- Steps to reproduce — ideally a minimal proof of concept.
- The keyrotate version (
keyrotate version) and platform. - Any logs, screenshots, or output that helps us understand the issue. Redact any real secrets from anything you send us.
What is in scope
- Vulnerabilities in the published binaries (
keyrotateCLI, all four platform targets). - Vulnerabilities in the source code on the
mainbranch. - Supply-chain issues affecting our published artifacts (npm packages, GitHub Releases, Homebrew Formula).
- The marketing site at keyrotate.dev.
What is out of scope
- Issues in upstream provider APIs (report to the provider).
- Issues in the destination CLIs (
op,gh,supabase,netlify,flyctl) — report to those projects. - Anything requiring root or code execution on the user's local machine (see threat model in Security Posture).
- Self-XSS, social engineering, lost-laptop scenarios.
- Reports generated by automated scanners with no analysis or proof of impact.
Response timeline
- Acknowledgement: within 3 business days of your report.
- Triage: initial assessment of severity and validity within 7 business days.
- Fix: targeted within 30 days for high-severity issues, 60 days for medium, best-effort for low.
- Coordinated disclosure: we follow a 90-day disclosure window. If the issue is fixed in fewer than 90 days, we publish a security advisory at that point. If the issue takes longer than 90 days to fix, we coordinate with you on a public disclosure date so users can take protective action.
Recognition
We will credit you in the security advisory and the release notes unless you prefer to remain anonymous. There is no monetary bug bounty at this time — this is a free open-source project run by a single maintainer.
Safe harbor
We will not pursue legal action against good-faith security research that follows this policy. "Good faith" means: you do not access data that isn't yours, you do not perform DoS testing on production infrastructure, you do not retain any secrets you may encounter during testing, and you give us a reasonable opportunity to fix the issue before public disclosure.