Who is accountable when third-party trust relationships are exploited in a supply chain compromise?

Why This Matters for Security Teams

Supply chain compromise rarely begins with a dramatic intrusion. It more often starts with inherited trust that was never re-verified after a vendor change, a token handoff, or a software dependency update. When third-party access is exploited, accountability is shared in practice but not always in governance: the organisation that granted trust must own verification, and the third party must own the integrity of the access path.

This is why NHI governance cannot stop at passwords or human joiner-mover-leaver processes. Third-party trust often survives far beyond its original business justification, especially for API keys, CI/CD credentials, and delegated service accounts. The OWASP Non-Human Identity Top 10 frames these failures as identity and credential risks, not just vendor risks. NHIMG’s Reviewdog GitHub Action supply chain attack shows how trust in a third-party action can turn into widespread secret exposure once repository and workflow permissions are inherited without tight controls.

In practice, many security teams encounter the real ownership gap only after a vendor token, package, or automation account has already been used to move laterally or exfiltrate secrets.

How It Works in Practice

Accountability for exploited third-party trust should be assigned at three layers: business ownership, technical control ownership, and incident response ownership. The business owner approves the relationship, but the security or platform team must continuously validate what the third party can access, how long access persists, and whether the access is still required. This is where delegated credentials, secret scoping, and offboarding become non-negotiable control points.

For software supply chain risk, the question is not only who supplied the dependency or integration. It is also who allowed the trust chain to remain broad after initial onboarding. Current guidance suggests using least privilege, short-lived credentials, and explicit revocation triggers for vendor access, supported by monitoring that can detect unexpected tool use or package behaviour. NHIMG’s Shai Hulud npm malware campaign and LiteLLM PyPI package breach both demonstrate how third-party components can become credential theft paths when trust is assumed rather than continuously revalidated.

• Assign one owner for vendor onboarding, one for access approvals, and one for revocation verification.
• Inventory every inherited trust relationship, including CI/CD tokens, API keys, package maintainer access, and service-to-service credentials.
• Use time-bound access with documented renewal rather than open-ended exceptions.
• Require offboarding checks that revoke secrets, keys, tokens, and federation links, not just user accounts.
• Monitor for anomalous use of third-party paths, especially when access appears legitimate but the behavior changes.

The practical rule is simple: if the organisation can grant trust quickly but cannot prove it is still justified, accountability remains incomplete. These controls tend to break down in high-velocity CI/CD environments because access is embedded in automation, secrets are copied across pipelines, and revocation is slower than deployment.

Common Variations and Edge Cases

Tighter third-party controls often increase procurement, engineering, and review overhead, requiring organisations to balance operational speed against assurance. That tradeoff becomes sharper in managed services, open-source dependencies, and subcontractor chains, where no single party owns the full attack surface.

There is no universal standard for assigning blame in every supply chain compromise, especially when a breach crosses contractual, jurisdictional, and technical boundaries. Best practice is evolving toward shared accountability with explicit control ownership: the organisation should be accountable for due diligence, access scoping, and monitoring; the third party should be accountable for secure handling of its own credentials, build pipelines, and maintenance processes. The 52 NHI Breaches Analysis is a useful reminder that repeated incidents usually reflect weak trust governance rather than one-off mistakes.

For faster-moving environments, the right answer is often not perfect prevention but faster revocation and clearer evidence of control. Industry guidance increasingly points to Anthropic’s report on AI-orchestrated cyber espionage as a sign that automated abuse of trusted systems is becoming more scalable, not less. In those cases, accountability also extends to whether the organisation had enough telemetry to notice trust misuse before it became a supply chain event.

Related resources from NHI Mgmt Group

• Why do third-party credentials increase supply chain risk?
• Who should be accountable for third-party access removal?
• Who is accountable for SaaS security when third-party apps are involved?
• Who is accountable when third-party or guest device access is over-extended?