How should teams govern build-system identities in software pipelines?

Why Build-System Identities Need Their Own Governance Model

Build services, signing jobs, package registries, and release automation are not just tools in the pipeline. They are NHIs that can fetch dependencies, write artifacts, publish releases, and sometimes sign what downstream systems trust. That makes them part of the supply chain’s security boundary, not an implementation detail. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is especially dangerous when a pipeline identity can reach production-adjacent systems.

Teams often misgovern these identities by treating them like shared developer convenience accounts, which blurs ownership and makes revocation slow. The result is long-lived access that survives team changes, repository churn, and vendor integrations. The risk is not abstract: secret sprawl and pipeline abuse have repeatedly turned CI/CD into an attacker’s entry point, as shown in the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study.

Practitioners should treat every build-system identity as a separate asset with an owner, a purpose, and a decommission path. In practice, many security teams discover pipeline overreach only after a compromised job token has already been used to move laterally, publish tampered artifacts, or harvest more secrets.

How Build-Identity Controls Work in Practice

Effective governance starts by inventorying every non-human identity used by the software delivery system: runner accounts, bot users, registry credentials, signing keys, deploy tokens, and API keys embedded in orchestration. Each one should have a narrowly defined scope, short lifetime where possible, and a documented revocation path. For artifact integrity, separate build, sign, and release duties so one credential cannot both produce and bless a release.

Current guidance from NIST’s NIST Cybersecurity Framework 2.0 aligns well with this approach because it emphasises governance, asset management, and protective controls rather than assuming a trusted pipeline by default. For identity lifecycle specifics, NHIMG’s Ultimate Guide to NHIs is useful for mapping ownership, rotation, and offboarding to operational controls.

• Assign one accountable owner per build identity, not “the DevOps team” in general.
• Use least privilege for repository read, package publish, signing, and deployment separately.
• Prefer short-lived tokens and workload-bound credentials over long-lived static secrets.
• Rotate or revoke on pipeline change, incident, or personnel change, not just on a calendar.
• Log issuance, use, and failure events so anomalous release activity can be detected quickly.

Build identities also need separation from everyday developer credentials. Shared logins, personal access tokens, and reused SSH keys collapse accountability and make offboarding unreliable. These controls tend to break down in monorepos with many automated release paths because ownership, privilege boundaries, and token sprawl become hard to trace consistently.

Common Variations and Edge Cases

Tighter control over build identities often increases pipeline friction, so organisations have to balance release speed against blast-radius reduction. That tradeoff is real, especially where frequent releases, ephemeral runners, or external contractors make rigid approval chains impractical. Best practice is evolving here, and there is no universal standard for exactly how much privilege a pipeline token should carry.

Some environments rely on federated workload identity, where the runner exchanges a cryptographic workload assertion for a short-lived credential at runtime. That pattern is generally stronger than embedding secrets in CI variables, but it still needs guardrails around issuer trust, audience restrictions, and token lifetime. Supply-chain attacks against developer tooling, including the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign, show why repository trust alone is not enough.

Another edge case is vendor-managed release automation, where the organisation may not control the full identity lifecycle. In those cases, teams should demand visibility into credential scope, rotation support, and revocation mechanics before trusting the integration. When those details are opaque, the control often fails in multi-tenant SaaS build systems because the organisation cannot prove who can still act as the pipeline.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?