Ghas Config Reviewer

ghas-config-reviewer

A Category 3 ops tool. The user runs this against a repo (or org) and gets a structured posture report: what's configured, what's missing relative to the baseline, what's misconfigured.

When to use

• New-repo onboarding review.
• Periodic sweep across the org's important repos (high-blast-radius, regulated-data-handling, etc.).
• Before stakeholder reviews of GHAS posture (legal, audit, security architecture).
• Validating that an exception expired and the baseline is now enforced.

When NOT to use

• Workflow-level review → actions-workflow-hardener.
• Repository-level governance beyond GHAS (CODEOWNERS specifics, ruleset patterns) → repo-golden-path-scorer.
• Investigating a specific CodeQL alert → that's CodeQL triage, not configuration review.

Baseline (the org's expected state)

This is the documented expected state for a "fully GHAS-onboarded" repo in the org. Deviations get flagged.

Code scanning

Secret scanning

Dependabot

Dependency review

Branch protection

Actions allowed list

Workflow

1. Identify target — the user provides a repo (owner/repo) or org name.
2. Inspect via gh api:
   • gh api repos/{owner}/{repo} for repo settings.
   • gh api repos/{owner}/{repo}/code-scanning/default-setup for code scanning state.
   • gh api repos/{owner}/{repo}/branches/{default}/protection for branch protection.
   • gh api repos/{owner}/{repo}/secret-scanning/alerts for secret scanning enablement (presence of the endpoint signals enabled).
   • gh api repos/{owner}/{repo}/vulnerability-alerts for Dependabot alerts.
   • gh api repos/{owner}/{repo}/contents/.github/dependabot.yml for version update config.
   • gh api orgs/{org}/actions/permissions for org-level Actions allow-list (when org-scoped).
3. Compare each setting against the baseline above.
4. Produce findings — structured list as below, presented in chat.
5. Persist the report — after presenting findings, write the full findings note via vault-writer.write_research to vault/research/ghas/YYYY-MM-DD-config-review-{repo}.md (frontmatter per research.yml, topic: ghas; body = findings grouped by category + summary) so the next session can query it.

If gh api access fails (no auth, no permission), stop and report: emit a manual checklist the user can run.

Output shape

{
  "target": "owner/repo",
  "findings": [
    {
      "check_id": "GHAS-SEC-001",
      "category": "secret-scanning",
      "severity": "critical",
      "current_state": "disabled",
      "expected_state": "enabled with push protection",
      "remediation": "Enable secret scanning via Settings → Code security and analysis. Then enable push protection. Both are no-cost for GHAS-licensed repos.",
      "reference": "GitHub Docs — About secret scanning"
    }
  ],
  "summary": {"critical": 0, "high": 2, "medium": 3, "low": 0, "info": 5, "total": 10}
}

Group findings by category (code-scanning, secret-scanning, dependabot, dependency-review, branch-protection, actions-allowlist).

Lands at vault/research/ghas/YYYY-MM-DD-config-review-{repo}.md (workflow step 5).

Composes with

• The user's gh CLI (already authenticated to the org).
• vault-querier — surface related research / prior audits.
• vault-writer.write_research — persists the findings note (workflow step 5).
• Related skills: actions-workflow-hardener (workflow-level), codeql-onboarding-helper (CodeQL setup decisions), dependabot-config-helper (Dependabot config generation).

Acceptance test (for step 13 done-criteria)

Run against a target repo the user nominates. Expected:

• Successful gh api calls for all baseline endpoints, OR a manual-checklist fallback if auth fails.
• Findings list grouped by category with severity correctly assigned.
• Each finding has a remediation step that's concrete and actionable.

Live exercise deferred to first real invocation (requires gh CLI auth + a target repo).