Who is accountable when compromised third-party code alters transactions?

Why This Matters for Security Teams

When compromised third-party code alters transactions, the technical failure is usually only the last link in a chain of governance, procurement, and runtime control gaps. The organisation that selected the software and allowed it to execute in a trusted path remains accountable, even if the code came from a vendor, package registry, plugin store, or outsourced developer. That is why supply chain risk cannot be treated as an externality.

This is especially visible in NHI-heavy environments, where code and automation frequently act with embedded secrets and broad API reach. NHIMG notes that 92% of organisations expose NHIs to third parties, which makes the trust boundary operationally fragile rather than theoretical. The issue is not just whether code is signed or reviewed, but whether the runtime can limit what that code can touch once it is loaded. See the Ultimate Guide to NHIs — Why NHI Security Matters Now and the OWASP Non-Human Identity Top 10 for why compromised machine identities often become the real transaction-control failure point. In practice, many security teams discover this only after an unsigned dependency, malicious plugin, or token leak has already influenced live business logic.

How It Works in Practice

Accountability starts with defining who owns the trust boundary, who approves third-party execution, and who can stop the code when its behaviour changes. For transaction integrity, that usually means application owners set the allowed execution path, security defines the control baseline, and platform teams enforce it at runtime. The practical challenge is that static trust is too coarse once code can call APIs, read secrets, or chain into other services.

Current guidance suggests treating third-party code as a bounded workload with least privilege, not as a fully trusted extension. That means separate identities for the workload, short-lived credentials, and runtime policy checks that constrain what the code can do on each request. NHI programs increasingly pair this with secret isolation, token scoping, and explicit approvals for privileged actions. The 52 NHI Breaches Analysis shows how quickly compromised machine access turns into downstream abuse when entitlements are broad. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for access enforcement, monitoring, and accountability across the full lifecycle.

• Inventory every third-party package, plugin, and embedded component that can alter transactions.
• Assign an owner for approval, review, rollback, and incident response.
• Run third-party code under a workload identity with least-privilege, short-lived secrets.
• Inspect transaction-impacting actions at runtime, not only at build time.
• Log and attest who approved the trust boundary and who can revoke it.

These controls tend to break down in fast-moving CI/CD environments where plugins, build steps, and runtime agents share the same credentials and can modify production transactions without a clean policy boundary.

Common Variations and Edge Cases

Tighter supply chain control often increases release friction, requiring organisations to balance velocity against assurance. That tradeoff becomes sharper when the third-party code is deeply embedded in a payment flow, trading engine, or workflow orchestrator, because overly broad blocking can interrupt legitimate business operations.

There is no universal standard for this yet, but best practice is evolving toward provenance checks, code signing, dependency review, and runtime allowlisting together rather than in isolation. A signed package can still be harmful if it inherits a privileged token, and a clean dependency scan does not prevent a trusted plugin from changing transaction amounts at runtime. The Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack illustrate how trusted automation can be turned into a control plane for abuse. In mature environments, accountability also extends to procurement and vendor management, because choosing the component is part of choosing the risk. The hard cases are highly automated platforms where third-party code is allowed to execute with production secrets and no independent approval step for transaction changes.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party product hides a vulnerable component?
• Who is accountable when replayed tokens come from a compromised third-party integration?
• Who should be accountable when a third-party connected app token is compromised?
• Who is accountable when third-party code or AI tooling expands breach exposure?