Credentials, tokens, keys, or certificates embedded in code, configuration, comments, or build artefacts. Once exposed, they often remain reusable beyond the original context, creating a lifecycle problem that requires discovery, rotation, and revocation rather than simple code cleanup.
Expanded Definition
Secrets in source code are not only a coding mistake; they are an identity lifecycle failure. In NHI operations, a secret can be a credential, token, API key, or certificate embedded in application source, configuration, comments, notebooks, or build artefacts, then copied into logs, package registries, or CI output. The risk is persistent because the exposed value may remain valid long after the code is fixed, which makes discovery, rotation, and revocation the real remediation steps. This is why the OWASP Non-Human Identity Top 10 treats secret handling as a core NHI control issue rather than a narrow DevSecOps hygiene problem.
Definitions vary across vendors on whether short-lived tokens and ephemeral build credentials count as secrets in the same category as long-lived keys, but the operational answer is simple: if a value authenticates a workload, it must be governed as a secret. The most common misapplication is assuming that deleting the line of code removes the exposure, which occurs when the secret has already propagated into caches, forks, artifacts, or external integrations.
Examples and Use Cases
Implementing secret controls rigorously often introduces friction in developer workflows, requiring organisations to weigh fast delivery against the overhead of rotation, scanning, and access boundaries.
- Hard-coded cloud access keys in a repository are discovered by a scanner, then rotated and revoked after exposure, similar to cases discussed in Gladinet Hard-Coded Keys RCE Exploitation.
- A CI job prints environment variables into build logs, creating a leak path that persists in pipeline history and runner artefacts, a pattern also reflected in the CI/CD pipeline exploitation case study.
- A package maintainer commits a cloud token in a dependency release, and downstream consumers inherit the exposure before the repository owner notices, as seen in the Shai Hulud npm malware campaign.
- Developers paste service credentials into comments for convenience, then later forget to remove them before merge, which is why automated pre-commit and repository scanning are essential in the Guide to the Secret Sprawl Challenge.
- Application teams replace static embedded keys with short-lived workload credentials aligned to the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the identity model described in OWASP Non-Human Identity Top 10.
Why It Matters in NHI Security
Secrets in source code become NHI incidents because they turn software supply chains into credential distribution channels. Once a token or key is exposed, attackers may authenticate as the workload, move laterally through connected services, or silently access data until the secret is found and invalidated. NHIMG research shows that the average time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities in The State of Secrets in AppSec. That gap matters because confidence without detection and rotation only increases dwell time.
This term also connects directly to breach prevention and post-exposure recovery. The Twitch Breach illustrates how code-adjacent credential exposure can escalate into broader compromise, while the 230M AWS environment compromise shows the scale that becomes possible when cloud secrets are mishandled. Organisations typically encounter the operational cost only after a leak is detected by an outsider, at which point secrets in source code become operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret exposure and improper handling are core NHI control concerns. |
| NIST CSF 2.0 | PR.AC-1 | Credential exposure directly undermines identity and access control protections. |
| NIST SP 800-63 | AAL2 | Secret strength and lifecycle influence authentication assurance for workloads. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust assumes credentials can be exposed and must be tightly constrained. |
| NIST AI RMF | AI systems can memorize and reproduce sensitive code patterns, including secrets. |
Prevent models and assistants from ingesting code with secrets and validate output for leakage.
Related resources from NHI Mgmt Group
- Why do secrets in source code create NHI governance problems?
- Should organisations scan Docker images for secrets if they already secure the source code?
- Why do secrets in source code remain a persistent security risk after removal?
- Why do secrets in source code become an IAM problem as well as an AppSec problem?
