What's changed: New GH-500 Chapter 2 (enabling & prevention = repo/org enablement, public vs private availability/licensing, Push Protection at the source, validity checks and prioritized alerting, mandatory token revocation; alert management = lifecycle [created→open→resolved/dismissed], role-based/delegated bypass, recipients/exclusions, custom secret patterns [regex])
2.1Enabling Secret Protection and Preventing Exposure
Understand enabling/configuring Secret Protection at repo/org levels, behavior differences for public vs private/enterprise, Push Protection that prevents exposure at the source, and validity checks with prioritized alerting for high-confidence secrets.
Secret Protection (the product bundling secret scanning/push protection) detects secrets committed to a repository (API keys, tokens, connection strings) and also prevents them before they are committed. Once a secret enters history, fully removing it is hard and a leak can be a serious incident—so beyond detection (after the fact), prevention at the source is emphasized.
2.1.1Enabling and availability
Secret Protection can be enabled per repository or per organization, with org-level bulk application and default configurations. On public repositories, secret scanning runs free, and detected partner secrets (from providers integrated with GitHub) may be auto-notified to the provider. To use the full set (Push Protection, custom patterns) on private/enterprise, a Secret Protection license (one of the products split from GHAS in 2025) is required. Settings configure scope, recipients, and exclusions.
2.1.2Push Protection — prevent at the source
Push Protection blocks the moment a developer tries to push a commit containing a secret (the core of the prevention-first strategy in Chapter 1). On detection the push stops, and the developer removes the secret or, with justification, bypasses (requires a recorded reason or approval). This keeps secrets out of history in the first place, avoiding the painful history rewriting and revocation needed after the fact. Orgs control "who may approve a bypass" via delegated bypass.
2.1.3Validity checks and prioritized alerting
Not all detected secrets are equally urgent. Validity checks verify whether a detected token is still valid (live)—via provider APIs—and prioritize alerting for high-confidence (active) secrets. This focuses attention on genuinely dangerous leaks, so you’re not distracted by revoked or test dummy values—the aim is effective prioritization.
Common: (1) Enable at repo/org; free on public, licensed on private/enterprise. (2) Push Protection blocks secret pushes at the source (prevention-first), keeping them out of history; bypass needs reason/approval and delegated bypass controls approvers. (3) Validity checks prioritize alerting for live, high-confidence secrets. (4) Prevention is cheaper than post-hoc history rewriting.
Watch out: (1) Detection (find after commit) and Push Protection (prevent before push) differ—prevention is ideal. (2) Once a secret is committed, deleting the file leaves it in history—revoking (rotating) the token is mandatory. (3) Push Protection bypass isn’t unconditional—approval/recording is required. (4) Validity checks confirm "is it live," not replace detection itself.
2.1.4Section summary
- Enable Secret Protection at repo/org; free on public, licensed on private/enterprise
- Push Protection blocks secret pushes at the source; bypass needs approval/recording and is governed via delegated bypass
- Validity checks prioritize alerting for live, high-confidence secrets
- A committed secret isn’t removed by deleting the file—revoke (rotate) the token
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which feature blocks the moment a developer tries to push a commit with a secret, preventing it from entering history?
Q2. Among many detected secret alerts, you want to prioritize the ones still active and truly dangerous. What helps?
Q3. A secret was accidentally committed and is now in history. What is the most important action?
Q4. What is generally required to use Push Protection or custom patterns on a private repository?
Q5. You want Push Protection blocks to be bypassable only with approval when justified. What do you configure?
Q6. Which correctly relates detection (after the fact) and Push Protection (prevention)?