What breaks when repository secrets are never recertified?

Why This Matters for Security Teams

Repository secrets that are never recertified create a control failure, not just a hygiene issue. A workflow credential can stay valid long after the repository, branch, or automation that justified it has changed, which means the organisation loses the ability to answer a basic question: who should still be able to use this secret, and why? That is the same drift pattern seen in incidents such as the CI/CD pipeline exploitation case study, where unattended automation becomes a durable attack path.

Current guidance suggests treating secrets as living access grants rather than static configuration. The OWASP Non-Human Identity Top 10 frames stale machine access as a core risk because unused or overbroad credentials are often easier to abuse than human accounts. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secret ownership decays once projects move on. The practical consequence is that security teams may still see “healthy” pipelines while old credentials continue to authorize actions no one is actively watching. In practice, many security teams encounter secret abuse only after a pipeline has already been reused outside its original purpose, rather than through intentional recertification.

How It Works in Practice

Recertification should answer three questions on a schedule: does the secret still exist, does the workload still need it, and is the scope still minimal for the current use case? For repository secrets, that usually means pairing inventory with ownership and expiry. If a secret is tied to a build, deployment, or integration workflow, the owner should confirm the workflow still runs, the target system still exists, and the credential still needs the same permissions.

Practitioners commonly implement this with short-lived secrets where possible, but for repository-bound credentials that cannot yet be ephemeral, the recertification workflow becomes the compensating control. A strong program combines:

• asset ownership linked to the repository or pipeline, not just the secret store
• periodic attestations by the business and technical owner
• automatic revocation when no owner responds or the workflow is retired
• scope reduction before renewal, not after a leak

That approach aligns with the secret-sprawl lessons documented by NHIMG in the 52 NHI Breaches Analysis and the remediation pressure described in The State of Secrets in AppSec, where leaked-secret remediation still averages 27 days despite high confidence in controls. Where possible, use event-driven recertification too: repository deletion, workflow changes, privilege elevation, or inactivity should trigger a review instead of waiting for the next quarterly cycle. These controls tend to break down in large mono-repos and shared CI/CD runners because one secret can support many loosely owned workflows, making true business ownership hard to prove.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, so organisations must balance assurance against workflow friction. That tradeoff is most visible in platforms where many teams reuse the same repository secret for convenience, especially when build systems are inherited, forked, or copied across environments.

There is no universal standard for exact recertification frequency yet. Current guidance suggests aligning review cadence to secret criticality, blast radius, and change rate: production deployment secrets and secrets with write access deserve more frequent review than low-risk read-only integrations. A secret used by an abandoned repository should be revoked immediately, while a secret tied to an active pipeline may require owner attestation and narrower scope before renewal.

Edge cases also matter. Secrets embedded in templates, reusable workflows, or forked repositories can survive long after the original owner has left. Shared service accounts can hide the real consumer, which means recertification must follow the workflow graph, not just the credential name. The Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack both illustrate how inherited automation can outlive its trust boundary. Where secrets are deeply embedded in developer tooling, recertification breaks down because ownership is diffuse and revocation can disrupt multiple pipelines at once.

Related resources from NHI Mgmt Group

• When does secrets rotation actually reduce NHI risk?
• What breaks when secrets never leave the kernel boundary?
• What breaks when an IAM tool cannot support offboarding well?
• What breaks when employee offboarding is treated as an HR task instead of an identity control?