Category: Adversarial Security

Supply Chain Attack

Also known as: Third-Party Attack, Value Chain Attack

Simply put

A supply chain attack is a cyberattack that reaches its intended target indirectly, by first compromising a less secure outside vendor, supplier, or partner that has access to the target's data, systems, or software. Rather than attacking an organization head-on, the attacker exploits a trusted relationship to gain entry. Because the compromised element is trusted, such attacks can be difficult to detect.

Formal definition

A supply chain attack is a cyberattack that targets a less secure element within an organization's supply chain, commonly a trusted third-party vendor or supplier of software, services, or hardware, in order to gain access to the primary target's systems or data. The attack typically leverages the trust and access relationships between an organization and its external providers or partners, propagating from the compromised upstream component to downstream victims. Note that definitions in the evidence vary in emphasis, some focusing on software and service providers, others noting the physical integrity of hardware; this entry does not address organizational governance controls or defensive frameworks, which are out of scope here.

Why it matters

Supply chain attacks matter because they exploit the trust relationships that organizations must maintain with vendors, suppliers, and partners in order to operate. As the evidence indicates, an outside provider or partner with access to an organization's data and systems can become the pathway an attacker uses to reach the intended target. This indirect route is significant precisely because the compromised element is trusted, which, as the definition notes, can make such attacks difficult to detect.

For risk and governance professionals, the relevance lies in the fact that an organization's security posture is not solely a function of its own controls. When a less secure element within the supply chain is compromised, the effects can propagate downstream to organizations that had no direct fault in the initial breach. This challenges the boundaries of conventional risk assessments, which often focus on an organization's internal systems rather than the access relationships extended to third parties.

The evidence sources vary in emphasis, with some focusing on software and service providers and at least one noting the physical integrity of hardware. This variation is itself meaningful: the attack surface described under this term is broad, and professionals should be cautious about assuming a single, narrow definition. Defensive frameworks and organizational governance controls for supply chain risk are beyond the scope of this entry.

Who it's relevant to

Model Risk Managers and Data Scientists

Teams that rely on external software libraries, model components, or data services should understand that a compromised upstream provider can become an entry point into their own systems. This is distinct from model performance concerns and instead concerns the security of the access relationships extended to third parties that supply software, services, or data.

Compliance Officers and Auditors

Professionals assessing organizational risk should recognize that security exposure extends beyond internal systems to the vendors, suppliers, and partners that hold access to data and systems. The difficulty of detecting attacks that exploit trusted relationships is relevant to how third-party access is scoped and reviewed, though the specific control frameworks for doing so are out of scope for this entry.

Legal and Policy Specialists

Because a supply chain attack reaches its target indirectly through an outside vendor or partner, questions of accountability, contractual access, and liability can arise between the compromised third party and the downstream victim. The variation across sources in what elements count as part of the supply chain, from software and services to hardware, is relevant when defining the scope of vendor obligations.

Inside Supply Chain Attack

Compromise of an upstream component

A supply chain attack targets a dependency, vendor, tool, or artifact that an organization relies on rather than attacking the organization directly. In an AI context this can include third-party models, pre-trained weights, training datasets, open-source libraries, or the tooling used to build and deploy models.

Attack surface across the model lifecycle

Potential entry points span data sourcing, model acquisition, dependency management, build and deployment pipelines, and runtime inference infrastructure. Each stage where an external artifact is ingested or trusted can represent an exposure, though the specific relevance varies by system and deployment.

Data poisoning as a supply chain vector

Where an attacker manipulates externally sourced training or fine-tuning data to influence model behavior. This is one commonly discussed AI-specific pathway, though it is distinct from tampering with binaries or code and should not be treated as synonymous with the broader category.

Compromised model artifacts and provenance gaps

Pre-trained models, adapters, or serialized weights obtained from external repositories may carry tampered content or lack verifiable provenance. Weak provenance and integrity verification are typically what allow such compromises to go undetected.

Third-party and dependency risk

Reliance on vendors, model providers, and open-source packages introduces risk that is not fully controlled by the adopting organization. This overlaps with governance concerns (vendor oversight, accountability) and with risk management (identifying and monitoring exposures) without collapsing the two.

Common questions

Answers to the questions practitioners most commonly ask about Supply Chain Attack.

Is a supply chain attack in an AI context the same as a general software supply chain compromise?

