Snyk secret scanning detects hardcoded credentials through two paths: rules built into the Snyk Code SAST engine, and a dedicated Snyk Secrets product that pairs entropy and regex detection with machine-learning context analysis. If you already run Snyk Code you are getting some secrets detection for free, but understanding where the coverage starts and stops keeps you from a false sense of safety.
Two products, two levels of coverage
For years, Snyk's answer to leaked credentials was a set of hardcoded-secret rules inside Snyk Code. These rules fire during a normal SAST scan when the analyzer sees something that looks like an API key, private key, or password literal sitting in source. They are useful, but Snyk itself describes them as part of the code analysis rather than a standalone secrets solution.
More recently Snyk introduced Snyk Secrets, a purpose-built engine that combines high-entropy string detection, regex signatures, and semantic analysis of the surrounding code. The goal of the newer approach is to cut the false positives that plague pattern-only scanners by understanding whether a matched string is actually a live credential or just a test fixture. If your organization is evaluating secret scanning specifically, that distinction matters: the SAST rules and the dedicated product are not the same depth of coverage.
What Snyk secret scanning actually catches
The detection surface covers the usual suspects:
- API keys and tokens with recognizable formats (AWS, Stripe, GitHub, and similar)
- Private keys in PEM blocks
- High-entropy strings that resemble generated secrets
- Passwords assigned to obviously named variables
Pattern-based detection is strong when the secret has a distinctive shape. An AWS access key ID starts with a fixed prefix and has a known length, so a regex catches it reliably. The harder cases are generic secrets, a database password that is just a normal-looking string, for example, where entropy scoring and code context do the heavy lifting.
// This gets flagged: recognizable shape + suspicious variable name
const stripeKey = "sk_live_51H8xY2eZvKY...";
// This is harder: no distinctive format
const dbPassword = "correct-horse-battery-staple";
The second case is exactly where an ML-informed engine earns its keep, and where a pure regex scanner produces either misses or noise.
Running Snyk secret scanning in CI
Snyk Code runs through the CLI or the platform integrations. A local SAST scan is a single command:
snyk code test
This walks your source tree and reports code issues, including hardcoded secret findings, with severity levels. In a pipeline you typically gate on severity so a critical finding blocks the merge:
snyk code test --severity-threshold=high
For the dedicated Snyk Secrets capability, availability depends on your Snyk plan and the integration you enable, so check what your tier includes before you assume full coverage. Pricing and packaging shift over time, so verify the current plan details in your Snyk account rather than trusting a blog number.
The limitation every team should know
Snyk secret scanning, like almost every scanner in this category, inspects the current state of your files. It does not, on its own, rewrite your Git history or rotate a leaked key. If a credential was committed six months ago and later deleted from the working tree, a scan of the current checkout will not surface it. The secret still lives in the history and remains exploitable to anyone who clones the repo.
That is why secret scanning is a detection control, not a remediation. When it fires, the response is the same regardless of tool:
- Treat the secret as compromised the moment it hit a remote branch.
- Rotate it immediately at the source of truth.
- Purge it from history if the repo is or ever was public, using a tool like
git filter-repo. - Add a pre-commit hook so the next one never lands.
A pre-commit hook stops secrets before they reach the remote at all, which is cheaper than any post-hoc scan:
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
Where secret scanning fits in a broader program
Leaked credentials are one of the most reliably exploited entry points in real breaches, and public GitHub sees tens of millions of new secrets a year. But a hardcoded key is only one class of supply chain risk. Vulnerable dependencies, misconfigured containers, and untrusted transitive packages all sit alongside it. Snyk secret scanning covers the credential slice; you still need software composition analysis for the dependency tree and configuration scanning for infrastructure.
Snyk is a capable option in this space, and so are focused tools like Gitleaks and TruffleHog. If you are weighing platforms, our comparison of scanning approaches lays out how coverage and pricing differ. The pragmatic move for most teams is a pre-commit hook plus a CI-level scan, so you catch secrets both before and after they are committed. An SCA platform such as Safeguard can sit next to that to cover the dependency risk that secret scanning does not touch.
FAQ
Does Snyk secret scanning scan Git history?
Not by default. Snyk Code inspects the current state of your files. Secrets buried in old commits will not appear unless you scan those revisions specifically. Assume any secret that ever reached a remote is compromised and rotate it.
Is Snyk secret scanning included in the free plan?
Snyk Code and its hardcoded-secret rules are available on entry tiers with usage limits, but the dedicated Snyk Secrets capabilities and higher test volumes depend on your plan. Confirm the exact entitlements in your Snyk account, since packaging changes.
What is the difference between Snyk Code secrets rules and Snyk Secrets?
The Snyk Code rules are part of the SAST engine and flag obvious hardcoded secrets during a code scan. Snyk Secrets is a dedicated engine that adds entropy analysis and ML-driven context to reduce false positives on secrets that lack a distinctive format.
What should I do the moment a secret is detected?
Rotate it first, because detection means it may already be exposed. Then remove it from the working tree and, if the repository is or was public, purge it from history. Add a pre-commit hook to prevent recurrence.