Who is accountable when a CI/CD identity is abused?

Why This Matters for Security Teams

When a CI/CD identity is abused, the blast radius is rarely limited to one repository or one engineer. Pipeline identities often hold signing rights, deployment access, package publishing permissions, and secret retrieval capability, which means abuse can turn a build system into a supply chain pivot. The accountability question matters because incidents usually span multiple owners: platform teams, application teams, security, and governance.

NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That combination makes CI/CD identities a governance problem, not just an engineering one. The NIST Cybersecurity Framework 2.0 reinforces that accountability must be assigned across identify, protect, detect, respond, and recover functions, rather than assumed to sit with one admin.

In practice, many security teams discover ownership gaps only after an abused pipeline token has already been used to move laterally, publish a malicious artifact, or exfiltrate secrets.

How It Works in Practice

Accountability for CI/CD identity abuse should follow control ownership, not incident blame. The team that owns the pipeline identity is responsible for its design, scope, rotation, and revocation. The development team is responsible for requesting the minimum access needed and for not embedding long-lived secrets into workflows. The governance or security function is responsible for making sure access reviews, segregation of duties, and revocation triggers actually exist and are enforced.

That division maps cleanly to how machine identities behave. A pipeline identity is not a person, so human-centric access assumptions do not hold. Security teams should treat it as an operational workload identity with explicit lifecycle management. That means:

• Inventory the CI/CD identity and every place it can authenticate.
• Bind access to the pipeline workload, not to a shared human credential.
• Use short-lived tokens and ephemeral secrets instead of static keys.
• Require change control for privileged pipeline steps such as deployment, signing, and secret access.
• Log who approved the access, who implemented it, and who can revoke it.

This is where guidance from the CI/CD pipeline exploitation case study and the Top 10 NHI Issues becomes operationally useful: abuse often starts with overbroad permissions, then expands through secret reuse, insecure build steps, or overly trusted runners. The right response is to assign a named owner for the pipeline identity, a separate approver for privilege changes, and a security control owner for monitoring and revocation. These controls tend to break down in monorepos with shared runners and cross-team deployment pipelines because ownership is diffuse and access paths are reused across many services.

Common Variations and Edge Cases

Tighter pipeline controls often increase delivery friction, so organisations must balance release speed against the risk of uncontrolled machine access. Current guidance suggests that the answer changes depending on whether the CI/CD system is centrally run, team-specific, or managed by a third party.

In a centrally managed platform, accountability usually sits with the platform team for identity issuance and with app teams for requesting the right scope. In a federated setup, shared responsibility is broader because different teams may control build runners, artifact repositories, and cloud deployment roles. In outsourced or SaaS-managed CI/CD, the vendor may operate the service, but the organisation still owns the identity policy and the access granted to its own environments. That distinction is important because third-party control does not remove internal accountability for excess privilege.

The hardest edge case is when a compromised pipeline identity has permission to modify the pipeline itself. At that point, incident response must include both identity revocation and trust reset for the build chain. The 52 NHI Breaches Analysis shows that identity abuse often persists because organisations delay revocation and fail to define ownership clearly. There is no universal standard for this yet, but best practice is to document a primary owner, a backup approver, and a revoke path for every CI/CD identity.

Related resources from NHI Mgmt Group

• Who is accountable when an AI workflow touches CUI without a distinct identity?
• Who is accountable when a valid identity makes a harmful decision?
• Who is accountable when an MCP server is abused through a malicious package or proxy?
• Who is accountable when a compromised identity is not contained quickly?