| English | 中文 |
Security governance must at least cover credential, dependency, and code scanning.
For regular teams, the easiest way to cause a major incident is by committing tokens, passwords, private keys, internal addresses, or production configurations into the repository.
Use these capabilities as security checkpoints during the PR and push stages, in combination with branch protection, Rulesets, and CI. See Enterprise GitHub Workflow Stack.
GitHub secret scanning scans for credential leak risks within the repository and generates alerts upon finding suspicious secrets.
The GitHub documentation states that secret scanning will scan the Git history of all branches in the repository.
The specific availability varies by repository type, organization plan, and GitHub security capabilities; rely on the repository settings page and official documentation for actual details.
Push protection identifies possible secrets when a developer pushes, preventing them from entering the remote repository.
This is more valuable than post-facto discovery because it intercepts risks before they enter the history.
The first step is always to revoke and rotate the secret.
Do not assume that deleting the file or reverting the commit makes you safe. Traces may have already been left in Git history, forks, caches, and logs.
Recommended workflow:
For detailed processing, see Remove Secret from History.
.env, private keys, and tokens to the repository.env.example for local developmentDependabot turns dependency upgrades and GitHub Actions version upgrades into reviewable PRs.
Code scanning is suited for shifting left static security issues into PR or main branch checks, and assigning the issues to owners via alerts.
These two types of capabilities must be coordinated with CODEOWNERS, required checks, and processing SLAs; otherwise, they merely increase the volume of alerts.