A credential stored for use by code or automation inside a repository context. Repository secrets are identity assets, not configuration text. They should be owned, scoped, rotated, and removed with the same discipline applied to service accounts and other privileged non-human identities.
Expanded Definition
A repository secret is a credential made available to code, build steps, or automation inside a repository context. In NHI governance, it is treated as a privileged identity asset, not as harmless configuration text, because it can authenticate to cloud services, deployment systems, APIs, or signing workflows.
Usage varies across platforms and teams, and definitions vary across vendors. Some tools bind secrets to a repository, others to an environment, branch, or workflow, but the operational concern is the same: the secret grants machine access and must be governed like any other non-human identity. That means clear ownership, scoped permissions, rotation, auditability, and removal when the workflow ends. This aligns closely with the guidance in the OWASP Non-Human Identity Top 10, which treats exposed machine credentials as a core attack surface.
Repository secrets are often confused with environment variables or safe defaults, but the security posture changes the moment a value can unlock an external system. The most common misapplication is storing long-lived credentials in repository settings without lifecycle ownership, which occurs when teams treat deployment convenience as a substitute for identity governance.
Examples and Use Cases
Implementing repository secrets rigorously often introduces release friction, because tighter scoping and rotation can require workflow refactoring, secret distribution changes, and more frequent access review.
- CI jobs use a short-lived cloud token to deploy artifacts, replacing a static API key that previously lived in repository settings. This reduces blast radius if the pipeline is compromised, a pattern reflected in NHIMG coverage of the CI/CD pipeline exploitation case study.
- A build workflow pulls signing credentials only at runtime, rather than persisting them in plaintext config. That supports better separation between source code and identity material, as discussed in the Ultimate Guide to NHIs - Static vs Dynamic Secrets.
- A repository used for third-party integrations stores a narrowly scoped token with read-only access and explicit expiration, limiting damage if the token is leaked through logs or pull requests.
- A security team hunts for hardcoded credentials after a dependency attack exposes secrets in a public workflow, similar to the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign.
- Repository owners remove obsolete secrets during offboarding so old deployment paths do not remain valid after a project is retired.
Why It Matters in NHI Security
Repository secrets become high-value targets because they are often reachable from developer tooling, automation logs, and compromised pipelines. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which explains why repository-based exposure remains such a common entry point.
When a repository secret is over-permissioned, stale, or widely shared, it can bypass Zero Trust assumptions and let attackers move from source control into cloud infrastructure, production systems, or third-party services. The risk is not theoretical: leaked repository secrets have featured in events such as the Emerald Whale breach and the GitLocker GitHub extortion campaign. In practice, repository secret governance depends on the same principles described by OWASP and repository-adjacent identity controls in NHI programs: least privilege, rotation, scoped exposure, and rapid revocation after compromise.
Organisations typically encounter the consequences only after secrets are exfiltrated from a repo or CI run, at which point repository 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 | Repository secrets are machine credentials and fall under improper secret management risk. |
| NIST CSF 2.0 | PR.AA-01 | Repository secrets support system authentication and require controlled access management. |
| NIST Zero Trust (SP 800-207) | PL-2 | Zero Trust requires continuous verification before repository-held credentials can be used. |
Inventory, scope, rotate, and revoke repository secrets as governed NHI credentials.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
