In 2022, a Toyota subcontractor left a database access key hardcoded in a public GitHub repository for almost five years, exposing data tied to more than 296,000 customers before anyone noticed. It's a familiar pattern: a developer pastes an API key into a config file to get something working locally, commits it "temporarily," and the string sits there — readable by anyone who clones the repo — until a scanner or an attacker finds it first. Hardcoded secrets (API keys, OAuth tokens, database connection strings, private keys) are consistently among the most common causes of cloud breaches, precisely because they require no exploit, no chained vulnerability, and no privilege escalation — just a string literal and a git clone.
Snyk Code, the static application security testing (SAST) product inside Snyk's platform, is one of the tools built to catch these before a commit ever reaches production. This post walks through the publicly documented mechanics of how it identifies hardcoded secrets — what it scans for, how the underlying analysis works, and where it fits in a typical pipeline.
What kinds of hardcoded secrets does Snyk Code actually look for?
Snyk Code's secrets detection targets literal, embedded credentials across more than a dozen categories rather than a single "password" pattern. Publicly documented rule categories include cloud provider keys (AWS Access Key IDs, which follow a predictable AKIA/ASIA + 16-character format; Google Cloud API keys, which start with AIza), SaaS and developer-tool tokens (GitHub personal access tokens prefixed ghp_, Slack tokens prefixed xox, Stripe live keys prefixed sk_live_, Twilio and SendGrid API keys), PEM-encoded private key blocks (-----BEGIN RSA PRIVATE KEY-----), JSON Web Tokens, and generic database connection strings that embed a username and password directly in a URI (postgres://user:password@host:5432/db). Coverage spans Snyk Code's full supported language set — JavaScript/TypeScript, Python, Java, C#, Go, Ruby, PHP, Kotlin, Swift, and C/C++ among them — because a hardcoded key is a hardcoded key regardless of which language it's typed into.
How does Snyk Code technically detect a secret sitting in a code file?
It combines format-based signature matching with semantic, context-aware analysis rather than relying on either alone. Many secrets are easy to catch by format: cloud providers and SaaS platforms issue tokens with distinctive, largely fixed prefixes and lengths (an AWS key's AKIA prefix, a GitHub token's ghp_ prefix), so a signature or regex match against known formats catches a large share of vendor-issued credentials with high confidence and essentially no ambiguity. The harder problem is generic secrets — a custom internal API key, a hardcoded password, a random-looking config value — that don't match any known vendor format. For those, Snyk Code leans on the semantic analysis engine that underpins the rest of its SAST product: the same symbolic/AI-based code-understanding capability (built on the DeepCode AI engine Snyk acquired in October 2020) that Snyk uses to trace tainted data through an application is also used to evaluate how a suspicious string literal is used — whether it's assigned to a variable named something like apiKey or dbPassword, passed into an HTTP Authorization header, or handed directly to a database driver's connection call. That contextual signal is what separates a likely credential from an unrelated high-entropy string, such as a minified asset hash or a base64-encoded test fixture, which a pure entropy-scoring approach would be more prone to flag.
Where in the development workflow does Snyk Code actually run these scans?
It runs at several points in the pipeline rather than just at merge time. Snyk Code ships as IDE plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse, surfacing findings inline as a developer writes code — closer to a real-time linter than a scheduled scan. It's also available via the CLI (snyk code test), through SCM integrations with GitHub, GitLab, Bitbucket, and Azure Repos that post findings as pull request checks, and as a CI/CD pipeline step that can be configured to fail a build. One structural point worth understanding: Snyk Code performs a snapshot analysis of the current working tree on the branch being scanned — it is not, by design, a git-history scanner. A secret that was committed once and later deleted from the current file will not surface in a standard Snyk Code scan, because the tool is evaluating the code as it exists now, not the full commit history behind it.
How does Snyk Code keep secrets scanning from drowning developers in false positives?
It narrows matches to security-relevant context rather than treating every string literal in a file as a candidate. Because the semantic engine understands variable naming, function signatures, and where a value flows (into a network call, a crypto operation, an auth header), it can deprioritize or exclude strings that look superficially secret-like but sit in irrelevant contexts — test fixtures, mock data, or non-sensitive constants. Teams can tune this further with a .snyk policy file or inline ignore comments to suppress a specific finding, and on Snyk's enterprise plans an audited ignore-approval workflow requires a second person to sign off before a flagged secret can be dismissed, so a single developer can't quietly wave off a real finding.
What happens once Snyk Code flags a hardcoded secret?
The finding surfaces with a severity rating — hardcoded secrets are typically scored High or Critical, since exploitability doesn't hinge on chaining other bugs the way a code-execution vulnerability might — along with a rule explanation and remediation guidance, generally: rotate the credential immediately, remove the literal from source, and load the value at runtime from an environment variable or a dedicated secrets manager instead. Where a team has configured policy gates, a detected secret can block the pull request from merging. It's also worth noting what the tool can't confirm on its own: because Snyk Code only inspects the code, it has no visibility into whether a flagged credential was actually rotated after the fact — the finding persists on every subsequent scan of that branch until the literal itself is removed from the tree, regardless of what happened to the credential outside the repository.
Does source-code secrets scanning cover the whole exposure surface?
Not by itself, and this is a limitation Snyk Code shares with most SAST-based secret detectors, not a shortcoming unique to it. Because the scan is scoped to the current source tree, it doesn't replay git history for secrets that were committed and later removed, doesn't inspect container image layers or compiled binaries, and doesn't see secrets that leak through CI/CD job logs, build artifacts, or third-party open-source packages pulled in as dependencies. That's why many security teams pair SAST-based secret detection with dedicated history scanners and broader supply-chain visibility — the two are complementary layers rather than substitutes for each other.
How Safeguard Helps
Source-code secrets scanning like Snyk Code's is a necessary layer, but the exposure surface for a hardcoded credential extends well beyond the current state of a first-party repository. Safeguard's platform is built around that broader supply chain: its SAST engine applies its own hardcoded-secret and weak-credential rule set across first-party source, while its Package Firewall inspects third-party open-source dependencies before they land in a build — including behavioral signals like embedded binary blobs and obfuscated payloads that can smuggle credentials in through a dependency rather than a line of application code. Safeguard's DSPM classifiers extend secret and credential detection into connected data stores and cloud resources (S3, RDS, and similar connectors), and its runtime/CWPP detections cover credential-dumping and exfiltration behavior at execution time, after a secret has already made it past static review. Combined with SBOM generation and per-project scanner coverage that spans source repositories, package registries, container registries, and binaries, Safeguard is designed to close the gaps that any single point-in-time source-code scan — regardless of vendor — cannot see on its own.