The better choice depends on whether the larger risk is fragmentation or inheritance complexity. Repository-level controls reduce cross-project leakage but create duplication, while hierarchical controls centralise governance but increase the chance of mis-scoped overrides. Mature teams choose the model they can actually operate consistently.
When does repository-level secret governance make more sense?
Repository-level governance works best when the main problem is blast-radius control. It gives each repo a tighter boundary for secret injection, scanning, rotation, and policy exceptions, which helps when teams own their own pipelines and credentials. The trade-off is duplication: without strong standards, the same controls get reimplemented unevenly across projects.
That unevenness is not just an efficiency issue. CI/CD secrets leak most often when guardrails are applied inconsistently across repositories, so a repo-first model is strongest when ownership is clear and the platform team can still enforce baseline controls centrally.
For attack patterns and exposed-secret failure modes, the CI/CD case studies in Shai Hulud npm malware campaign and reviewdog Action compromise 2025 show how quickly one repository or action compromise can spread into wider secret exposure.
When is hierarchical secret governance the stronger model?
Hierarchical governance is better when the hard part is consistency across many repos, teams, or environments. A parent policy can standardise where secrets come from, how rotation is enforced, and which repositories inherit default controls, which reduces drift and audit friction. The downside is that broad inheritance can hide accidental overrides and create false confidence if exceptions are not visible.
This model is usually the better fit for large platforms, monorepos, or organisations with a shared pipeline estate. It works only when the hierarchy is designed so that inheritance is predictable and exceptions are reviewable, otherwise the “central control” becomes just another way to spread the same misconfiguration everywhere.
For a broader governance view on secret lifecycle and operational patterns, Secrets Management Guide and the secret-sprawl analysis in Guide to the Secret Sprawl Challenge are useful complements to a hierarchy-first model.
How should teams decide between the two in CI/CD?
The practical decision is not “centralise or decentralise” in the abstract. It is whether your organisation fails more often through uncontrolled duplication or through inherited policy mistakes. If teams regularly need bespoke controls, repository-level governance usually keeps scope clearer. If the same secret policies are being recreated everywhere, hierarchical governance usually wins on maintainability and control consistency.
Use the operating model you can inspect, test, and enforce at scale. If a secret control cannot be proven in the pipeline that actually executes the build, it is only documentation, not governance. Mature teams also separate where policy is defined from where it is overridden, so they can tell the difference between an intentional exception and an accidental drift.
For supply-chain hardening in CI/CD, SLSA is a useful reference point for build integrity, while the OWASP Non-Human Identity Top 10 helps frame secret exposure, overprivilege, and rotation as governance problems rather than just leakage events.
Risk and Threat Considerations
Both models can fail in different ways. Repository-level governance can fragment until teams quietly diverge on rotation, storage, and exception handling. Hierarchical governance can fail when inherited settings are assumed to apply everywhere, but a lower-level override silently reintroduces exposure.
Failure mechanism: Attackers and insiders often exploit the weakest governance seam, which is usually the repo, branch, or pipeline where a secret is least visible or least frequently rotated. In a hierarchical model, mis-scoped inheritance and override rules can let one compromised project reach far more secret material than intended.
Impact: The result is usually secret sprawl, broader-than-expected blast radius, and a harder recovery path after compromise. In CI/CD, that can turn a single leaked token into pipeline tampering, artifact poisoning, or wider environment access.
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 SLSA, 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 | CI/CD secret governance directly addresses leaked pipeline secrets. |
| NHI-05 — Overprivileged NHI | Repo or hierarchy choices change how much privilege CI/CD secrets can accumulate. | |
| Recommendation — Scan pipelines for exposed secrets and rotate any credentials that can be recovered from builds or logs. Scope CI/CD credentials to the minimum permissions required for each repository or pipeline. | ||
| SLSA | Supply-chain Levels for Software Artifacts | CI/CD secret governance supports build integrity and supply-chain trust. |
| Recommendation — Harden build provenance and restrict secret access in the delivery pipeline. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secret governance is an access-lifecycle problem in build automation. |
| Recommendation — Standardise account and credential lifecycle controls for CI/CD automation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CI/CD secret rotation and lifecycle are authenticator management concerns. |
| Recommendation — Rotate, store, and revoke CI/CD secrets under formal authenticator lifecycle controls. | ||
Practitioner Guidance
Decision rule: If your organisation has many teams with genuinely different build trust boundaries, start with repo-level controls and enforce a shared minimum baseline. If the same secrets policy is being copied across many repos, move governance up the hierarchy so rotation, scoping, and exception handling are standardised once.
What to verify: Check whether every inherited policy has an observable enforcement point in the pipeline, and whether overrides are logged well enough to distinguish approved exceptions from silent drift. The model is only as strong as your ability to answer “where did this secret rule come from?” during an incident.
Practitioner takeaway: Choose the governance model that minimises untracked exceptions, because in CI/CD the real risk is not the presence of secrets, but the organisation losing control of where they are allowed to exist and how long they remain valid.
Related resources from NHI Mgmt Group
- Should organisations use the same governance model for CI/CD identities as for service accounts?
- Should organisations use agentic AI in CI/CD before strengthening governance?
- How should security teams use IAST and RASP in NHI governance?
- Should organisations prioritise external exposure or internal credential governance first?