How should teams secure CI/CD pipelines against identity-based attacks?

Why This Matters for Security Teams

CI/CD is not just a delivery system. It is an identity transit layer where developer accounts, build runners, package tokens, signing keys, and deployment credentials all intersect. That makes it a high-value target for identity-based attacks that do not need malware to succeed. Attackers often prefer stolen secrets, poisoned workflows, and over-privileged service accounts because they can move from source code to production with minimal friction. NHIs outnumber human identities by 25x to 50x in modern enterprises, and the 52 NHI Breaches Analysis shows how often those identities become the real entry point.

The operational risk is amplified by speed. In incident research on exposed cloud credentials, attackers have been observed attempting access within minutes, which means pipeline compromise can become production compromise before a standard review cycle finishes. Guidance from CISA cyber threat advisories reinforces that identity and access abuse is now a routine part of intrusion tradecraft, not an edge case. In practice, many security teams encounter pipeline abuse only after secrets have already been reused outside the intended build path.

How It Works in Practice

The most effective model is to treat the pipeline as a chain of governed NHIs, not a single trusted system. Each stage should authenticate with its own workload identity, receive only the permissions it needs for that stage, and lose access as soon as the task ends. That means replacing long-lived static secrets with short-lived credentials, enforcing commit provenance checks before build execution, and binding release authorization to verified inputs rather than to a broad pipeline token.

Current guidance suggests using Ultimate Guide to NHIs as the governance baseline, then mapping the implementation to workload identity and policy controls. For example, a build runner should be able to fetch only the artifacts, registries, and signing services required for that job, while release jobs should require separate approval and separate identity context. OIDC federation, SPIFFE-style workload identity, and policy-as-code are all common patterns here, but there is no universal standard for every platform yet. The key is that authentication, authorisation, and secret issuance all happen per task, not per environment.

• Use JIT credentials for each job or deployment step, then revoke them automatically at completion.
• Store signing keys and deployment tokens in managed secret systems, not in repository variables or runner images.
• Verify commit provenance and dependency integrity before the pipeline can promote an artifact.
• Separate build, test, package, and deploy identities so one compromise does not span the full lifecycle.

For implementation patterns, the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack show how quickly one weak integration can expose secrets across the delivery chain. In a recent AI-focused threat report, Anthropic — first AI-orchestrated cyber espionage campaign report also illustrates how tooling and credentials can be chained once initial access is gained. These controls tend to break down in self-hosted runner fleets with shared images and persistent filesystem state because stolen tokens can be replayed before revocation catches up.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery overhead, requiring organisations to balance release speed against the cost of stronger identity checks. That tradeoff is real, especially in polyglot estates where legacy CI systems, vendor-managed runners, and ad hoc automation all coexist. Best practice is evolving, but the direction is clear: every exception to short-lived credentials or scoped authorisation becomes a reusable attack path.

Edge cases usually appear where teams treat the pipeline as trusted infrastructure rather than as a hostile execution environment. Monorepos with hundreds of deployable services, ephemeral preview environments, and cross-account cloud deployments all add identity sprawl. In those environments, the safest pattern is to make the pipeline prove intent at runtime and to fail closed when provenance, device posture, or secret freshness cannot be verified. The same logic applies to package publishing and signing: if one runner can mint broadly valid credentials, the whole release chain inherits that risk. The Guide to the Secret Sprawl Challenge is useful here because it shows how secrets escape into places teams forget to inspect, and the Shai Hulud npm malware campaign is a reminder that package ecosystems are also part of the pipeline trust boundary. When release automation spans multiple clouds or third-party build services, identity controls often fragment before policy can enforce a consistent trust decision.

Related resources from NHI Mgmt Group

• How should teams secure non-human identities across cloud and SaaS?
• How should teams combine SAST and DAST in a secure development programme?
• How should security teams govern credentials used by CI/CD pipelines?
• Why are identity-based attacks growing faster than traditional network attacks?