In GitHub, what is secret scanning and what does push protection add to it?
answer
- Two timings of the same detection
- One reports, the other refuses
- History of every branch is covered
- Providers get told about public matches
- Only formats with a known shape
basics
~20 sGitHub secret scanning matches known credential formats across a repository's commits and raises alerts after the fact. Push protection applies the same detection at push time and rejects the push, so the credential never reaches the repository at all.
solid answer
~50 sSecret scanning is **detective**: GitHub matches the contents of a repository against a large set of **partner patterns** — credential formats published by providers such as cloud vendors, payment platforms and package registries — across the entire Git history of all branches, and raises an alert on the Security tab for each match. On public repositories, matches are also reported to the issuing partner, who can revoke or notify the owner. Push protection is **preventive**: the same patterns are evaluated as the push is received, and a push containing a supported secret is rejected with a message naming the secret type, the commit, and the file. The distinction interviewers want: scanning tells you a credential has leaked and must now be rotated; push protection stops it becoming a leak in the first place. Neither one covers credential formats it has no pattern for.
go deeper
Be able to state the pair plainly: GitHub finds known credential shapes in a repository and alerts on them, and push protection refuses the push before the credential lands. Know that public repositories get both for free.
Explain partner patterns, that scanning covers the full history of all branches, and that the partner programme means providers are notified for public repositories.
Add the limits: pattern coverage gaps, deliberate bypass, and the fact that neither control changes the credential's status. Show that your response plan starts with rotation, not with the alert UI.
Own the coverage and cost argument for a whole organisation: which repositories get the paid product, where custom patterns are needed for internally issued credentials, and how bypass behaviour is governed.
## Detection after the fact Secret scanning looks for strings whose *shape* identifies them as credentials. GitHub maintains a large catalogue of **partner patterns** contributed by the services that issue those credentials — a cloud access key ID, a payment-platform live key, a package registry token, an API key for a SaaS product all have distinctive, machine-recognisable formats. When secret scanning is enabled on a repository, GitHub scans the **entire Git history on all branches**, not just the tip of the default branch, and continues scanning new pushes. Matches become alerts on the repository's Security tab, each naming the secret type, the file, and the commit where it appears. This is why enabling it on an old repository often produces a wave of alerts on day one: it is finding credentials committed years ago that are still sitting in history. ## The partner programme For **public** repositories, a match against a partner pattern is forwarded to the partner that issued that credential type. The provider then does whatever their policy says — commonly revoking the credential automatically, or emailing the account owner. This runs independently of your own alert handling, and it is the reason a leaked key on a public repository is sometimes already dead by the time an engineer looks at it. Do not rely on it: the partner can only act on formats they publish, and the window before revocation is a window in which anyone scraping public pushes could have used the key. ## Validity checks An alert can also carry a **validity** status. With validity checks enabled, GitHub asks the provider whether the matched credential is currently active and shows the result on the alert. This is useful triage input — an active production key outranks a long-dead one — but it is not proof of safety. "Inactive" tells you the credential cannot be used *now*; it tells you nothing about whether it was used while it was live. ## What push protection changes Push protection moves the same detection to write time. When a push arrives containing a match for a supported pattern, the push is **rejected**. The developer sees the secret type, the commit SHA and the file and line, plus a URL that can be used to allow the push anyway. The value is enormous and simple: a secret that never lands never has to be rotated, never has to be scrubbed from history, and never gets fetched by anyone else's clone. Push protection also applies beyond `git push` — commits made through the web editor and other write paths are covered by the same check. ## The limits worth naming - **Pattern coverage is not universal.** Both features only find formats they have a pattern for. A homegrown token that looks like a random 24-character string, a database connection URL with an inline password, or a private key format nobody registered may pass straight through. Custom patterns exist precisely to close this gap. - **Push protection is bypassable.** By design, a developer can push anyway with a stated reason. That is a deliberate escape hatch so the control does not become a work stopper, and it is why bypasses are recorded and can be restricted. - **A blocked push proves nothing about the credential's safety.** If the same key is in a colleague's clone, a CI log or a Slack message, blocking one push has not protected it. ## Availability Secret scanning alerts and push protection are available at no cost on **public** repositories. On private and internal repositories they are part of GitHub's paid advanced security offering — now sold as a Secret Protection product rather than only as part of the older bundled Advanced Security licence. Naming the exact packaging matters less in an interview than knowing that public repositories get it free and private ones need a paid plan. ## How to describe the pair in one breath "Scanning is the smoke alarm, push protection is the fire door." One tells you a credential is out and must be treated as compromised; the other stops it getting out. You want both: push protection for everything going forward, scanning because history and unsupported paths still exist, and a rotation process because neither control un-leaks anything that already escaped.
- Why does enabling secret scanning on an old repository produce a flood of alerts immediately?Because it scans the entire Git history on all branches, not just current files. Credentials deleted from the working tree years ago still exist in the commits that introduced them, so every historical leak surfaces at once. Triage by validity and severity rather than trying to clear the list in one sitting.
- Does push protection guarantee no secret reaches the repository?No. It only blocks formats it has a pattern for, so homegrown tokens and passwords embedded in connection strings can pass through. It is also deliberately bypassable with a reason. It removes the large, well-shaped classes of leak; it is not a substitute for keeping credentials out of source in the first place.
- What does a validity check on a GitHub secret scanning alert actually tell you?Whether the provider considers that credential currently active. It is triage input, not an all-clear: an inactive result says the key cannot be used now, not that nobody used it while it was live. A live-and-valid result should be treated as an incident and revoked immediately.
saying these in an interview costs you the question
- Thinks secret scanning only looks at current files
- Believes push protection catches every possible secret
- Treats an inactive validity result as proof of no compromise
- Assumes deleting the file resolves the alert
- Cannot distinguish detection after the fact from prevention at push