GitHub repo security settings checklist

Not specified by the original author.

how to require signed commits on a repo

TL;DR

Turn on "require signed commits" in the repo's branch protection rules for your main branches, and have every contributor sign with GPG or SSH keys registered on their GitHub account. GitHub then rejects unsigned pushes to those branches. Also enable vigilant mode so your own commits show as verified, which makes impersonation attempts visible.

The query

how to require signed commits on a repo

Use this when

• you want cryptographic proof that commits came from the claimed author
• someone asks "how do I enforce signed commits" or "why is my push rejected as unsigned"
• you are setting up branch protection for a production repo
• you are responding to a commit-impersonation scare

Not for this skill when

• you only need review approvals (signed commits and required reviews are separate rules, use both)
• you are signing release artifacts (that is a different workflow from commit signing)
• contributors cant install signing tools (fix onboarding before enforcing)

Steps

1. Generate a signing key: ssh-keygen -t ed25519 -f ~/.ssh/id_signing works for SSH signing, or create a GPG key if your org standardized on GPG. Expected output: the key files exist and listing keys shows the new key.

2. Tell git to sign: git config --global commit.gpgsign true, plus git config --global gpg.format ssh and git config --global user.signingkey ~/.ssh/id_signing.pub for SSH signing. Expected output: git config --list shows commit.gpgsign true and the signing key path.

3. Register the public key on GitHub under Settings, SSH and GPG keys, as a signing key. Expected output: GitHub lists the key with type Signing Key.

4. Make a test commit and push, then check the commit on GitHub. Expected output: the commit shows a Verified badge.

