Hardcoded secret, token, or password in source code

A secret-named variable is assigned a literal string value in source code, exposing credentials, API keys, or tokens to anyone with repository access.

hardcoded-secret high confidence silent_failure

Hardcoded secret, token, or password in source code

What this failure means

A secret-named variable is assigned a literal string value in source code, exposing credentials, API keys, or tokens to anyone with repository access.

Diagnosis

A variable whose name suggests it holds a secret (API key, token, password, or credential) is assigned a literal string directly in source code.

Hardcoded secrets are committed to version control, visible in PR diffs, and persist in git history even after removal. This affects the security of all environments where the secret is valid.

Common patterns:

  • const APIKey = "sk_live_..." in Go config or init files
  • API_KEY = "..." in Python settings modules
  • token: "..." in YAML configuration committed to the repo

Fix steps

  1. Remove the literal secret value from source code immediately.
  2. Replace it with an environment variable lookup: os.Getenv("API_KEY") in Go, process.env.API_KEY in Node.js, ENV["API_KEY"] in Ruby, etc.
  3. Store the actual secret in CI secrets, a secrets manager (Vault, AWS SSM, GCP Secret Manager), or an .env file that is in .gitignore.
  4. If the secret has already been committed, rotate it — git history is permanent and the exposed value should be treated as compromised.
  5. Add a git-secrets or trufflehog pre-commit hook to catch future leaks.

Validation

  • Run faultline inspect . from the repository root and confirm this source finding is absent or intentionally mitigated.
  • Confirm the finding is resolved and the secret is loaded from the environment.
  • Run git log -p | grep -i api_key to confirm the literal is not present in committed history.

Why it matters

Hardcoded secrets are one of the most common causes of credential compromise in open-source and private repositories alike. A single exposed key can give an attacker full access to a production system, a cloud account, or a third-party API — often without any log of the intrusion. Even private repositories expose secrets to all collaborators and any tool with read access.

Try it locally

make test
rg -n 'api_key|API_KEY|secret|token|password' --type go --type py --type js
make test

How Faultline detects it

Use faultline explain hardcoded-secret to see the full playbook.

faultline analyze build.log
faultline explain hardcoded-secret

Generated from playbooks/bundled/source/hardcoded-secret.yaml. Do not edit directly.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.