A developer secret is a credential used to access code, services, or infrastructure, such as an API key, SSH key, token, or certificate. In practice, it becomes an identity artifact when it can authorize action, not just authenticate a person. Its risk lies in spread, reuse, and weak revocation.
Expanded Definition
A developer secret is any credential that grants a software actor access to code, services, or infrastructure, including API keys, SSH keys, tokens, and certificates. In NHI practice, the important distinction is not whether the secret was created by a developer, but whether it can authorize an action on behalf of a workload, pipeline, or integration. That is why developer secrets sit at the boundary between application security and identity governance.
Definitions vary across vendors on whether a secret is treated as a configuration artifact, an authentication factor, or a full identity artifact. NHI Management Group treats it as an identity-bearing control object whenever it can be used to call an API, sign a request, or unlock privileged access. This aligns with the broader NHI lens used by the OWASP Non-Human Identity Top 10, where secret handling is inseparable from lifecycle, privilege, and revocation.
The most common misapplication is treating developer secrets as harmless code variables, which occurs when teams store them in repositories, CI/CD variables, or shared build artifacts without ownership and rotation controls.
Examples and Use Cases
Implementing developer secret controls rigorously often introduces release friction, requiring organisations to weigh automation speed against revocation, rotation, and auditability.
- An API key embedded in a backend service to call a payment platform must be scoped, monitored, and rotated, because it can become a long-lived workload identity.
- An SSH key used for deployment access can be more sensitive than a password if it grants persistent server access without JIT controls.
- A signing token in a CI pipeline may authorize artifact publishing, so a leaked value can become a supply-chain entry point, as seen in incidents discussed in the CI/CD pipeline exploitation case study.
- A cloud access token in a mobile backend should be treated as a governed identity artifact, not a developer convenience, especially when paired with dynamic secret issuance patterns described in Ultimate Guide to NHIs — Static vs Dynamic Secrets.
- A leaked secret in a public repository can trigger unauthorized access long after the commit is removed, which is why the State of Secrets in AppSec reports that only 44% of developers follow secrets-management best practices.
Why It Matters in NHI Security
Developer secrets matter because they frequently become the easiest path from code exposure to active compromise. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 91.6% of secrets remain valid five days after notification, which means detection alone does not end exposure. That gap turns a single leak into an identity problem, a privilege problem, and an incident-response problem at the same time.
Mismanagement also amplifies shadow access, since a secret may survive developer turnover, pipeline changes, or third-party integrations. When a secret is reused across environments, attackers can pivot from one service to many. The operational lesson is reinforced by breach analysis such as the 52 NHI Breaches Analysis and the Guide to the Secret Sprawl Challenge, both of which show how spread and weak governance multiply impact.
Organisations typically encounter the full consequence only after a leaked key is abused in production, at which point developer secret governance 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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret storage, exposure, and rotation are central concerns in this NHI control area. |
| NIST CSF 2.0 | PR.AA-04 | Credentials and authentication mechanisms must be managed as part of identity assurance. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires continuous verification rather than implicit trust in static secrets. |
Inventory developer secrets, remove exposed values, and enforce rotation and revocation workflows.