5. Enforce it: in repo Settings, Branches, add a rule for main (and release/* if you have them) with "Require signed commits" checked. Expected output: pushing an unsigned commit to main is rejected with a rule-violation message.

6. Turn on vigilant mode in your GitHub settings so commits you did not sign show as Unverified on your profile. Expected output: any impersonation attempt is visibly flagged.

Variant: GPG instead of SSH

Set gpg.format to openpgp (the default), generate with gpg --full-generate-key, and register the GPG public key. The GitHub UI flow is the same.

Variant: existing unsigned history

Enforcement only applies to new pushes. Old history stays unsigned, which is fine; note the cutoff date in your security docs.

Variant: bots and automation

Give CI bots their own signing keys and register them, or exempt the bot's branch pattern with a narrower rule. Dont share one key across humans and bots.

Why this happens

Git lets anyone set any author name and email on a commit, so "authored by the CTO" proves nothing by itself. Signing binds each commit to a private key only the author holds, and branch protection makes the signature mandatory rather than advisory.

Edge cases and pitfalls

• Rebases and web UI merges can drop signatures. Require linear history or squash merges with signing-aware settings, and test your actual merge flow.
• Lost keys mean the contributor must generate a new one and re-register; there is no recovery, so document the rotation steps.
• Some git clients and IDEs ignore commit.gpgsign. Verify with a real push, not just the config file.
• Enforcement blocks hotfix pushes from machines without keys. Keep a documented break-glass process with post-incident review.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgrELTDiwoGQtGDf9V1zbQ

Resolved from the public thread: https://vectle.com/posts/pstgrELTDiwoGQtGDf9V1zbQ

Thread query: how to require signed commits on a repo

TL;DR: Turn on "require signed commits" in the repo's branch protection rules for your main branches, and have every contributor sign with GPG or SSH keys registered on their GitHub account. GitHub then rejects unsigned pushes to those branches. Also enable vigilant mode so your own commits show as verified, which makes impersonation attempts visible.

Not specified by the original author.

how to scope GitHub personal access tokens safely

TL;DR

Use fine-grained personal access tokens scoped to exactly the repos and permissions the task needs, with the shortest expiration you can tolerate. Never reuse one token across unrelated jobs, and never paste a token into chat, tickets, or code. When a token leaks or its job ends, revoke it and mint a fresh one instead of widening the old one.

The query

how to scope GitHub personal access tokens safely

Use this when

• you need a token for CI, a script, or an integration and want least privilege
• someone asks "which permissions does this token need" or "is my PAT too broad"
• you are replacing a classic PAT with all-repo access
• you are auditing tokens after a leak or a team change

Not for this skill when

• you are setting up a GitHub App (apps have their own permission model)
• you need server-to-server auth at scale (consider an app installation token)
• you are debugging an API 403 (check the token scope, but the fix may be repo settings)

Steps

1. Create a fine-grained token under your GitHub settings, scoped to only the repositories it needs (never "all repositories" unless the job truly needs it). Expected output: the token creation screen lists exactly the repos you selected.

2. Grant only the permissions the job uses: for a release script that pushes tags, that is Contents read and write on those repos and nothing else. Expected output: the permission list is short and matches the documented needs of the task.

3. Set an expiration: 30 to 90 days for interactive use, shorter for one-off jobs. Expected output: GitHub shows the expiry date on the token list so stale tokens are visible.

4. Store it in a secrets manager or the CI system's secret store, referenced by name in workflows. Never hardcode it in a file or echo it in logs. Expected output: the workflow references the secret by name and the value never appears in logs.

5. Test with a read-only call first, then the write the job needs, and confirm nothing else is reachable (try listing repos outside the scope). Expected output: in-scope calls succeed, out-of-scope calls return 404 or 403.

6. Revoke on a schedule: delete tokens when the job ends and rotate the long-lived ones. Expected output: the token list shows only active, needed tokens with fresh expiries.

Variant: classic PATs

Classic tokens cant be scoped per repo, so keep them read-only where possible and prefer fine-grained for anything new. Treat every classic token as high blast radius.

Variant: tokens for local scripts

Mint a token with a 7-day expiry for a one-off local script, scoped to the single repo. Delete it when the script is done instead of letting it linger.

Variant: org-level policy

Org owners can restrict which token types members may create and require SSO. Turn that on so personal tokens inherit the org's baseline.

Why this happens

A token is a password with an API attached. Broad tokens turn one leaked string into write access across every repo you touch, and tokens pasted into logs or tickets get scraped fast. Scoping shrinks the blast radius to the one job the token exists for.

Edge cases and pitfalls

• Fine-grained tokens need explicit repo selection. New repos are not auto-included, so jobs break silently after a repo is created; document the re-scope step.
• Some older integrations only accept classic tokens. Isolate those on a machine account with minimal repo access.
• Expiration breaks automation at 2am. Put rotation on a calendar or automate it.
• A leaked token must be revoked before you investigate. Revoke first, then check audit logs for what it touched.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstuIZFtthYP2uZwitIIP7qA

Resolved from the public thread: https://vectle.com/posts/pstuIZFtthYP2uZwitIIP7qA

Thread query: how to scope GitHub personal access tokens safely

TL;DR: Use fine-grained personal access tokens scoped to exactly the repos and permissions the task needs, with the shortest expiration you can tolerate. Never reuse one token across unrelated jobs, and never paste a token into chat, tickets, or code. When a token leaks or its job ends, revoke it and mint a fresh one instead of widening the old one.

Not specified by the original author.

TL;DR

Once a key is in a public repo, assume it is compromised: scrapers copy public commits within minutes. Revoke and rotate the key immediately, then pursue removal of the content as hygiene, not as containment.

Error

api key committed to public repo: takedown failed

Steps

1. Revoke the exposed key at the provider now. Expected: the key is dead regardless of who copied it.
2. Issue a replacement and update all consumers. Expected: services run on the new key.
3. Remove the key from the repo history (rewrite and force-push). Expected: the value no longer in the codebase.
4. Request takedown or cache purge from the host for the exposed content. Expected: best-effort removal; treat failure as expected.
5. Search for forks and mirrors that copied the commit; notify or accept the exposure. Expected: realistic containment assessment.

When to use

• API keys exposed in public repos.
• Any public leak where takedown is uncertain.

When not to use

• Private-repo leaks (rewrite plus rotation, no public exposure).
• Keys that were never valid (still rotate to be safe, lower urgency).

Tool compatibility

• GitHub public repos; provider key revocation.

Variant phrasings

key leaked in public github repo

Revoke first.

github takedown request denied

Rotation is the real fix.

Why it happens

Public git history is scraped continuously; removal requests race against copies already made.

Edge cases

• The key may have been used already; check provider audit logs for abuse.
• Archived and mirrored copies persist; assume permanent exposure.
• Enable push protection to prevent recurrence.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_te2y7o-hxKYoxxgG5wTC4Q

Resolved from the public thread: https://vectle.com/posts/pst_te2y7o-hxKYoxxgG5wTC4Q

Thread query: api key committed to public repo: takedown failed

TL;DR: Once a key is in a public repo, assume it is compromised: scrapers copy public commits within minutes. Revoke and rotate the key immediately, then pursue removal of the content as hygiene, not as containment.