Secret scanning is supposed to be the safety net that catches what code review misses: a hardcoded AWS key, a leaked database password, an API token copied into a config file and pushed by accident. GitHub Advanced Security (GHAS) ships this capability directly inside GitHub, matching commits against a curated list of roughly 200 partner-defined regex patterns for services like AWS, Stripe, Slack, and Twilio. That list is genuinely useful — it catches a large share of the most common leaked credentials with very few false positives. But it is also a finite, provider-curated list: it only catches secrets that look like formats GitHub and its partners have already cataloged. Internal tokens, homegrown authentication schemes, and credentials from services outside the partner program fall outside that net unless a team writes and maintains its own custom patterns. This post looks at what GHAS's pattern-based model covers well, where the gaps tend to show up in practice, and how Safeguard approaches secret-type detection to close them.
How many secret types does GitHub Advanced Security actually detect?
GHAS's secret scanning is built on a partner pattern program. GitHub works with cloud providers, SaaS vendors, and infrastructure companies to define the exact structure of their API keys and tokens, then ships those definitions as built-in patterns. According to GitHub's own documentation, this list currently sits at roughly 200 supported token types, covering major providers such as AWS, Azure, GCP, Stripe, Twilio, Slack, npm, and dozens of others. When secret scanning finds a match, it can also trigger push protection, which blocks the commit from being accepted in the first place on repositories where that feature is enabled.
This is a real strength: pattern matching against known, well-structured token formats is precise, and it's the reason GHAS secret scanning has a low false-positive rate for the providers it supports. It's also why GHAS secret scanning is enabled by default on public repositories and available on private/internal repositories that hold a GHAS license.
Where do pattern lists fall short?
The limitation is structural, not a bug: a pattern list can only match what's already been defined. Two categories of secrets consistently fall outside a ~200-pattern list:
- Internal and proprietary credentials. Most organizations run internal services — auth tokens for an internal API gateway, database connection strings for a self-hosted Postgres instance, service-to-service JWTs signed with a custom scheme. None of these match a partner pattern because no external partner defined them.
- Generic high-entropy secrets. Not every credential has a recognizable prefix or fixed structure. A randomly generated 32-character string used as a webhook secret, or a base64-encoded blob pasted into a
.envfile, doesn't match a regex built around a known vendor format.
GitHub's answer to the first gap is custom patterns — organizations can define their own regex-based patterns for internal secret formats. That's a legitimate mitigation, but it shifts the burden back onto the security team: someone has to know every internal secret format in advance, write a regex for it, keep that regex current as formats change, and roll it out consistently across repositories. In practice, custom pattern libraries lag behind the actual variety of credentials living in a codebase, especially in larger engineering organizations where new internal services and token formats are introduced continuously.
Does GitHub validate the secrets it finds?
GHAS also supports validity checking for a subset of its supported patterns: for token types where the partner has an API that can confirm whether a specific token is still active, GitHub can flag a detected secret as "verified" versus "unverified." This is a meaningful feature for prioritization — a verified, active AWS key is a very different incident than a token pattern match that turns out to be a revoked test credential.
The important nuance is that validity checking is partner-dependent, not universal. It's only available for the subset of the ~200 patterns where the partner exposes a verification endpoint GitHub can call. For internal secrets and for the many partner patterns without a validation API, GHAS reports a match without telling you whether the credential is live. That's a reasonable trade-off for a platform-level feature, but it means the signal quality varies a lot depending on which of the 200 patterns actually fired.
How does Safeguard approach secret-type coverage differently?
Safeguard's secret detection is built to not depend entirely on a fixed, vendor-curated pattern list. It combines several detection techniques in the same scan pass:
- Structured pattern matching for well-known provider token formats, covering the same class of common cloud and SaaS credentials that a pattern-list approach targets.
- Entropy and statistical analysis to flag high-randomness strings that look like generated secrets even when they don't match a known vendor prefix — the base64 blobs, random webhook secrets, and generated API keys that fall through a pure regex list.
- Contextual signals from surrounding code — variable names, file type, import statements, and configuration file structure — used to reduce false positives on high-entropy matches and to catch secrets assigned to variables like
db_passwordorclient_secretthat wouldn't otherwise stand out. - Custom pattern authoring so teams can define their own regex patterns for internal token formats, the same capability GHAS offers, without that being the only mechanism available for catching internal credentials.
The goal of layering these techniques is to reduce reliance on any single detection method having already been told, in advance, exactly what an organization's secrets look like.
Where else do secrets leak that repository scanning alone doesn't reach?
A second, genuinely verifiable dimension of coverage is scan surface, not just pattern count. Secrets don't only end up in tracked source files — they show up in:
- CI/CD job logs, where a misconfigured pipeline step echoes an environment variable
- Container image layers, where a secret was baked in during a build step and then removed in a later layer but still present in image history
- Infrastructure-as-code state files and templates, where a credential is written in plaintext for provisioning
- Build artifacts and compiled bundles, where a frontend build accidentally inlines an API key meant to stay server-side
GHAS secret scanning is scoped to GitHub repository content — commits, and with push protection, content being pushed to a repository. That is its designed job, and it does it within that scope. Safeguard's scanning is built to extend across these additional surfaces — CI logs, container layers, and IaC files — as part of the same secret-detection pipeline, rather than requiring a separate tool per surface. Coverage of the software supply chain has to account for the fact that a leaked credential doesn't care whether it ended up in a git commit or a Docker layer; the risk is the same, but a repository-scoped tool will only ever see one of those.
What does this mean for prioritizing which alerts to act on first?
Broader detection only helps if it doesn't drown a team in noise. The practical question isn't "how many patterns does a tool check against" — it's how many of the resulting alerts are worth someone's attention. This is where combining detection techniques with contextual signals matters most: an entropy-based match in a test fixture directory that's clearly a placeholder string should not carry the same priority as a matching AWS key pattern found in a production deployment config. Safeguard applies risk context — file location, whether the repository is actively deployed, and whether a similar credential has appeared elsewhere in the codebase — to help teams triage broader detection coverage without treating every high-entropy string as a five-alarm fire.
How Safeguard Helps
Safeguard treats secret detection as one part of a broader supply chain security posture, not an isolated repository feature. That means:
- Layered detection combining pattern matching, entropy analysis, and contextual heuristics, so coverage isn't limited to secrets that already match a predefined vendor list.
- Custom pattern support for internal and proprietary credential formats, so teams aren't forced to rely solely on the built-in list to catch what's actually running in their environment.
- Cross-surface scanning across source repositories, CI/CD logs, container images, and infrastructure-as-code, closing the gap left by tools scoped to repository content alone.
- Risk-aware triage that factors in file location, deployment status, and repeat exposure so security teams can act on the highest-risk findings first instead of working through an undifferentiated alert queue.
If your organization is currently relying on a single pattern-based scanner and wants to understand where its blind spots are — whether that's internal token formats, non-repository surfaces, or alert prioritization — Safeguard's team can walk through a coverage assessment against your actual codebase and infrastructure, not just a hypothetical pattern list.