Not exactly. While AI supply chain attacks share the general pattern of compromising an upstream dependency to reach a downstream target, they typically extend the attack surface to AI-specific components such as pre-trained models, model weights, training datasets, fine-tuning pipelines, and third-party model APIs. Treating the two as identical can cause teams to overlook artifacts that traditional software composition tooling does not inspect. That said, the underlying principle of trust in upstream providers is common to both, so conventional supply chain controls remain relevant even when they are not sufficient on their own.

Does using a model from a reputable provider or repository eliminate supply chain risk?

No. Sourcing a model or dataset from a well-known provider or repository reduces some risk but does not eliminate it. Provenance and reputation are signals, not guarantees, and controls typically manage rather than remove residual risk. Compromised artifacts, tampering during transit, poisoned training data, or malicious dependencies within an otherwise trusted package can still be present. Reliance on reputation alone should be treated as one input among several, alongside verification, integrity checks, and ongoing monitoring.

How can an organization establish provenance for models and datasets it did not build itself?

In many frameworks, provenance is established through a combination of documented sourcing, integrity verification, and record-keeping. Practically, this can include capturing where an artifact was obtained, validating cryptographic hashes or signatures where the provider offers them, and maintaining an inventory that records versions and origins. Where provenance information is incomplete or unavailable, that gap is itself a finding to document and treat as elevated inherent risk rather than assume away.

What role does a bill of materials play in managing AI supply chain risk?

A bill of materials—covering software dependencies and, where applicable, model and data components—supports visibility into what an AI system actually incorporates. It can help teams identify affected components when a vulnerability or compromise is disclosed upstream, and it supports the inventory function that many governance programs rely on. Its usefulness depends on being kept current and on the completeness of the components it captures; an outdated or partial listing provides limited assurance.

Where does responsibility for supply chain risk fit across the lines of defense?

Responsibilities are typically distributed rather than held by a single function. The first line—those developing or operating the AI system—generally owns day-to-day controls such as vetting sources and verifying integrity. The second line, such as risk or compliance functions, commonly sets policy, defines expectations for third-party components, and provides independent challenge. The third line, internal audit, typically provides assurance that these controls operate as intended. The precise allocation varies by organization and should be documented rather than assumed.

How should supply chain risk be monitored after a model or component is deployed?

Monitoring is generally treated as ongoing rather than a one-time check at onboarding. Practical measures can include tracking disclosures of vulnerabilities affecting incorporated components, watching for changes to externally hosted models or APIs, and re-verifying integrity when artifacts are updated. Because upstream conditions can change after initial approval, many programs tie supply chain monitoring to their broader inventory and change-management processes so that new risks are surfaced and reassessed over time.

Common misconceptions

A supply chain attack is the same as a data poisoning attack.

Data poisoning is one possible vector within the broader supply chain attack category, but supply chain attacks also include compromised code libraries, tampered model artifacts, and corrupted tooling. Treating the terms as interchangeable understates the range of exposures involved.

Using well-known open-source models or libraries eliminates supply chain risk.

Popularity or wide adoption does not remove the possibility of compromised or tampered components. Provenance verification, integrity checks, and ongoing monitoring reduce risk but do not eliminate it; residual risk typically remains even with reputable sources.

Supply chain security is purely a technical security concern, separate from AI governance and model risk management.

It intersects both. Governance structures address vendor oversight and accountability for externally sourced components, while model risk management addresses identifying, measuring, and monitoring the risks such components introduce. These functions overlap here but remain distinct in role and purpose.

Best practices

Maintain an inventory of externally sourced components, including third-party models, datasets, libraries, and tooling, so that dependencies and their provenance can be tracked across the model lifecycle.

Verify the integrity and provenance of acquired model artifacts and dependencies before use, applying validation checks appropriate to the deployment context rather than assuming trusted sources are safe.

Treat externally sourced training and fine-tuning data as a potential vector and apply appropriate review, monitoring, and controls proportionate to how the resulting model is used.

Coordinate between security, governance, and model risk functions so that vendor oversight, accountability, and risk monitoring responsibilities for external components are clearly assigned rather than assumed.

Establish ongoing monitoring for anomalous model behavior and for changes in upstream components, recognizing that controls reduce and manage risk but do not fully eliminate residual exposure.

Document assumptions, limitations, and out-of-scope elements of any supply chain risk assessment, noting where treatment is evolving or sector-specific rather than settled.