Who is accountable when a supply chain compromise spreads through trusted credentials?

Why This Matters for Security Teams

When a supply chain compromise spreads through trusted credentials, the incident is no longer just a software integrity problem. It becomes an identity and authorization problem, because the attacker is operating with legitimate publish rights, signing access, or automation credentials that already cross trust boundaries. That is why accountability usually sits across release engineering, platform security, and identity governance, rather than a single team.

The practical failure is not only stolen secrets. It is over-scoped automation identities, weak offboarding, and credentials that remain valid long after the service or pipeline that used them has changed. NHIMG’s research on Reviewdog GitHub Action supply chain attack shows how quickly trust in a workflow can be converted into credential exposure at scale. OWASP’s Non-Human Identity Top 10 frames the same issue from a governance angle: NHI sprawl turns one compromised credential into many downstream failures.

In practice, many security teams encounter accountability gaps only after a trusted pipeline has already pushed malicious changes or exfiltrated secrets, rather than through intentional ownership design.

How It Works in Practice

The cleanest way to assign accountability is to separate the control points that actually made the compromise possible. Release engineering usually owns the publishing workflow and artifact integrity. Platform security typically owns the guardrails around build systems, signing systems, and runtime permissions. Identity governance owns lifecycle controls for the automation identities that made the trust chain possible in the first place.

That division matters because trusted credentials rarely fail in isolation. A compromised token can be reused for package publishing, CI access, cloud API calls, or signing operations. In NHI terms, the question is not just “who lost the secret,” but “who approved the scope, who monitored use, and who revoked it when the workflow changed?” NHIMG’s Guide to the Secret Sprawl Challenge highlights why fragmented secret ownership makes that answer hard to reconstruct after the fact.

Current guidance suggests treating the credential as an operational asset with an explicit owner, expiry, and revocation path. That means:

• mapping each automation identity to a named business or engineering owner
• limiting publish rights to the minimum repository, registry, or environment scope
• requiring short-lived credentials for CI, release, and signing steps
• logging credential use with enough context to distinguish normal release activity from abuse
• running offboarding checks when a pipeline, maintainer, or integration is retired

For identity proof and lifecycle controls, NIST SP 800-63 Digital Identity Guidelines remains useful for thinking about proofing, binding, and reauthentication expectations, even though the document is not written specifically for software supply chains. These controls tend to break down when a single automation identity is reused across multiple repositories, clouds, and signing systems because attribution and containment become indistinguishable.

Common Variations and Edge Cases

Tighter credential scoping often increases operational overhead, requiring organisations to balance blast-radius reduction against release velocity. That tradeoff is real, especially where legacy CI/CD systems, third-party build actions, or package maintainers depend on long-lived tokens to keep releases moving.

There is no universal standard for accountability matrices in software supply chain incidents yet, so best practice is evolving. Some organisations assign primary ownership to the team that controlled the compromised credential, while others split accountability between the platform that issued it and the team that allowed it to be over-privileged. For vendor-managed build tools or open-source dependencies, the incident may also involve a third-party trust boundary, which makes post-incident governance more important than blame assignment.

NHIMG’s 52 NHI Breaches Analysis is useful here because it shows how often the root cause is not just compromise, but poor control ownership over non-human credentials. In high-assurance environments, the cleanest approach is to assign one team to credential issuance, one to runtime enforcement, and one to audit and revocation evidence. That model becomes less effective when vendors hide signing, build, or deployment logic behind opaque services, because the organisation may not control the identity lifecycle end to end.

Related resources from NHI Mgmt Group

• Who is accountable when AI tool use happens through unmanaged browser sessions?
• Who should be accountable when compromised npm packages spread through CI and developer systems?
• Who is accountable when a template engine flaw leads to host compromise?
• Who is accountable when shadow AI uses corporate credentials to process sensitive data?