Hardcoded Credentials
debt(d5/e7/b3/t7)
Closest to 'specialist tool catches it' (d5). The term's detection_hints.tools list — trufflehog, gitleaks, github-secret-scanning, semgrep — are all specialist SAST/secret-scanning tools, not default linters or compiler errors. Automated detection is possible but requires deliberately running these tools against the full git history, not something that fires by default in most dev workflows.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says to scan the entire git history and rotate every found credential immediately. Rotation is not a code change — it involves updating secrets in every environment, revoking and reissuing credentials with external providers, updating CI/CD pipelines, and purging or rewriting git history. This is inherently cross-cutting and touches infrastructure, deployment config, and source code simultaneously.
Closest to 'localised tax' (b3). The applies_to contexts are web and cli, which is broad, but hardcoded credentials are typically concentrated in specific config files or constants. Once removed and replaced with environment variable injection, the burden doesn't spread widely across the codebase. However, the persistent risk of git history exposure means a localised-but-sticky tax remains.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states directly: 'Credentials in a private repository are safe.' Developers routinely believe access controls on the repo are sufficient protection, not realising that git history permanently preserves secrets even after removal, that private repos can be breached or accidentally made public, and that CI logs often echo secrets. This contradicts the intuitive mental model of 'private = safe.'
Also Known As
TL;DR
Explanation
Hardcoded credentials are a persistent risk because developers commit secrets into version control — even if removed later, they remain in git history. Once a repository is leaked or made public, automated scanners harvest these credentials within minutes. Use environment variables or a secrets manager (HashiCorp Vault, AWS Secrets Manager) to inject credentials at runtime. Implement pre-commit hooks with tools like truffleHog or git-secrets to prevent accidental commits.
Common Misconception
Why It Matters
Common Mistakes
- Committing .env files or config files with real credentials to version control.
- Defining credentials as PHP constants in source files that are tracked in git.
- Using the same credentials in development and production, meaning a dev repo leak compromises production.
- Not scanning CI pipelines and logs, which often echo environment variables containing secrets.
Code Examples
$db = new PDO('mysql:host=localhost', 'root', 'SuperSecret123!');$db = new PDO('mysql:host=' . $_ENV['DB_HOST'], $_ENV['DB_USER'], $_ENV['DB_PASS']);