A hardcoded credential is a password, API key, token, or encryption key written directly into source code, a config file, or a container image instead of being fetched from a vault at runtime. In May 2023, Toyota disclosed that an access key had been hardcoded into T-Connect app source code and left exposed on a public GitHub repository from December 2017 to September 2022 — nearly five years — putting the data of 296,019 customers at risk. In September 2022, an Uber contractor's PowerShell script contained a hardcoded admin password for the company's PAM tool, which an attacker used to pivot across AWS, GCP, Slack, and internal dashboards. CWE-798, "Use of Hard-Coded Credentials," has appeared on the CWE Top 25 Most Dangerous Software Weaknesses list for multiple consecutive years. This glossary entry breaks down what hardcoded credentials risk actually means in practice, how these secrets get into code, and how security teams find and fix them before attackers do.
What Counts as a Hardcoded Credential?
A hardcoded credential is any secret — password, API key, OAuth token, database connection string, SSH private key, or symmetric encryption key — embedded as a literal value in application code, infrastructure-as-code templates, CI/CD YAML, or a container layer, rather than injected at runtime from a secrets manager. In practice this shows up as recognizable patterns: an AWS access key starting with AKIA, a Slack token starting with xox, a Stripe live key starting with sk_live_, or a plain DB_PASSWORD = "prod123!" line in a settings file. GitGuardian's State of Secrets Sprawl report found more than 12.8 million secrets exposed in public GitHub commits in 2023 alone, a category that includes hardcoded credentials alongside leaked .env files and tokens pasted into commit messages. The common thread is that the secret is static and discoverable by anyone who can read the artifact — source file, Docker image, or build log — rather than something issued dynamically and scoped to a short-lived session.
Why Do Hardcoded Credentials Pose Such a High Risk?
Hardcoded credentials are high risk because once a secret is committed to source control or baked into a container image layer, it persists indefinitely in git history, build caches, and registry layers — even after the offending line is deleted from the current file. Deleting a credential from main does not remove it from commit a1b2c3d, and anyone who clones the repository, forks it, or pulls an old image tag can still recover it with git log -p or docker history. This is what separates hardcoded credentials from most other vulnerability classes: a SQL injection flaw is neutralized the moment the patched code ships, but a hardcoded API key is compromised the moment it's committed, regardless of whether the file is later "fixed." The blast radius also tends to be broad — a single leaked cloud access key can grant read/write access to every S3 bucket, EC2 instance, or IAM role the associated account can reach, not just the one application it was written for. Attackers know this: credential-based initial access is one of the most common entry points tracked in Verizon's annual Data Breach Investigations Report, alongside phishing and exploited vulnerabilities.
How Do Hardcoded Credentials Get Into Code in the First Place?
Hardcoded credentials get into code mostly through developer convenience during testing and debugging — pasting a working API key into a script to unblock local development, then forgetting to strip it before committing. Common entry points include: a developer hardcoding a database password to get a feature working locally rather than wiring up the team's secrets manager; copying a credential from a Slack thread or internal wiki directly into a config file; inheriting legacy code where secrets were hardcoded years ago and nobody has since rotated or removed them; writing plaintext environment variables directly into a CI/CD pipeline YAML file instead of referencing a pipeline secret store; embedding a credential in a Dockerfile ENV or ARG instruction, which persists in every image layer even if a later RUN command deletes the file; and committing a .env file that was supposed to be covered by .gitignore but was added before the ignore rule existed. Forked or cloned repositories compound the problem — a secret hardcoded in a private repo for "just this once" often ends up in a public fork months later when a developer open-sources a side project without scrubbing history.
What Are Examples of Real-World Breaches Caused by Hardcoded Credentials?
Real-world breaches caused by hardcoded credentials span cloud providers, automotive manufacturers, and ride-sharing platforms, and they consistently show the same pattern: a single overlooked secret with broad access. Toyota's T-Connect incident (exposed December 2017, disclosed May 2023) involved a hardcoded key sitting in public source code for nearly five years, affecting 296,019 customer records including email addresses and vehicle registration numbers. In September 2022, Uber's breach involved an attacker who, after gaining VPN access via social engineering, found a hardcoded credential for the company's Thycotic privileged access management tool inside a PowerShell script on a network share — that single credential unlocked access to Uber's AWS console, GCP project, Slack workspace, and internal admin tools. In March 2022, the Lapsus$ group leaked roughly 190GB of Samsung source code that reportedly included hardcoded credentials and algorithms for biometric authentication systems. In January 2024, security researchers at RedHunt Labs reported that a leaked GitHub personal access token gave access to Mercedes-Benz's internal GitHub Enterprise Server, exposing source code repositories that contained hardcoded credentials for databases, cloud services, and internal APIs. In each case, the initial exposure point was small — one script, one token, one repository — but the resulting access was enterprise-wide.
How Do You Detect Hardcoded Credentials Before They Ship?
You detect hardcoded credentials before they ship by combining pattern- and entropy-based secret scanning with full git history scanning, run at every stage from the developer's pre-commit hook through the CI/CD pipeline to the container registry. Pattern matching catches known credential formats (cloud provider key prefixes, JWT structures, private key headers), while entropy analysis flags high-randomness strings that look like secrets even when they don't match a known pattern — catching custom API keys or internally generated tokens. Because a secret removed from the current file is still present in earlier commits, detection has to scan the full commit history, not just the working tree, or teams get a false sense of security from a clean HEAD. Detection also needs to extend past application source code into Dockerfiles and built image layers, Terraform and CloudFormation templates, Kubernetes manifests, and CI/CD configuration files like .gitlab-ci.yml or GitHub Actions workflows — all common places a credential ends up hardcoded outside the main codebase. The highest-signal programs also correlate a found secret with whether it's still live (by checking rotation status or testing scope) and whether the code path that uses it is actually reachable, since a hardcoded credential in dead code is a lower-priority fix than one wired into a production authentication flow.
How Do You Remediate Exposed Hardcoded Credentials?
You remediate an exposed hardcoded credential by rotating it immediately, before doing anything else — assume it's compromised the moment it's found in a public or shared location, regardless of whether you have evidence of misuse. Rotation comes first because removing the line from code or even scrubbing it from git history does not undo the exposure window; anyone who already scraped, cloned, or cached the repository still has the old value, and only invalidating the credential at its source (IAM console, database, third-party API dashboard) closes that door. After rotation, remove the hardcoded value from the codebase and replace it with a runtime call to a secrets manager or vault, scoped with the narrowest permissions the application actually needs. For credentials with a long exposure history, purge them from git history using tools like git filter-repo or BFG Repo-Cleaner, and check whether the secret was cached in CI build logs, container registry layers, or third-party mirrors that also need cleanup. Finally, add a scanning gate to the pipeline so the same class of secret can't be reintroduced — remediation without prevention just resets the clock until the next accidental commit.
How Safeguard Helps
Safeguard's platform is built to catch hardcoded credentials before they reach production and to prioritize the ones that actually matter once they're found. Its scanning engine covers source repositories, container image layers, IaC templates, and full git history, then applies reachability analysis to determine whether the code path holding a hardcoded credential is actually exercised at runtime — so teams aren't burning remediation cycles on secrets sitting in dead or test-only code. Griffin AI, Safeguard's reasoning engine, triages each finding with context on exposure scope and exploitability, and can generate an auto-fix pull request that swaps the hardcoded value for a secrets-manager call and opens the rotation workflow in one step. Safeguard also generates and ingests SBOMs across the software supply chain, so a hardcoded credential tied to a specific dependency or base image can be traced across every downstream artifact that inherited it, closing the exposure everywhere it landed rather than in just the one repository where it was found.