Who is accountable when a third-party script causes downstream compromise?

Why This Matters for Security Teams

When a third-party script causes downstream compromise, the technical blast radius is rarely limited to the code that was imported. The real issue is trust delegation: the consuming organisation approved execution, permissions, and data paths, even if the payload arrived through a supplier update. That is why supply chain events often become identity and secrets incidents, not just software defects.

NHIs Mgmt Group has documented how exposed secrets and third-party exposure are common failure modes, including the finding that Ultimate Guide to NHIs — Why NHI Security Matters Now reports 92% of organisations expose NHIs to third parties. That makes supplier trust a live access-control problem, not a procurement checkbox. The same pattern appears in Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign, where trusted integrations became the path to downstream compromise.

Security teams get this wrong when they treat third-party code as if it inherited safety from the vendor relationship alone. In practice, many teams discover accountability gaps only after tokens are stolen, lateral movement starts, and no one can say who approved the trust boundary.

How It Works in Practice

Accountability should be mapped to the organisation that accepted the risk, but responsibility needs to be distributed across procurement, security, engineering, and platform owners. The consuming organisation decides whether the script may run, what network and secret access it gets, and how quickly it can be revoked. That is the operational locus of control.

In practical terms, teams should treat every third-party script as a workload with an identity, a permission set, and a lifecycle. Current guidance suggests combining software supply chain controls with non-human identity governance so that approval is not just vendor-centric. The OWASP Non-Human Identity Top 10 is useful here because it frames service accounts, API keys, and automation credentials as governed identities rather than incidental implementation details.

• Inventory every script, package, and CI/CD integration that can execute in production or staging.
• Assign a named risk owner for each trust decision and require documented approval for elevated access.
• Use least privilege for tokens, secrets, and network paths, with short TTLs where possible.
• Rotate or revoke credentials immediately on supplier change, compromise, acquisition, or policy drift.
• Monitor runtime behaviour for unusual tool use, data access, or outbound exfiltration.

For control design, pair this with NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where supply chain and access enforcement need auditability. The strongest lesson from NHIMG research is that third-party exposure is common enough to require default-off trust and explicit re-approval, not inherited confidence. These controls tend to break down in environments with unmanaged CI runners and broad shared credentials because there is no reliable boundary between vendor code and internal execution context.

Common Variations and Edge Cases

Tighter supplier controls often increase integration overhead, so organisations have to balance developer velocity against the cost of revalidation and revocation. That tradeoff becomes sharper when the script is embedded in customer-facing systems, where a small dependency update can affect many downstream services at once.

There is no universal standard for assigning legal versus operational accountability in every supply chain incident. In most security programs, the practical answer is that the vendor may be at fault for introducing the compromise, but the consuming organisation remains accountable for the access it granted and the safeguards it failed to enforce. That distinction matters when the supplier is acquired, the package maintainer changes, or the script moves from test to production without review.

Edge cases also include open-source components, browser-delivered scripts, and managed SaaS integrations. In those scenarios, the trust decision often sits outside a classic procurement record, so the owning team needs compensating controls: code signing checks, dependency pinning, secret scoping, and fast offboarding procedures. If a third-party component can reach secrets, APIs, or deployment tooling, the organisation should assume it is part of the identity perimeter and govern it accordingly. The best practice is evolving, but the accountability model is clear: trust granted is risk owned.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party NHI causes PCI scope exposure?
• Who is accountable when a third-party OAuth app causes a breach?
• Who is accountable when a third-party identity compromise leads to customer exposure?
• Who is accountable when a third-party SaaS app causes a compliance failure?