docs(standards): add Advanced Security (GHAS) org standard#495
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds ChangesGHAS Standard Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 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 |
There was a problem hiding this comment.
Code Review
This pull request introduces a new GitHub Advanced Security (GHAS) standard document outlining org-wide enablement, licensing, and verification of push protection. It also adds a rollout prompt for Copilot instructions across repositories, updates related standards to link to the new GHAS standard, and modifies scripts/apply-repo-settings.sh to handle missing check-suite preferences. Feedback on the changes points out a high-severity issue in scripts/apply-repo-settings.sh where the 404 error check on gh api output looks for a JSON status field that does not match the actual CLI error format, and a code suggestion is provided to resolve this.
Dev-Lead — fix-bot-comment (no-changes)Agent reasoning |
Document how GHAS is enabled org-wide via the "GitHub recommended" code security configuration (attach scope=all + default_for_new_repos=all), the public-free/private-licensed billing model, and a four-level verification procedure culminating in a push-protection live-fire canary test. Captures the key gotcha proven in practice: Google API keys are detect-only and NOT push-protection-eligible, so they produce false negatives when used to test push protection. Recommends Stripe/OpenAI/AWS-pair fabricable canaries. Registers the standard in the AGENTS.md index and cross-links push-protection.md and github-settings.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
a02c8a7 to
7a1289e
Compare
|
Dev-Lead — waiting on PR blockers (intent: review-changes)PR: #495 |
|
Note @don-petry I reviewed this PR and no code changes were needed, but it still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews), so I cannot mark it done yet. I'll re-check automatically. |
Dev-Lead — fix-reviews (no-changes)Agent reasoning |
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: LOW
Reviewed commit: 7a1289eaf70a132468590714fb8e9465478ac2f9
Review mode: triage-approved (single reviewer)
Summary
Documentation-only PR adding standards/advanced-security.md (GHAS org-wide enablement + verification) and three cross-reference edits (AGENTS.md index, github-settings.md, push-protection.md). No code, workflow, or settings changes (+240/-0 across 4 files). Triage's low-risk assessment confirmed.
Linked issue analysis
No linked issues (closingIssuesReferences empty; CodeRabbit Linked-Issues check skipped). Not applicable — this is a standalone docs standard.
Findings
- No blocking findings.
- Content is prose plus illustrative shell snippets; the canary "secrets" are fabricated templates (e.g.
sk_live_$(... /dev/urandom ...)) explicitly labelled FAKE, not real credentials. Secret-scan CI (gitleaks) and SonarCloud Quality Gate both passed. - MCP
run_secret_scanningreturned "Repository does not have GitHub Advanced Security enabled" — tool unavailable for this repo; noted and skipped per policy. Did not affect the verdict (gitleaks already covers secret detection). - The gemini-code-assist review (COMMENTED) flagged a HIGH issue in
scripts/apply-repo-settings.sh, but that review was on the superseded commit a02c8a7 and that file is NOT part of the current head (7a1289e is the 4 docs files only). Finding is stale/out of scope for this diff. - CodeRabbit APPROVED the current head commit; no actionable comments. No unresolved review threads or unanswered human questions.
CI status
All checks green or skipped: CI Lint/ShellCheck/Secret-scan(gitleaks)/Agent Security Scan = SUCCESS, CodeQL Analyze (actions) = SUCCESS, SonarCloud Quality Gate = passed, AgentShield = SUCCESS, dev-lead/dispatch = SUCCESS. Skipped checks are not-applicable ecosystem audits. Note: mergeStateStatus=BLOCKED / reviewDecision=REVIEW_REQUIRED reflects a required org-leads human review gate (branch protection), which is separate from this automated assessment.
Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.
…#517) * docs(ci-standards): correct stale "ring model is the next phase" note The Reusable workflow versioning section claimed the next/ring_n channels and soak-gated ring promotion were "the next phase" / not yet built. They are in fact implemented and in production for the .github-private agents (dev-lead, pr-review) via scripts/cut-release.sh + docs/release/ (epic #495). Update the Rollout status note to reflect reality, point to that authoritative process as the source of truth, and state that .github-hosted reusables are being brought under the same model (cut-release.sh extension) — with stable-only as an explicit interim, not the target. Refs petry-projects/.github-private#870, #866. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(reviews): address review comments [skip ci-relay] --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: donpetry-bot <281750570+donpetry-bot@users.noreply.github.com>
…DR (#869) (#520) * docs(standards): formalize the agent canary-ring/soak/promotion model + ADR (#869) The rings model in ci-standards.md was documented aspirationally and as a cut-release.sh-only (manual) process. dev-lead v1.4.0 has now shipped end-to-end through the automated, health-gated pipeline, so promote the standard to match: - Ring table → the canonical host-relative model: next=host, ring0=other org-infra repo, ring1=named low-traffic consumers, stable=rest. Points at canary-rings.json as the membership SoT. - "Rollout status" → reflects the built automation: canary-rollout.sh + the 4h evaluate / dispatch-gated promote, the concrete soak gate (healthy >= ceil(baseline/7) AND failure-rate <= baseline, no floor), rollback mechanics, and the codified release-channel-tags ruleset (apply-rulesets.sh). - New ADR docs/initiatives/agent-canary-rings-adr.md — records the decision + rationale (immutable releases + moving channels, host-relative rings, health-gated promotion, circular-dependency fix). DRAFT until the host-repo implementation PRs land (.github-private #878 canary-rollout, #889 ruleset codify, #880 SHA-pin guardrail) — this standard references them. Closes #869. Refs #495, #499, #500, #501, #502, #868. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(bot): address bot feedback [skip ci-relay] * fix(reviews): address review comments [skip ci-relay] --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: donpetry-bot <281750570+donpetry-bot@users.noreply.github.com> Co-authored-by: Don Petry Bot <donpetry+bot@gmail.com>
* feat(audit): make centralized-stub check ring-aware (#870) The 6 #482 reusables (auto-rebase, dependency-audit, dependabot-automerge, dependabot-rebase, agent-shield, pr-review-mention) are moving onto the canary-ring model (epic #495). The compliance audit must ACCEPT a repo's ring-tier channel pin before any stub is repinned — otherwise dev-lead remediation reverts the change, the #482 revert-collision lesson. Changes: - Add ring_tier_for_repo(): maps each repo to its tier (next=.github-private, ring0=.github, ring1=TalkTerm+bmad-bgreat-suite, stable=broad fleet). Mirrors the epic #495 topology and cut-release.sh. - check_centralized_workflow_stubs: the 6 reusables now carry a `RING` sentinel canonical. At check time the expected pin resolves to the repo's tier channel (e.g. agent-shield/ring1 on a ring1 repo); the transitional legacy grace accepts every ring channel plus the pre-ring @v1/@v2 pins so no stub is flagged or reverted mid-migration. - feature-ideation stays a fixed @v1 pin (not on the ring model). - bats: 4 new cases covering ring_tier_for_repo; existing stub_pin_acceptable cases unchanged (signature preserved). 11/11 pass. Refs #870 * fix(bot): address bot feedback [skip ci-relay] --------- Co-authored-by: donpetry-bot <281750570+donpetry-bot@users.noreply.github.com>
.github is the ring0 dogfood tier — its own callers should run the latest reusable code via a local ref so regressions surface at the source. Two were frozen on a stale @v2 cross-repo tag and weren't dogfooding; cut them over to the local-ref form already used by auto-rebase/dependabot-rebase/pr-review-mention: agent-shield.yml @v2 -> ./.github/workflows/agent-shield-reusable.yml dependabot-automerge.yml @v2 -> ./.github/workflows/dependabot-automerge-reusable.yml Verified against HEAD reusables: agent-shield inputs are all optional; dependabot-automerge's required secrets (APP_ID/APP_PRIVATE_KEY) are already supplied via the stub's `secrets: inherit` (unchanged). .github is exempt from the centralized-stub audit and the deploy sweep (SKIP_REPOS), so the local refs won't be reverted. Only affects .github's own repo automation. Closes #541. Refs #870, #495. Co-authored-by: Claude Code Bot <bot@petry-projects> Co-authored-by: Don Petry Bot <donpetry+bot@gmail.com>



Summary
Adds
standards/advanced-security.mddocumenting how GitHub Advanced Security is enabled org-wide forpetry-projects— the gap not covered by the existing per-repo settings docs.The new standard captures, as canonical org policy:
scope=all) and set as the default for new repos (default_for_new_repos=all), viagh api. Explicitly steers away from the deprecatedenable_allendpoint and one-repo-at-a-time toggling.alertsendpoint200) → push-protection live-fire canary test.ghp_…) is checksum-validated.Why this exists
This standard was written from a live org-wide GHAS rollout + verification exercise. The detect-only-pattern gotcha caused a real "push protection looks broken" false alarm that was actually the wrong canary type — worth codifying so it isn't rediscovered.
Changes
standards/advanced-security.mdAGENTS.mdstandards indexstandards/push-protection.mdandstandards/github-settings.mdVerification
markdownlint-cli2passes (0 errors) on all changed filesNotes
Documentation only — no workflow or settings changes. The org configuration it describes is already applied and verified live (all 8 public repos
enforced; push protection confirmed blocking a Stripe canary).🤖 Generated with Claude Code
Summary by CodeRabbit