gvkhosla/github-security-hardening-skill

Harden a GitHub repository

Treat repository security as a user-controlled change. Inspect first, explain the practical effect, obtain approval for live-setting changes, apply narrowly, and verify.

Read references/controls.md before proposing or applying changes. It contains the six controls, current API routes, availability notes, and failure modes.

Workflow

1. Resolve the exact OWNER/REPO.
   • Prefer the current checkout: gh repo view --json nameWithOwner,defaultBranchRef,visibility.
   • If there is no unambiguous repository, ask for it.
2. Confirm authentication and authority.
   • Run gh auth status.
   • Require repository admin access for settings changes.
   • Never print tokens or auth headers.
3. Audit without changing anything.
   • Run python3 scripts/audit.py --repo OWNER/REPO --markdown.
   • Supplement unclear or unavailable results with read-only gh api calls from the reference.
   • Report enabled, missing, partial, unavailable, and unknown distinctly. A 404 can mean disabled, unsupported, or insufficient access; do not guess.
4. Inspect repository context before proposing changes.
   • Identify the default branch, visibility, active rulesets or classic branch protection, current workflows, supported CodeQL languages, and whether the repository is maintained by one person.
   • Preserve existing protections. Merge with them; never replace or weaken them.
5. Present a compact plan with:
   • current state;
   • exact change;
   • benefit in plain language;
   • possible disruption;
   • rollback method.
6. Ask for explicit approval before changing GitHub settings, committing files, creating workflows, or adding branch rules.
   • One approval may cover a clearly enumerated batch.
   • Obtain a separate explicit choice for branch protection if one approval could prevent a solo maintainer from merging.
7. Apply only the approved controls.
   • Prefer current GitHub REST endpoints through gh api.
   • For SECURITY.md and optional workflow files, create a branch and pull request unless the user explicitly asks for a direct commit.
   • Make idempotent changes: skip settings already enabled and update existing files rather than creating duplicates.
8. Verify by rerunning the audit and reading the changed files/rules.
9. Report what changed, what remains, any plan/visibility limitations, and links to the repository settings or pull request.

Safety rules

• Default to audit-only when the user asks to "check," "review," or "assess."
• Do not enable, disable, or alter a live setting without explicit authorization.
• Do not weaken existing rules, delete bypass actors, or overwrite a ruleset.
• Do not claim branch protection is complete merely because pull requests are required. Verify one approval is required and the rule targets the default branch.
• Do not create a required status check before that check has run successfully; doing so can block every merge.
• Do not install dependency-review enforcement automatically. Dependency review becomes available with the dependency graph. Offer the action as an optional enforcement layer and verify repository eligibility first.
• Do not invent a vulnerability contact. Ask the user for a monitored private contact or point reporters to private vulnerability reporting.
• Never place secrets, private vulnerability details, or credentials in commits, issues, logs, or chat output.
• For a leaked secret, enabling scanning is not remediation. Revoke or rotate the credential first, then remove it from history as a separately approved operation.
• Use the repository's existing conventions and preserve unrelated local changes.

Completion format

Return a six-row checklist:

Control	Before	After	Evidence / next step

State plainly whether the repository now matches all six recommendations. If not, name the precise blocker without presenting it as success.