SECRET-CLIENT-EMBEDDED

Hardcoded secrets are API keys, database passwords, OAuth tokens, and private keys written directly as string literals into application source and committed to version control. Because they are plaintext constants, automated scanners (Trufflehog, Gitleaks, GitHub secret scanning) trivially recover them by pattern-matching commit contents against known token formats and high-entropy strings, so a single push to a public host exposes the credential to anyone watching the commit stream within seconds. GitGuardian's State of Secrets Sprawl reported 12.8 million new secrets leaked on public GitHub in 2023, rising about 25% to 23.8 million in 2024, with generic secrets making up 58% of detections. The problem is not limited to public code: GitGuardian found 35% of scanned private repositories also contained plaintext secrets, and AWS IAM keys appeared several times more often in private than public repos. Once committed, a leaked credential can grant direct access to production databases, cloud accounts, and third-party services.

On October 10, 2022 Toyota disclosed that data for up to 296,019 customers of its T-Connect vehicle-connectivity app had been exposed for nearly five years. A development subcontractor published part of the T-Connect source code to a public GitHub repository in December 2017, and that code contained a hardcoded access key for a data server holding customer records. Because the repository was public, anyone could read the embedded key and use it to authenticate to the server storing customer email addresses and management (customer control) numbers. The exposure ran from December 2017 until the public repository was noticed and access restricted on September 15, 2022. Toyota changed the affected database keys on September 17, 2022 and warned customers of phishing risk, while stating it could not completely rule out third-party access; names, credit card data, and phone numbers were not stored in the exposed dataset. This is distinct from Toyota's separate 2023 cloud-configuration exposure.

On October 17, 2019 security researcher Vinoth Kumar reported via HackerOne that a Starbucks developer had committed a JumpCloud API key to a public GitHub repository. JumpCloud is a directory-as-a-service and identity-management platform, and the exposed key granted access to internal systems, allowing an attacker to list systems and users, run commands on internal hosts, take control of the associated AWS account, and add or remove user access. Because the key sat in a public repository, anyone scanning GitHub could retrieve it and reach Starbucks' internal directory and infrastructure. Starbucks rated the issue critical as significant information disclosure, removed the repository and revoked the key by October 21, 2019, and paid Kumar a $4,000 bounty, the maximum for critical findings.

In October 2016 attackers breached Uber and stole data on roughly 57 million riders and drivers, including about 600,000 driver's license numbers, an incident Uber concealed until publicly disclosing it on November 21, 2017. The attackers scanned GitHub and found AWS access credentials hardcoded in a private Uber GitHub repository, where engineers used personal accounts without enforced multi-factor authentication and reused passwords exposed in prior breaches. Using the plaintext AWS access key, the intruders authenticated to an Amazon S3 bucket Uber used for backups and downloaded the rider and driver datastore over roughly a month. Rather than report it, Uber paid the attackers $100,000 in Bitcoin disguised as a bug-bounty reward to stay silent. The concealment led to an FTC settlement requiring a 20-year privacy program, and in October 2022 former CSO Joseph Sullivan was convicted of obstruction and misprision of a felony.

Git is a content-addressable store: every version of every file is saved as an immutable blob object referenced by commits, so deleting a secret in a later commit or removing the file entirely leaves the original blob intact and fully reachable in history. Anyone who clones or forks the repository receives the complete object database and can recover the credential by walking old commits (git log -p, git rev-list, or extracting the blob by its hash), which is why a secret 'removed' in HEAD is still public. Truly purging it requires rewriting history with git filter-repo or the BFG Repo-Cleaner to drop the blob and force-pushing, but GitHub warns that existing clones, forks, pull-request references, and cached commit views may still expose it. GitHub's own guidance is explicit: once a secret has been pushed, consider it compromised and rotate it, because rewriting history cannot guarantee no one already copied it. Rotation is the only reliable remediation; history rewriting is cleanup, not a fix.

A container image is a stack of immutable, content-addressed layers where each Dockerfile instruction (RUN, COPY, ADD) commits a filesystem diff, so a secret introduced in one layer persists permanently even if a later layer deletes the file. Deleting with RUN rm only writes a whiteout entry in a higher layer; the original bytes remain in the earlier layer's tarball and are recoverable by extracting the image and reading individual layer archives. Secrets passed via ARG or ENV are worse still, as their values are recorded in image metadata and surface directly through docker history, exposing them to anyone who pulls the image or has registry layer-download permissions. Once such an image is pushed to a public or shared registry, the credential leaks to every consumer. BuildKit's RUN --mount=type=secret solves this by exposing a secret to a single build step without writing it to any layer, leaving no trace in the final image.