Secrets in code are credentials or sensitive authentication material embedded in source files, configuration, scripts, documentation, or build assets. They create exposure because anyone who can read the artifact may be able to impersonate a user, service, or workload. Detection must account for code context, history, and deployment paths.
Expanded Definition
Secrets in code refers to credentials or sensitive authentication material that is embedded where it can be read by anyone with access to the artifact, including source files, scripts, build manifests, container layers, and generated documentation. In NHI operations, the concern is not only the secret value itself but the full path by which it can be copied, committed, cached, indexed, or deployed. That is why this term sits alongside broader guidance in the OWASP Non-Human Identity Top 10 and why detection must include repository history, CI/CD output, and runtime artefacts.
Definitions vary across vendors when teams blur “in code” with “in config,” but the practical boundary is simple: if a secret is committed, baked into an artifact, or shipped through a pipeline, it becomes harder to revoke and easier to reuse. NHI Management Group treats this as an exposure class, not just a coding mistake, because the secret may already be mirrored across forks, caches, logs, and containers. The most common misapplication is treating a removed line as fixed when the secret still exists in commit history, build caches, or downstream deployment copies.
Examples and Use Cases
Implementing controls against secrets in code rigorously often introduces developer friction and pipeline overhead, requiring organisations to weigh faster delivery against stronger prevention and verification.
- A developer commits an API key into a private repository, and later the key is surfaced through a fork or dependency scan. The Guide to the Secret Sprawl Challenge shows why discovery must extend beyond the original repo.
- A CI job injects a token into a container image layer, then publishes the image to a registry. This pattern is consistent with findings in the State of Secrets Sprawl 2025, where container exposure remains a high-volume leakage path.
- A build script stores a service credential in environment variables and echoes it during test runs, creating log exposure. The Shai Hulud npm malware campaign is a reminder that pipeline-adjacent systems are attractive targets.
- A deployment template contains a long-lived database password that is reused across environments instead of being generated dynamically. The Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why static values expand blast radius.
Why It Matters in NHI Security
Secrets in code weakens NHI security because a leaked credential can impersonate a workload, service account, or agent with no further compromise required. Once that secret is embedded in code, the exposure often becomes persistent across branches, artifacts, and deployment targets, which complicates revocation and incident response. NHI Management Group’s research shows the scale of this problem: The State of Secrets Sprawl 2025 reports that 15% of commit authors have leaked at least one secret in their contribution history, a sign that the issue is systemic rather than exceptional.
This matters operationally because NHI compromise is frequently invisible until a downstream event forces attention. If a secret is reused in CI/CD, embedded in an image, or copied into a ticketing tool, the control failure can spread beyond engineering into incident response, audit, and identity governance. The right response is to combine repository scanning, history rewriting where appropriate, rotation, and short-lived credential design, while aligning with Reviewdog GitHub Action supply chain attack lessons and the OWASP NHI guidance. Organisations typically encounter the real impact only after a token is abused in production, at which point secrets in code becomes 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret handling that enables NHI credential exposure in code and artifacts. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access control fail when secrets are hardcoded and broadly exposed. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero trust assumes credentials are compartmentalized and not permanently exposed in code. |
| NIST SP 800-63 | AAL2 | Authenticator strength is undermined when shared secrets are copied into source or pipelines. |
| CSA MAESTRO | GOV-02 | Agentic workflows must govern secret usage across orchestration, tools, and execution paths. |
Replace static secrets with short-lived, verifiable credentials and reauthenticate each access path.
