docs(security): document two-person control on alert dismissals (#800)

* docs(security): document two-person control on alert dismissals

Adds a "Vulnerability & Alert Triage" section to SECURITY.md that codifies
the dismissal flow we already operate under and that GitHub's delegated
alert dismissal enforces:

- Request (any write maintainer, with justification)
- Approval (different admin maintainer; no self-approval)
- GitHub auto-applies dismissal after approval

Also documents:
- The four valid triage dispositions (Fix / Mitigated / False positive /
  Won't fix) and the evidence each requires
- Secret Scanning Push Protection bypass logging
- Dependabot dismissal owner + comment requirement

The flow was verified end-to-end on Scorecard alert #565 (anandray
requested with documented compensating controls, kwit75 approved as
second principal). This commit captures the policy that maps to that
audit trail; it's a documentation-only change with no code impact.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(security): correct approver-role wording for delegated dismissal

CodeRabbit flagged that the policy text said "admin permissions on the
repository" for the second-principal approver, which is the wrong
authorization scope. GitHub Delegated Alert Dismissal is an org-level
control: only organization owners, security managers, or holders of
explicitly delegated custom roles can approve dismissal requests.
Repo-admin alone is not sufficient.

This matches what actually worked for alert #565: kwit75 approved as a
rocketride-org owner, not via repo-admin.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(security): align Dependabot dismissal wording with delegated-dismissal model

Same fix as a42cf81 but for the Dependabot bullet on line 71.
CodeRabbit caught that "repository admins" was wrong for the same
reason: GitHub Delegated Alert Dismissal is an org-level control,
authorized by organization owners, security managers, or holders of
explicitly delegated custom roles — not repo-admin alone. The new
wording also explicitly points at the two-person request → approval
flow defined earlier in the section.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: anandray

SECURITY.md

@@ -40,6 +40,40 @@ We take security vulnerabilities seriously. If you discover a security issue, pl
 - We request a 90-day disclosure window for non-critical issues
 - We will credit reporters (unless anonymity is requested)
 
+## Vulnerability & Alert Triage
+
+This project uses GitHub-native scanning on the `develop` branch — CodeQL (Default Setup), Secret Scanning with Push Protection, Scorecard, and Dependabot. CodeQL and Scorecard findings both surface as code scanning alerts in the same GitHub UI and share the dismissal workflow described below. All findings are triaged against the SLAs in [What to Expect](#what-to-expect).
+
+### Two-Person Control on Alert Dismissals
+
+To prevent unilateral dismissal of security findings, this repository operates under GitHub's **Delegated Alert Dismissal**, enabled at the `rocketride-org` organization level:
+
+1. **Request** — any maintainer with write access can submit a dismissal request. The request **must** include a documented justification: compensating controls, mitigation rationale, or basis for "won't fix". This justification is recorded as the dismissal comment on the alert.
+2. **Approval** — must be given by a *different* authorized reviewer under GitHub Delegated Alert Dismissal (organization owner, security manager, or explicitly delegated custom role). The requester cannot self-approve.
+3. **Dismissal** — GitHub auto-applies the dismissal once approval lands. The full `request → approval → dismissal` trail is preserved on the alert and serves as the system-of-record for audit.
+
+Direct (one-step) dismissal is blocked at the organization level.
+
+### Triage Dispositions
+
+When closing an alert, choose one of:
+
+| Disposition | When to use | Evidence captured |
+| --- | --- | --- |
+| **Fix** | Vulnerability is exploitable in our usage | PR linking the alert (auto-closes on merge) |
+| **Mitigated** | Code path is reachable but compensating controls neutralize the risk | Two-person dismissal with controls listed in comment |
+| **False positive** | Tool flagged a non-issue (e.g., test fixture, intentional pattern) | Two-person dismissal with explanation |
+| **Won't fix** | Risk accepted by ownership | Two-person dismissal with named approver and rationale |
+
+### Secret Scanning & Dependabot
+
+- **Secret Scanning Push Protection** is enabled org-wide. Pushes containing detected secrets are blocked at push time; bypasses require committer justification and are recorded in the audit log.
+- **Secret Scanning alerts** for secrets already in the repository follow the same two-person Delegated Alert Dismissal flow (request by any write-access maintainer; approval by a different organization owner, security manager, or holder of an explicitly delegated custom role; auto-dismissal with audit trail).
+- **Dependabot alerts** follow the same two-person Delegated Alert Dismissal flow described above:
+  - Request by any write-access maintainer; approval by a different organization owner, security manager, or holder of an explicitly delegated custom role.
+  - Dismissal reason and any SLA exception must be recorded in the dismissal comment.
+  - Fixes are tracked via Dependabot security update PRs against the SLAs above.
+
 ## Security Best Practices
 
 When using RocketRide Engine: