Secret Scanning

Secret scanning searches a repository's Git 1,932 history, issues, pull requests and discussions for credentials in hundreds of formats; a partner's token (AWS 24 , Stripe 238 , npm 2,036 and more) found in a public repository is also reported to that provider, which usually revokes it. Push protection goes further and rejects a push that contains a supported secret before it is stored. Both are on by default for public repositories, as BookNest's settings show:

gh api repos/{owner}/{repo} --jq '.security_and_analysis | with_entries(.value |= .status)'

{"dependabot_security_updates":"enabled","secret_scanning":"enabled",
"secret_scanning_non_provider_patterns":"disabled","secret_scanning_push_protection":"enabled",
"secret_scanning_validity_checks":"disabled"}

To see push protection work without risking a real credential, GitHub 29 's documentation supplies a dummy token that its scanners recognize. It went into a throwaway branch:

git switch -c try/push-protection
echo 'GH_TOKEN: "secret_scanning_ab85fc6f8d7638cf1c11da812da308d43_abcde"' > leak-test.yml
git add leak-test.yml && git commit -qm "Try to commit GitHub's dummy token"
git push origin try/push-protection

Switched to a new branch 'try/push-protection'
remote: error: GH013: Repository rule violations found for refs/heads/try/push-protection.
...
remote:     - Push cannot contain secrets
...
remote:          - commit: 1022a9c0429917991f7fbe8ebf0c0490f29f9a4e
remote:            path: leak-test.yml:1
remote:        (?) To push, remove secret from commit(s) or follow this URL to allow the
secret.
remote:        https://github.com/binarybehemoth/booknest/security/secret-scanning/
unblock-secret/3JpAD7NUeqFDXdYIczxnciVkMX2
...
 ! [remote rejected] try/push-protection -> try/push-protection (push declined due to
repository rule violations)

Nothing reached GitHub; the branch was then deleted. For a real secret, remove it from the commit (Amending Commits and Interactive Rebase), revoke it anyway, and push again. The unblock URL lets someone with write access bypass the block with a reason (used in tests, false positive, fix later), which is recorded as an alert. The two settings still off above are non-provider patterns (private keys, connection strings) and validity checks, which ask the provider whether a found token is live.