Inclusion of sensitive information in source code is the hard-coding of secrets, credentials, tokens, keys, or confidential data into application code or scripts. Attackers can extract these from repositories, build artefacts, or error output. Teams should scan source, remove exposed values, and rotate anything that may already have been disclosed.
What This Means in Code and in the Repository
Hard-coding secrets turns source code into a storage location for credentials, tokens, API keys, certificates, and other sensitive values. That creates a hidden dependency on every place the code is copied, reviewed, built, logged, or shared, because the secret can travel far beyond the original developer’s workstation.
The danger is not limited to the repository itself. Secrets can also surface in build artefacts, stack traces, configuration dumps, test fixtures, commit history, or error output, which means a single mistake can become a long-lived disclosure path.
Why It Becomes a Security Problem
Once a secret is embedded in code, it is easy to duplicate and hard to fully retract. Even after removal from the current branch, it may still exist in forks, mirrors, caches, pull requests, release packages, or developer laptops, so exposure can persist well after the original file is fixed.
This pattern is especially dangerous because the secret itself is often the thing that grants access. A leaked token or key can let an attacker read data, impersonate a service, access a cloud account, or move laterally into adjacent systems without needing to exploit a software vulnerability first.
Public repository exposure is a recurring failure mode, as seen in EmeraldWhale Git config credential theft and New York Times GitHub breach 2024, where exposed tokens and secrets in source material enabled broader compromise.
How Teams Detect and Reduce Exposure
Detection starts with scanning source repositories, commit history, and build outputs for secrets before they are merged or shipped. Mature programmes treat secret discovery as part of code review and CI/CD hygiene, not as a one-time audit.
Removal alone is not enough. Teams also need to invalidate or rotate anything that may already have been exposed, because a copied token remains usable even after the source line is deleted. That is why remediation must pair cleanup with credential lifecycle control.
Exposure often crosses from source into delivery pipelines and shared tooling, so Guide to the Secret Sprawl Challenge is a useful companion for understanding how hard-coded values spread across CI/CD and repository workflows.
Safer Coding and Secret Handling Patterns
The safer pattern is to keep secrets out of code entirely and retrieve them from controlled secret storage at runtime. That reduces accidental disclosure in version control and makes access easier to govern, monitor, and revoke.
Developers should also avoid using real production secrets in samples, tests, documentation, or debug output. When a secret is needed for local development, it should be short-lived, environment-specific, and easy to replace if it is ever copied or revealed.
For teams building or reviewing software, CWE Top 25 Guide provides the broader weakness taxonomy behind this class of coding error, while Guide to the Secret Sprawl Challenge reinforces the operational controls that stop secrets from accumulating in code and pipelines.
Risk and Threat Considerations
Hard-coded secrets are attractive because they collapse discovery and access into a single step: find the repository, copy the value, and use it before defenders notice. That makes this weakness a direct enabler for credential theft, unauthorised access, and post-compromise persistence.
Failure mechanism: The secret is embedded in a place that is widely distributed, cached, logged, or revisited, so disclosure survives ordinary code changes and can be harvested from history, artefacts, or copied repositories.
Impact: Attackers may gain reusable access to applications, cloud services, support systems, or internal data, and defenders may be forced into broad rotation and incident review even when the original code issue looks small.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hard-coded secrets in code are direct secret leakage into repositories and artefacts. |
| NHI-07 — Long-Lived Secrets | Embedded secrets often persist too long and remain usable after disclosure. | |
| Recommendation — Scan code and pipelines for secret leakage, then remove exposed values and rotate them immediately. Replace long-lived embedded secrets with short-lived, revocable credentials. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure coding and secret handling are core application security hygiene for this weakness. |
| Recommendation — Embed secret scanning into secure development and release checks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Leaked secrets require control over issuance, storage, rotation, and revocation. |
| SI-12 — Information Management and Retention | Source and artefact retention increases how long exposed secrets remain accessible. | |
| Recommendation — Manage authenticators so exposed secrets can be rotated and revoked quickly. Limit retention of source and build artefacts that may contain sensitive data. | ||
Practitioner Guidance
Why practitioners should care: This term is not just a coding smell, it is a governance problem for secret ownership and revocation. If a secret appears in source, teams need to assume disclosure until they prove otherwise and treat rotation as part of the fix, not a follow-up task.
Common misunderstanding: Removing the line from the current branch does not necessarily remove the exposure. History, forks, CI logs, cached artefacts, and copied snippets can keep the secret alive long after the file looks clean.
Practitioner takeaway: The safest response is always to search broadly, remove the exposure, and rotate every credential that could plausibly have been seen or reused.
Related resources from NHI Mgmt Group
- Inclusion of Sensitive Information in Test Code
- Should organisations prefer on-premise code models for sensitive source code?
- Why do developer secrets and source code create outsized risk compared with larger but less sensitive data sets?
- What should teams do when sensitive source code or customer data is discovered in an open S3 bucket?