Who is accountable when a compromised build identity poisons downstream software?

Accountability usually sits with both platform owners and application owners because the failure spans identity governance, pipeline hardening, and release approval. The right control lens is to treat build identities as governed NHIs with explicit ownership, revocation paths, and audit coverage. If no owner can rotate or retire them, the risk is already unmanaged.

Why This Matters for Security Teams

A compromised build identity is not just another leaked secret. It can sign artifacts, pull dependencies, inject code, and propagate trust into every downstream environment that accepts the pipeline’s output. That makes accountability a governance problem as much as a technical one: platform teams usually own the identity issuance, while application teams own the software release impact. When those boundaries are unclear, no one can revoke, rotate, or investigate with enough authority.

NHI Management Group has found that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which helps explain why build identity compromise is often missed until a downstream package, container, or deployment is already trusted. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for traceability, access restriction, and auditability, but those controls only work when identity ownership is explicit. In practice, many security teams encounter this only after a poisoned build has already been promoted through an otherwise “successful” release.

How It Works in Practice

Build identities should be treated as governed NHIs with a named owner, documented purpose, bounded permissions, and a revocation path that can be executed without waiting for a crisis. The practical question is not simply who created the identity, but who can disable it, inspect its usage, and approve its scope when the pipeline changes. That is where platform engineering, security, and application ownership must be connected.

Good practice is to separate control planes from release decisions. The platform team typically maintains the identity lifecycle, secrets handling, and pipeline hardening. The application owner remains accountable for what the pipeline is allowed to publish and where that software is trusted. If the build identity can access signing keys, artifact registries, or deployment targets, then those privileges need explicit review and periodic revalidation. The risk is amplified when secrets are stored in code or CI/CD tooling, a pattern highlighted in Ultimate Guide to NHIs — Why NHI Security Matters Now.

Practitioners should also map the identity to the software supply chain controls that matter most:

• Use short-lived credentials and rotate them on pipeline changes, not on annual calendars.
• Bind the identity to a specific workload, runner, or signing function instead of broad shared access.
• Log every artifact signing, dependency fetch, and release approval to a tamper-resistant audit trail.
• Revoke the identity immediately when a runner image, token, or secret store is suspected to be exposed.

Recent breach patterns show why this matters, including the 52 NHI Breaches Analysis and the Cisco DevHub NHI breach, both of which illustrate how trust in automation can spread quickly once a machine identity is abused. These controls tend to break down when build systems are shared across teams and no single group has authority to revoke credentials or halt release propagation.

Common Variations and Edge Cases

Tighter build-identity controls often increase operational overhead, requiring organisations to balance release speed against traceability and blast-radius reduction. That tradeoff becomes more visible in monorepos, ephemeral runners, and multi-tenant CI/CD platforms where one identity may serve many products.

There is no universal standard for this yet, but current guidance suggests using the narrowest possible trust boundary and treating signing, fetching, and publishing as separate privileges. In regulated environments, security teams may require dual approval for identity changes, while high-velocity engineering teams may prefer policy-as-code and automated expiry to avoid manual bottlenecks. The important part is that ownership does not stop at the platform layer; application owners still share accountability for the software that is distributed under that identity.

Where teams get caught is in edge cases such as third-party build services, outsourced release pipelines, or emergency hotfix identities that were meant to be temporary but became permanent. The Top 10 NHI Issues research shows how quickly overprivilege and lifecycle drift accumulate once identities are not actively governed. In practice, accountability becomes contested only after an incident reveals that no one could actually retire the compromised identity in time.

Related resources from NHI Mgmt Group

• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
• What is the difference between prompt injection risk and identity abuse in agents?
• What actions should I take if my OAuth tokens are compromised?
• Why do non-human identities increase identity blast radius?