docs: write up incident response plan (IRP)

INCIDENT_RESPONSE.md

@@ -0,0 +1,162 @@
+# Actix Incident Response Plan
+
+This document describes how Actix maintainers handle active security incidents after a report has been received.
+Reporter-facing guidance belongs in `SECURITY.md`.
+
+## Scope
+
+This plan applies to incidents affecting Actix-maintained assets, including:
+
+- Rust crates published from Actix repositories;
+- source code, branches, tags, and release artifacts;
+- GitHub Actions workflows and release automation;
+- repository or organization credentials used to publish crates or manage releases;
+- documentation and website repositories.
+
+This plan does not cover ordinary bugs, unsupported versions, or vulnerabilities that exist entirely outside Actix-managed code or infrastructure.
+
+## Core Rules
+
+- Keep initial handling private.
+- Prefer one coordinated fix over multiple partial fixes.
+- Ship a usable fix or mitigation before publishing exploit details.
+- Treat release integrity incidents as urgent, even before the exact blast radius is known.
+- Keep `SECURITY.md`, advisories, changelogs, and release notes consistent.
+
+## Incident Types
+
+Most incidents will fall into one of these buckets:
+
+- **Code vulnerability:** a defect in an Actix crate or repository that can affect confidentiality, integrity, or availability.
+- **Release integrity issue:** a compromised crate release, tag, artifact, workflow, or publishing credential. Compromised credentials, publishing paths, or release artifacts must be treated as **Critical** by default.
+- **Security regression:** a recent change that removes or weakens an intended security property and requires a patch release.
+- **Dependency issue:** a vulnerability in an upstream dependency that is exploitable through Actix's supported behavior.
+
+## Severity
+
+| Severity | Description |
+| --- | --- |
+| **Critical** | Active exploitation, compromised publishing or release infrastructure, or a vulnerability requiring immediate user action. |
+| **High** | Confirmed vulnerability in a supported release with serious security impact. |
+| **Medium** | Real vulnerability with meaningful but bounded impact or strong preconditions. |
+| **Low** | Hardening issue or low-practicality finding with limited user risk. |
+
+## Response Targets
+
+Actix is maintained by a volunteer team, so these targets describe intended response times rather than strict guarantees.
+
+- Aim to acknowledge incoming security reports within 7 days.
+- Aim to complete initial triage within 30 days of acknowledgement.
+- For **Critical** and **High** incidents, aim to complete disclosure within 90 days of acknowledgement.
+- For **Medium** and **Low** incidents, there is no fixed disclosure deadline; aim to release fixes as soon as practical.
+
+## Workflow
+
+### 1. Validate the Report
+
+1. Acknowledge the report according to the applicable `SECURITY.md`.
+2. Decide whether it is a security report or a normal bug.
+3. Reproduce the issue or build a minimal proof of concept.
+4. Identify the affected repository, crate, feature set, platform, and supported version range.
+5. Open or update a private GitHub Security Advisory if the issue is a vulnerability.
+
+If the report turns out not to be a security issue, close it privately.
+
+### 2. Bound the Blast Radius
+
+Before writing the fix, determine what else is affected.
+
+- Check whether the issue exists on `main`, in the latest release, or in multiple released versions.
+- Check whether the same flaw exists in sibling Actix repositories.
+- For dependency issues, confirm whether Actix is actually exposing the vulnerable behavior.
+- For release-integrity incidents, determine which tags, releases, crates, docs, and workflow runs can no longer be trusted.
+
+If multiple repositories are affected, coordinate them as one incident even if fixes land in separate repositories.
+
+### 3. Stabilize the Situation
+
+Take the smallest action that immediately reduces user risk.
+
+For release or credential incidents, this usually means acting first and investigating in parallel:
+
+- rotate or revoke affected credentials;
+- stop automated publishing if it may be unsafe;
+- freeze further releases until trust is re-established;
+- mark untrusted artifacts clearly and replace them with known-good ones.
+
+### 4. Prepare the Fix
+
+1. Develop the fix privately and keep the patch private until release.
+2. Add regression coverage for the vulnerable behavior.
+3. Review for incomplete fixes and adjacent variants of the same bug.
+4. Verify all affected crates and repositories together.
+5. Decide which versions will be released and which old versions, if any, should be yanked.
+
+Avoid speculative refactors during incident response. The goal is to restore a safe release quickly and clearly.
+
+### 5. Publish in the Right Order
+
+For normal vulnerability handling, the order should usually be:
+
+1. finalize the private advisory;
+2. publish patched releases;
+3. make the GitHub Security Advisory public;
+4. request or attach a CVE for **Critical** and **High** incidents;
+5. publish a RustSec advisory for affected published crates;
+6. update changelogs or release notes with user-facing upgrade guidance.
+
+If the incident is already public or actively exploited, maintainers may publish a limited advisory earlier, but only with enough concrete guidance for users to protect themselves.
+
+### 6. Follow Through
+
+After disclosure:
+
+- verify that published versions, advisory ranges, and links are correct;
+- watch for regressions or reports of incomplete remediation;
+- update advisories if new facts appear;
+- record follow-up engineering work;
+- update this plan or `SECURITY.md` if the incident exposed process gaps.
+
+## Dependency-only Vulnerabilities
+
+Dependency vulnerabilities should be handled conservatively. If a vulnerability exists only in an upstream dependency, maintainers should normally rely on the upstream advisory process rather than publishing a separate Actix advisory.
+
+A repository advisory for a dependency-only issue should generally be published only when the issue is **Critical** and Actix users need repository-specific mitigation or upgrade guidance.
+
+## Actix-Specific Release Guidance
+
+Actix repositories frequently publish Rust crates consumed directly from crates.io. That shapes the response:
+
+- Prefer coordinated crate releases when one issue spans multiple packages.
+- Use the GitHub Security Advisory as the primary private record for vulnerability incidents.
+- Publish RustSec entries for vulnerabilities if needed so Cargo-based tooling can surface them.
+- Use changelogs and release notes to tell users exactly which versions to upgrade to.
+- Do not rely on yanks alone; users may already have the affected version locked in dependency graphs.
+
+## Cross-Repository Coordination
+
+The Actix organization contains multiple repositories with related code and shared maintainers. When an incident crosses repository boundaries:
+
+- treat it as one incident with shared scope;
+- keep one canonical private record, with links to any repository-specific fixes;
+- align publication timing across repositories;
+- avoid publishing one fix in a way that reveals an unfixed issue elsewhere.
+
+## Communication
+
+- Keep communication with the reporter in the same private channel used for intake.
+- Do not confirm exploitability in public until a fix or mitigation is available.
+- Share enough information for users to act, but avoid publishing unnecessary exploit detail.
+- Credit reporters only with their consent.
+
+## Relationship to `SECURITY.md`
+
+`SECURITY.md` tells reporters how to contact maintainers and what versions are supported.
+
+This document describes how maintainers respond after that report arrives.
+
+The two documents should be updated together when the process changes.
+
+## Maintenance
+
+Review this plan after any Critical or High incident, and periodically as Actix release practices or organization structure change.

SECURITY.md

@@ -32,6 +32,11 @@ Include as much of the following as you can:
 
 If you're not sure whether something is a security issue, report it anyway and mark it as uncertain.
 
+Fully AI-generated, low-quality, or spammy reports are not accepted. Reports must reflect a
+real investigation, include repository-specific details, and provide a credible reproduction or
+impact assessment. Sending AI slop or repeatedly submitting low-quality reports may result in a
+ban from the organization.
+
 ## Disclosure Process
 
 After receiving a report, maintainers will make a best effort to: