docs(security): document two-person control on alert dismissals#800
Merged
Conversation
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>
anandray
requested review from
Rod-Christensen,
jmaionchi and
stepmikhaylov
as code owners
Contributor
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR updates SECURITY.md to document GitHub-native security scanning and a Vulnerability & Alert Triage workflow on ChangesSecurity Triage Workflow Documentation
Possibly related issues
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
No description provided. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@SECURITY.md`:
- Around line 49-53: Update the Approval wording in the "Approval — must be
given by a *different* maintainer with admin permissions on the repository"
sentence to reflect GitHub's delegated alert dismissal model: replace "admin
permissions on the repository" with the correct organization-level roles (e.g.,
"organization owners, security managers, or other org-level roles explicitly
granted dismissal authority") and note that repository admin rights do not
confer approval authority; preserve the requirement that the approver must be
different from the requester and keep the rest of the flow unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: aeab359b-4ad4-42ce-801b-6af400cfe049
📒 Files selected for processing (1)
SECURITY.md
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>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@SECURITY.md`:
- Line 71: The sentence in SECURITY.md that currently reads "Dependabot alerts
are dismissed only by repository admins..." is inaccurate when
organization-level Delegated Alert Dismissal is enabled; update that sentence to
list the broader set of roles that may dismiss alerts: organization owners,
security managers, and any custom organization roles granted dismissal
permission, and retain that dismissal reason and SLA exceptions must be recorded
in the dismissal comment and fixes tracked via Dependabot security update PRs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 89da0ad4-0604-499a-9503-1027d5084821
📒 Files selected for processing (1)
SECURITY.md
…missal 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>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@SECURITY.md`:
- Line 45: Update the SECURITY.md sentence that lists scanning tools: either
remove "Scorecard" from the listed tools or add a clarifying sentence about how
Scorecard findings are handled differently — e.g., "Scorecard produces an
overall security posture score and recommendations which are reviewed and
addressed in aggregate rather than dismissed as individual alerts," and
reference "Scorecard" and the existing "findings are triaged against the SLAs in
[What to Expect]" wording so reviewers can find and update the same line.
- Around line 68-72: Update the "Secret Scanning & Dependabot" section to
explicitly state that Secret Scanning alerts (for secrets already present in the
repo) follow the same two-person Delegated Alert Dismissal workflow as
Dependabot alerts; mention that any dismissal requires request by a write-access
maintainer, approval by a different organization owner/security manager or
delegated role, and that dismissal reasons and any SLA exceptions must be
recorded in the dismissal comment, with fixes tracked via Secret Scanning
remediation PRs under the same SLAs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9e5ad205-1ebd-47d1-93d7-cfc32780257e
📒 Files selected for processing (1)
SECURITY.md
…push protection CodeRabbit caught that the previous bullet only documented Push Protection (blocks new secrets at push time) and missed the separate flow for Secret Scanning *alerts* — i.e., secrets already detected in the repository. Those follow the same two-person Delegated Alert Dismissal flow as Code Scanning and Dependabot alerts. Adds a bullet noting the parity so the policy covers all three GitHub alert types the org has enabled. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…lerts CodeRabbit flagged that Scorecard appeared in the scanning-tools list but wasn't covered explicitly by any dismissal-flow section. In our setup, Scorecard publishes SARIF that surfaces as code scanning alerts in GitHub's UI (that's the channel by which alert #565 — Scorecard DangerousWorkflowID — was dismissed via the two-person flow). Adds an intro sentence making this coverage explicit so an auditor reading the doc doesn't have to infer it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@SECURITY.md`:
- Line 47: Update the markdown heading "Two-Person Control on Code Scanning
Alert Dismissals" to a broader title that covers all alert types (e.g.,
"Two-Person Control on Alert Dismissals" or "Two-Person Control on Alert
Dismissals (Code Scanning, Secret Scanning, Dependabot)") so the heading aligns
with the content that extends the Delegated Alert Dismissal flow to Secret
Scanning and Dependabot alerts; replace the exact heading text at the section
title to reflect the expanded scope.
- Line 71: Replace the generic phrase "authorized reviewer" in the "Secret
Scanning alerts" sentence with the exact role enumeration used elsewhere:
"organization owner, security manager, or explicitly delegated custom role" so
the line matches the precise terminology on lines 52 and 72 and maintains audit
documentation consistency.
- Line 72: The Dependabot alerts bullet is a single dense sentence; split it
into multiple focused bullets mirroring the Secret Scanning pattern: one bullet
stating who may request dismissal (any write-access maintainer), another stating
who must approve the dismissal (a different organization owner, security
manager, or holder of a delegated custom role), one bullet requiring that the
dismissal comment record the dismissal reason and any SLA exception, and a final
bullet noting that fixes are tracked via Dependabot security update PRs against
the SLA; update the "Dependabot alerts" heading/bullet label accordingly so each
responsibility is a separate, clear line.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ca45827f-64b0-4c3e-9974-5c5b2ecb56b2
📒 Files selected for processing (1)
SECURITY.md
…ependabot Three small fixes from CodeRabbit's third pass: 1. Heading "Two-Person Control on Code Scanning Alert Dismissals" was misleading — the same flow applies to Secret Scanning and Dependabot alerts (called out below). Renamed to "Two-Person Control on Alert Dismissals" to reflect the actual scope. 2. Secret Scanning alert bullet used the shorthand "authorized reviewer" while lines 52 and 72 used the full role enumeration. Replaced with the full enumeration for audit consistency. 3. Dependabot bullet packed request/approval/documentation/fix-tracking into one dense sentence. Restructured as sub-bullets matching the focused-bullet pattern Secret Scanning uses, so an audit reviewer can verify each clause individually. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
asclearuc
approved these changes
May 10, 2026
anandray
added a commit
that referenced
this pull request
May 11, 2026
Resolves merge conflict with develop (where PR #800 landed the "Vulnerability & Alert Triage" section with the two-person Delegated Alert Dismissal flow). This commit replays #762's original intent on top of current develop and integrates with what merged: Additions on top of develop's current SECURITY.md: - Scanning Tools and Coverage subsection — lists CodeQL (Python, JS/TS, C/C++ via Default Setup), Scorecard, Trivy, Dependabot, Secret Scanning + Push Protection. Defers to .github/workflows and repo settings as source of truth. - Branch Protection (`develop`) section — code-owner approval, required checks, force-push/branch-deletion disallowed, linear history, stale reviews dismissed, admin bypass disabled. - Access Reviews section — quarterly review of org members, outside collaborators, owners, and 2FA compliance. - Public Vulnerability Disclosure section — advisory publication policy. - Triage and Remediation SLA table — business days for triage, calendar days for remediation; replaces the prose SLA list. - "Critical-severity issues in unsupported versions evaluated case-by-case" note on Supported Versions. Adjustments to existing develop content: - Triage Disposition naming: "Fix" → "Fixed", "Won't fix" → "Accepted risk" (the latter now requires named approver, rationale, AND a re-evaluation date — the additional SOC2 hygiene #762 introduced). - "Initial Assessment: within 5 business days" prose dropped — the new SLA table covers triage timing more rigorously. Reporting email stays `security@rocketride.ai` (mailbox now exists, per the SOC2 follow-up). Refs #760 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7 tasks
anandray
added a commit
that referenced
this pull request
May 11, 2026
Resolves merge conflict with develop (where PR #800 landed the "Vulnerability & Alert Triage" section with the two-person Delegated Alert Dismissal flow). This commit replays #762's original intent on top of current develop and integrates with what merged: Additions on top of develop's current SECURITY.md: - Scanning Tools and Coverage subsection — lists CodeQL (Python, JS/TS, C/C++ via Default Setup), Scorecard, Trivy, Dependabot, Secret Scanning + Push Protection. Defers to .github/workflows and repo settings as source of truth. - Branch Protection (`develop`) section — code-owner approval, required checks, force-push/branch-deletion disallowed, linear history, stale reviews dismissed, admin bypass disabled. - Access Reviews section — quarterly review of org members, outside collaborators, owners, and 2FA compliance. - Public Vulnerability Disclosure section — advisory publication policy. - Triage and Remediation SLA table — business days for triage, calendar days for remediation; replaces the prose SLA list. - "Critical-severity issues in unsupported versions evaluated case-by-case" note on Supported Versions. Adjustments to existing develop content: - Triage Disposition naming: "Fix" → "Fixed", "Won't fix" → "Accepted risk" (the latter now requires named approver, rationale, AND a re-evaluation date — the additional SOC2 hygiene #762 introduced). - "Initial Assessment: within 5 business days" prose dropped — the new SLA table covers triage timing more rigorously. Reporting email stays `security@rocketride.ai` (mailbox now exists, per the SOC2 follow-up). Refs #760
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a Vulnerability & Alert Triage section to
SECURITY.mdthat codifies the alert-dismissal flow we already operate under (and that GitHub's Delegated Alert Dismissal enforces at the org level). Documentation-only change — no code impact.The new section covers:
Why
This is a SOC2 CC8 (change-management) and CC7.1 (vulnerability management) artifact. The policy in the file maps 1:1 to the system-of-record GitHub already preserves on each alert (request comment → approver → dismissal timestamp), giving an auditor a single document to compare against the alert metadata.
Audit traceability (for the auditor's records — not in the file itself)
The two-person flow was verified end-to-end on Scorecard alert #565:
anandraysubmitted dismissal as "Mitigated" with documented compensating controls (PR fix(security): explicit branch check on nightly workflow_run trigger #771 fix in flight, branch protection prevents direct push, etc.)kwit75approved as the second admin principalrequest → approval → dismissaltrail visible on the alert pageOrg-level controls in place that back this policy:
Test plan
[What to Expect](#what-to-expect)link in the new section resolves to the existing### What to Expectheading🤖 Generated with Claude Code
Summary by CodeRabbit