mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-10 06:24:09 +09:00
Myasnikov Daniil
1ceaeb8b6e
The security policy promised three supported lines and said no rule decides which of them a fix reaches. The backport batch runs for the two newest lines with a stable release, by the rules on the backport policy page, and the maintainers agreed to make that the support window. SECURITY.md, the incident-response summary and the technical review now name the two latest minor releases, say that the older one drops out when a new minor ships, and send a reader to the backport policy for which fixes reach them. Assisted-By: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
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: the backport batch carries it onto the supported lines, the two latest minor releases, newest first, by the rules in
docs/release/backports.md, which a maintainer can override for a single fix. See the Supported Versions table inSECURITY.md. - 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.