How can organisations reduce credential theft from build and dependency workflows?

Why This Matters for Security Teams

Build and dependency workflows are attractive because they sit close to source code, signing keys, package registries, and deployment paths. Once an attacker gets a foothold in a pipeline, credential theft can turn a routine build compromise into code signing abuse, package poisoning, or lateral movement into production systems. The risk is not limited to source repositories. It also includes ephemeral runners, dependency caches, secrets managers, and automation accounts that were never intended to be interactive.

Organisations often underestimate how much trust these workflows accumulate over time. A package install step may be able to reach internal registries, a test job may inherit cloud credentials, and a release task may have permission to publish artefacts or assume a deployment role. Current guidance from the OWASP Non-Human Identity Top 10 aligns with the idea that machine identities need explicit governance, not informal convenience. In practice, many security teams encounter credential theft only after a malicious dependency or compromised maintainer account has already abused standing pipeline access.

How It Works in Practice

Reducing credential theft starts with treating build and dependency systems as high-value identity environments. The goal is to minimise what each workflow can see, sign, publish, or deploy, and to shorten the time any credential remains valid. That means separating developer tools from release tooling, isolating trusted and untrusted jobs, and ensuring that dependency resolution does not run with the same privileges as release signing or production deployment.

A practical control set usually includes:

• Use short-lived credentials for builds rather than static secrets in environment variables or repository settings.
• Scope tokens to a single task, repository, environment, or artefact path wherever possible.
• Separate dependency download, test, and release stages so untrusted code cannot reach signing or publishing steps.
• Store signing keys and deployment approvals outside general-purpose runner access.
• Rotate and revoke pipeline identities as rigorously as human credentials, with inventory and ownership assigned.

This is also where identity governance matters. Build runners, package bots, and deployment agents are Non-Human Identities, so they need lifecycle controls, authentication assurance, and periodic review. The principles in NIST SP 800-63 Digital Identity Guidelines are useful when deciding how strongly a machine identity should be bound to a workload and how confidently its actions should be attributed. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a good baseline for access enforcement, auditability, and key management.

Dependency workflows also need defensive engineering against secret exfiltration. That means preventing scripts from echoing tokens, blocking unnecessary environment inheritance, disabling broad file-system access in runners, and treating third-party packages as potentially hostile until verified. These controls tend to break down when shared runners, long-lived service accounts, and monolithic release jobs are used because a single compromised step can then expose multiple credentials at once.

Common Variations and Edge Cases

Tighter pipeline isolation often increases build complexity and operational overhead, requiring organisations to balance developer speed against containment. Some environments also have legacy tooling that cannot easily support short-lived credentials or fine-grained scoping, so best practice is evolving rather than universal.

High-automation environments introduce a few recurring edge cases. Monorepos may need different trust levels for internal libraries and external dependencies. Multi-stage CI/CD systems often require one identity for dependency fetching, another for artifact signing, and a separate deployment identity, but that separation is only effective if each role is truly independent. Where organisations use package mirrors, artifact caches, or federated cloud roles, stolen tokens may not look like a classic login event, so detection logic must focus on unusual issuance, reuse, or scope expansion rather than password-based alerts.

There is also an important distinction between preventing theft and limiting impact. Some teams assume that secret scanning alone is enough, but current guidance suggests that credential minimisation, workload isolation, and approval boundaries matter more than detection after the fact. For additional context on machine identity governance, the OWASP Non-Human Identity Top 10 remains a strong reference point for reducing standing privilege across automation. Where release workflows are tightly coupled to production access, the most common failure mode is not token theft itself but over-scoped automation that turns a single compromised build into a trusted deployment path.

Related resources from NHI Mgmt Group

• How can organisations reduce the damage from credential theft?
• How can organisations reduce risk from voice-driven credential theft?
• How can organisations reduce over-privileged OAuth access without breaking business workflows?
• Should organisations allow pull_request_target for automated dependency workflows?