GitHub spent 2024 and early 2025 quietly rebuilding one of its most-used security features into a standalone product. On April 14, 2025, GitHub split GitHub Advanced Security (GHAS) into two independently licensed SKUs: GitHub Secret Protection and GitHub Code Security. The $49-per-active-committer-per-month GHAS bundle is gone; Secret Protection now runs $19 per active committer per month and ships push protection, custom patterns, validity checks, and AI-assisted detection of unstructured passwords in one package. That timing isn't cosmetic. GitGuardian's annual State of Secrets Sprawl research put the number of secrets found in public GitHub commits at 12.8 million in 2023 alone, and internal, private-repo exposure is understood to run several multiples higher. This piece breaks down what Secret Protection actually does, what changed from the old GHAS bundle, where the coverage gaps still sit, and how teams close them.
What is GitHub Secret Protection, and how is it different from GitHub Advanced Security?
GitHub Secret Protection is the secret-detection half of GHAS, unbundled into its own product and price. Previously, an organization that wanted push protection or custom regex patterns on private repos had to buy the full GHAS license, which also included code scanning (CodeQL) whether or not the team used it. As of the April 2025 restructuring, Secret Protection ($19/active committer/month) and Code Security ($30/active committer/month) are sold separately on GitHub Enterprise Cloud and Server, so a team that only cares about credential leakage no longer subsidizes SAST tooling it isn't running. Public repositories retain free secret scanning and push protection regardless of license, a policy GitHub made default in December 2023. The feature set inside Secret Protection — provider partner patterns, push protection, custom patterns, validity checks, and generic-password detection via a fine-tuned model (public beta since 2024) — is unchanged from GHAS; only the packaging and price moved.
How does push protection actually stop a secret before it lands in a repo?
Push protection intercepts the push itself, scanning each commit against GitHub's detection patterns before the objects are accepted, and rejects the push if a match is found. The developer sees the failure in git push output or the web UI, with the exact file and line, and must either remove the secret, or bypass with a logged reason (used in tests, false positive, or "I'll fix it later"). Since December 2023, this has applied by default to all public repositories for the roughly 200 token types GitHub detects across 190+ partner services (AWS, Stripe, Slack, npm, Azure, and others). On private repositories it requires a Secret Protection license and org-level opt-in. GitHub added delegated bypass in 2024, letting org owners require a designated security reviewer to approve any bypass request instead of leaving it to the committing developer's judgment — a meaningful control given that "I'll fix it later" is one of the most common bypass justifications GitHub reports seeing in the wild.
What do custom patterns catch that GitHub's 200 built-in detectors miss?
Custom patterns catch internally issued credentials that no partner integration will ever know about — think sg_live_[A-Za-z0-9]{32}-style internal API keys, service-account tokens, or proprietary database connection strings unique to a company's naming convention. GitHub's out-of-the-box list only covers secrets from providers who've published a detectable format to GitHub's partner program; anything an internal platform team mints itself is invisible until someone defines a pattern for it. Custom patterns can be configured at the repository, organization, or enterprise level using standard regex, with optional pre- and post-match validation (e.g., requiring a checksum or specific prefix to cut false positives), and enterprises can layer dozens of patterns across business units with different formats. The catch: someone in security or platform engineering has to actually write, test, and maintain those regexes, and a stale or overly broad pattern generates as much noise as it prevents.
What are validity checks, and why do they matter more than raw detection?
Validity checks call back to the issuing provider's API to confirm whether a detected secret is still live, turning a flat list of regex matches into a prioritized incident queue. A regex match only tells you a string looks like an AWS key; a validity check actually asks AWS whether that key still authenticates, returning active, inactive, or unknown. For supported partners — AWS, Azure, Google Cloud, Slack, Stripe, npm, and a growing list of others — this happens automatically and is visible directly in the alert. GitHub extended validity checks to custom patterns in 2024, letting organizations point a custom pattern at their own internal validation endpoint so an internally issued token gets the same active/inactive triage as a partner secret. This is the difference between a security team drowning in "1,400 secrets found" after a first retroactive scan of an old monorepo, and a team that can see the 40 of those that are still live and worth an emergency rotation today.
Where does GitHub's secret protection still fall short?
The biggest gap is scope: Secret Protection only sees what happens inside a GitHub-hosted git push, so anything landing in CI/CD job logs, build artifacts, container images pushed to a registry, Slack messages, Jira tickets, or a developer's local .env file never gets scanned at all. A secret can pass push protection cleanly and still leak an hour later through a debug log dumped by a GitHub Actions workflow. Second, validity checks only work where GitHub has a partner integration or where a team has built and maintained its own validation endpoint for custom patterns — most home-grown secrets get detected but not automatically confirmed as live, leaving the "is this actually exploitable" judgment call to a human. Third, retroactive scanning of pre-existing history in a large, long-lived monorepo commonly surfaces thousands of historical alerts at once, and GitHub has no built-in workflow for bulk triage, ownership assignment, or automated rotation — someone still has to work the backlog repo by repo. Finally, licensing is per active committer across the whole enterprise, and coverage is GitHub-only: organizations running GitLab, Bitbucket, self-hosted Gitea, or storing secrets outside of Git entirely (config management, artifact stores, internal wikis) get zero protection from this product regardless of how much they spend on it.
How Safeguard Helps
Safeguard treats GitHub Secret Protection as one signal source among many, not the whole answer, because the leak paths that matter most in a real supply-chain incident routinely start outside the git push GitHub can see. Safeguard continuously monitors CI/CD job logs, build artifacts, container images, and package registry uploads for the same credential patterns, and cross-references any hit with its live view of your dependency graph and deployment surface — so a leaked key isn't just flagged, it's ranked by what it can actually reach. For the retroactive-scan backlog problem, Safeguard clusters historical secret alerts by owning team and repository, attaches validity status even for internally issued formats that GitHub's custom-pattern validation isn't wired up for, and routes confirmed-live secrets into an automated rotation workflow instead of a static dashboard entry. And because Safeguard isn't tied to a single SCM, teams running a mixed GitHub, GitLab, and self-hosted environment get one consistent secret-detection and revocation policy instead of GitHub-only coverage with blind spots everywhere else. The result is the same push-time prevention GitHub Secret Protection already does well, plus the full-lifecycle visibility and response that a single git-hook check was never designed to provide.