mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-12 23:54:01 +09:00
Timur Tukaev
e1fc2ab82e
Maintainer decisions on the two questions this branch raised rather than answered. Supported versions are the latest stable minor and the two minors preceding it. Expressed as a rolling rule, so it names concrete lines when read against the Releases page without going stale, and it replaces the activity-window test, which classified every 1.x line back to 1.0 as supported and so described something wider than the project does. There is no documented rule for choosing which supported lines a fix is backported to; it is a per-fix maintainer decision weighing severity against backport risk. Say that plainly in SECURITY.md instead of implying a policy. That also resolves the promise in the incident-response process, which said a fix ships across all affected supported release lines. It does not necessarily, and with no rule governing the choice that sentence committed the project to something it has not agreed. Point at the per-fix decision instead. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
68 lines
3.5 KiB
Markdown
68 lines
3.5 KiB
Markdown
# Incident Response
|
|
|
|
This document is the public summary of how the Cozystack maintainers respond to
|
|
a confirmed security vulnerability or incident. Detailed operational procedures
|
|
(contact trees, credential inventories, and step-by-step checklists) are
|
|
maintained privately by the maintainers; this page describes the process and
|
|
the mechanisms it relies on so that reporters and users know what to expect.
|
|
|
|
It complements, and does not replace:
|
|
|
|
- [`SECURITY.md`](../../SECURITY.md) — how to report a vulnerability, response
|
|
commitments, and the disclosure timeline.
|
|
- [`CONTRIBUTOR_LADDER.md`](../../CONTRIBUTOR_LADDER.md) — the offboarding
|
|
procedure, including access revocation and credential rotation.
|
|
|
|
## Roles
|
|
|
|
For each incident the maintainers designate:
|
|
|
|
- **Incident lead** — a maintainer (typically a core maintainer) who coordinates
|
|
triage, the fix, the release, and disclosure, and keeps the reporter informed.
|
|
- **Comms owner** — responsible for the public advisory and release-notes
|
|
wording, and for any coordination with upstream projects and CNCF.
|
|
- **Fix owner(s)** — the maintainer(s) developing and reviewing the fix.
|
|
|
|
One person may hold more than one role on a small incident.
|
|
|
|
## Lifecycle
|
|
|
|
1. **Intake.** A report arrives through GitHub Private Vulnerability Reporting or
|
|
a private maintainer contact (see `SECURITY.md`). Receipt is acknowledged
|
|
within **3 business days**.
|
|
2. **Triage and severity.** The maintainers reproduce the issue and assign a
|
|
CVSS v3.1 severity within **7 business days**. This drives the remediation
|
|
target and disclosure window (see `SECURITY.md` → *Disclosure timeline*).
|
|
3. **Containment.** Where an immediate mitigation or workaround exists (a
|
|
configuration change, a policy, or disabling an affected feature), it is
|
|
documented and shared with the reporter and, if warranted, with affected
|
|
adopters under embargo.
|
|
4. **Private fix development.** The fix is developed under a **GitHub Security
|
|
Advisory** (private fork) so that code and discussion stay confidential until
|
|
release.
|
|
5. **Coordinated release.** The fix is shipped through the normal patch-release
|
|
and backport process. Which supported lines receive the backport is decided
|
|
per fix, weighing severity against backport risk — see the *Supported
|
|
Versions* table in `SECURITY.md`, which also records that no documented rule
|
|
governs that choice.
|
|
6. **Disclosure.** A GHSA — and, when applicable, a CVE — is published. Public
|
|
disclosure follows the outbound channels: GitHub Releases and release notes,
|
|
the changelog, and the GHSA itself. The reporter is credited unless anonymity
|
|
is requested. Disclosure happens no later than the coordinated-disclosure
|
|
window committed in `SECURITY.md`.
|
|
7. **Access and credential hygiene.** If the incident involved a compromised or
|
|
departing maintainer or leaked credential, the access-revocation and
|
|
credential-rotation steps in `CONTRIBUTOR_LADDER.md` are executed (GitHub team
|
|
access, org roles, Actions secrets, registry tokens, and App keys), completed
|
|
within five business days.
|
|
8. **Retrospective.** After resolution the maintainers record what happened, the
|
|
root cause, and any follow-up hardening, and open tracking issues for
|
|
preventative work.
|
|
|
|
## Severity and timelines
|
|
|
|
Severity classification (CVSS v3.1) and the target remediation and disclosure
|
|
timelines are defined once, authoritatively, in
|
|
[`SECURITY.md`](../../SECURITY.md) → *Disclosure timeline*. They are not
|
|
duplicated here to avoid drift.
|