Who is accountable when a poisoned build pipeline or exposed edge device causes compromise?

Accountability usually spans platform engineering, application owners, and security governance because the control failure is shared. For build pipelines, the owner of the automation identity must govern secrets and approvals. For edge devices, the network or infrastructure team must own exposure, patching, and segmentation. NIST CSF and NIST SP 800-53 both support that shared-control model.

Why This Matters for Security Teams

When a poisoned build pipeline or an exposed edge device leads to compromise, the failure is rarely isolated to one team. The real issue is control ownership across the identity that runs the process, the systems that store secrets, and the teams that approve releases or maintain exposed infrastructure. In NHI security, that boundary matters because automation identities and device credentials often outlive the people who created them.

NHI Management Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes pipeline compromise a governance problem as much as a technical one. The same pattern appears in CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge, where the initial weakness is operational, but the blast radius becomes enterprise-wide.

For teams, accountability should map to the control point that failed, not just the system that was finally breached. NIST SP 800-53 Rev. 5 is explicit that access control, configuration management, and system integrity are shared responsibilities across owners and operators. In practice, many security teams encounter blame after exposure has already happened, rather than through intentional ownership mapping.

How It Works in Practice

The most useful way to assign accountability is to follow the chain of control. For a poisoned build pipeline, that usually includes the platform engineering team that owns the CI/CD system, the application owner that approved the release path, and the security function that defines minimum control requirements. For an exposed edge device, responsibility often sits with infrastructure or network operations for patching, segmentation, certificate management, and asset inventory. The direct answer is shared accountability, but the operational question is which team owns each control.

Practically, organisations should separate Ultimate Guide to NHIs — Why NHI Security Matters Now ownership from service ownership. The team running the pipeline must govern the automation identity, including secrets placement, approval gates, and revocation on change. The team managing edge devices must govern exposure, hardening, and secure update channels. Security governance then defines standards, verifies evidence, and escalates exceptions.

• Map each NHI, device credential, and signing key to a named control owner.
• Require short-lived secrets and revocation paths for build and release automation.
• Track external exposure for edge devices, including remote management ports and stale certificates.
• Use change records to identify who approved the system state before compromise.
• Test whether the pipeline or device can be rebuilt, rotated, or isolated without manual guesswork.

For emerging threats, the pattern is similar. The Anthropic report on AI-orchestrated cyber espionage illustrates how automation can compress attacker timeframes and widen impact, which makes ownership clarity even more important. These controls tend to break down when pipelines are shared across multiple product teams and edge devices sit outside normal patch windows because no single team has full operational control.

Common Variations and Edge Cases

Tighter control assignment often increases overhead, requiring organisations to balance accountability precision against delivery speed. That tradeoff is real, especially in environments where build automation is shared, outsourced, or embedded in product teams that move faster than central governance.

There is no universal standard for this yet, but current guidance suggests three common edge cases. First, in outsourced CI/CD environments, the external provider may operate the pipeline while the internal application owner still owns the risk acceptance. Second, for managed edge fleets, infrastructure teams may hold patch authority while business teams retain operational dependency decisions. Third, in hybrid environments, one team may own the credential while another owns the exposed service, which means both must be accountable for different failure modes. The practical answer is to document control ownership at the level of secrets, signing keys, patching, segmentation, and approval workflow rather than at the level of broad system labels.

That approach aligns with the compromise patterns described in 52 NHI Breaches Analysis, where the breach often traces back to unmanaged identity or access sprawl before any obvious system failure appears. In blended cloud-edge estates, accountability breaks down when asset inventory is incomplete and no team can prove who last controlled the credential, firmware, or release trust chain.

Related resources from NHI Mgmt Group

• Who is accountable when a hardcoded private key causes device compromise?
• Who is accountable when a privileged appliance login path is left exposed?
• Who is accountable when a compromised build identity poisons downstream software?
• How should teams reduce the risk of exposed AI credentials being abused?