mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-03 02:27: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>
3.5 KiB
3.5 KiB
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— how to report a vulnerability, response commitments, and the disclosure timeline.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
- Intake. A report arrives through GitHub Private Vulnerability Reporting or
a private maintainer contact (see
SECURITY.md). Receipt is acknowledged within 3 business days. - 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). - 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.
- Private fix development. The fix is developed under a GitHub Security Advisory (private fork) so that code and discussion stay confidential until release.
- 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. - 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. - 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.mdare executed (GitHub team access, org roles, Actions secrets, registry tokens, and App keys), completed within five business days. - 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 → Disclosure timeline. They are not
duplicated here to avoid drift.