Supply Chain Poisoning

• Supply chain poisoning is the deliberate compromise of development pipelines by injecting malicious code, metadata, or artifacts to propagate backdoors and unauthorized behavior.
• It affects diverse components such as open-source packages, build automation, and ML model supply chains, with attackers exploiting dependency indirection to trigger latent threats.
• Detection strategies rely on dynamic behavioral analysis, provenance checks, and policy enforcement, though challenges persist across heterogeneous threat surfaces.

Supply chain poisoning is the deliberate compromise of the artifacts, metadata, or execution paths through which software and machine-learning systems are built, distributed, loaded, fine-tuned, or extended. In the software literature, it denotes the insertion of malicious code into components of an application’s software supply chain so that the payload propagates downstream into consumer applications; in package ecosystems, it refers to malicious code embedded in published packages; in build pipelines, it includes poisoning build automation rather than program source; and in model ecosystems, it includes malicious pre-trained weights, poisoned fine-tuning data, and model artifacts whose loading path executes attacker-controlled behavior (Liu et al., 2024, Zheng et al., 2024, Pappas et al., 13 Jan 2026, Wang et al., 2024, Liu et al., 27 Aug 2025). Across these settings, the common feature is indirection: the attacker compromises a trusted upstream dependency, pipeline stage, training corpus, or extension mechanism, and the victim later activates or inherits the malicious behavior during ordinary development or deployment workflows.

1. Conceptual scope and defining properties

The term spans several related but non-identical threat models. In open-source package ecosystems such as NPM and PyPI, supply chain poisoning is the deliberate injection of malicious code into packages published in the ecosystem, so that downstream applications that install or depend on those packages become compromised (Zheng et al., 2024). In build systems, pipeline poisoning is framed as a form of software supply chain poisoning in which the attacker compromises build automation code and pipeline stages that generate, test, package, or release the software, rather than attacking the program’s C source directly (Pappas et al., 13 Jan 2026). In pre-trained-model ecosystems, model supply chain poisoning occurs when a malicious publisher releases a modified PTM that behaves normally on benign inputs but transfers a backdoor into downstream models fine-tuned from it (Wang et al., 2024). In model-sharing platforms that rely on Python pickle, the supply chain risk is sharpened by the fact that pickle is fundamentally code-executing serialization, so simply loading a malicious model can execute attacker-controlled code (Liu et al., 27 Aug 2025).

A central distinction in this literature is between direct compromise of a deployed system and compromise of the production or acquisition path leading to that system. The supply chain is poisoned at the source, at an intermediate transformation step, or at an extension boundary, and the final consumer often interacts only with a seemingly legitimate artifact. This suggests that supply chain poisoning is not defined by a single malicious mechanism, but by the attacker’s location in the dependency, build, training, or extension chain.

Another recurring distinction is between proof of compromise and indicators of elevated risk. The “software supply chain smell” literature explicitly defines a smell as a package that matches patterns indicating a potential security issue “current or to come in the future,” emphasizing that such signals are risk indicators rather than proof of an exploit (Schmid et al., 25 Mar 2026). This separation matters because many defensive techniques in the area operate by surfacing structural weakness, missing provenance, or suspicious behavior rather than by conclusively identifying malicious payloads.

2. Attack surfaces and adversary models

The attack surface is heterogeneous because modern software and AI systems are assembled from registries, build scripts, repositories, model hubs, agent-skill marketplaces, and data-collection pipelines. In package ecosystems, the literature emphasizes install-time, import-time, and run-time activation. PyPI setup.py and NPM preinstall or postinstall scripts can execute during installation; package entry points such as __init__.py or main can execute on import; and malicious logic can remain dormant inside exported functions or methods until invoked with appropriate arguments (Zheng et al., 2024). The iOS dependency-management literature adds dependency confusion and dependency hijacking, made practical by the fact that reverse-engineerable app binaries expose internal package names, versions, and hosting locations in a MATE setting (Schmidt et al., 28 Jan 2026).

Build pipelines introduce a different class of attack surface. Modern C projects contain substantial build system code in autoconf, Make, and C preprocessor code, and that code automates configuration, compilation, testing, packaging, and deployment (Pappas et al., 13 Jan 2026). Because it controls the actual construction of software, a compromised pipeline can poison the final artifact even when the visible program source appears benign. The same paper argues that build code can disable tests, verification, or bug-finding steps, which means it can also circumvent ordinary security tooling.

Machine-learning supply chains add model-loading, fine-tuning, and data-ingestion paths. One threat model assumes an untrusted third-party model publisher who uploads a malicious pickle-based model to a public hub and relies on the victim to load it through normal inference, fine-tuning, or evaluation workflows (Liu et al., 27 Aug 2025). Another assumes a malicious PTM publisher who distributes a backdoored checkpoint and depends on downstream fine-tuning to preserve, rather than erase, the backdoor (Wang et al., 2024). A third assumes a data-only adversary who inserts a small number of crafted instruction-response pairs into an instruction-tuning set, with no ability to alter pretrained weights, training algorithms, inference prompts, or data order (Sun et al., 22 May 2026).

Agentic systems broaden the notion of supply chain poisoning beyond static dependencies. One line of work formalizes three AI-agent threat models: direct poisoning of fine-tuning traces, environmental poisoning in webpages or tool outputs used to generate those traces, and supply chain poisoning via a pre-backdoored base model fine-tuned on clean data (Boisvert et al., 3 Oct 2025). Another studies third-party “agent skills” distributed through open marketplaces and loaded into coding agents as operational directives; after retrieval, a malicious skill can steer file writes, shell commands, network requests, or persistent configuration changes on the host (Qu et al., 3 Apr 2026). Reinforcement-learning systems admit a further variant in which the attacker is a supplied external agent embedded in the training workflow and poisons the victim’s experience through legitimate interactions only (2505.19532).

3. Software ecosystems, build pipelines, and dependency management

Build-system poisoning is notable because it targets code that is often treated as operational glue rather than as a first-class attack surface. One paper states that the Linux kernel build system is over 200k LOC and argues that build systems are large, powerful, and often under-secured compared with program code (Pappas et al., 13 Jan 2026). The XZ Utils case study is used to illustrate the mechanism: attackers disguised a payload as test cases, modified the build-to-host.m4 macro, used autoconf-generated configuration scripts, decompressed and decrypted hidden content through shell commands, ultimately injected liblzma_la-crc64-fast.o, and linked that object into the final liblzma library. The malicious flow crossed expected phase boundaries by moving information from test files into configure and build stages. Foreman, a 177-line Python prototype based on development phase isolation, detected the attack by warning that the compile phase accessed bad-3-corrupt_lzma2.xz and good-large_compressed.lzma, the poisoned files used in the attack (Pappas et al., 13 Jan 2026).

In open package ecosystems, the empirical focus is often on behavioral detection. OSCAR fully executes packages in a sandbox environment, fuzz-tests exported functions and classes, monitors network, file, and process behavior through aspect-based hooks, and uses Falco as a system-level fallback (Zheng et al., 2024). On a benchmark dataset, it reports TP 459, FP 3, FN 41, Precision 0.99, Recall 0.92, and F1 0.95 for NPM, and TP 423, FP 4, FN 77, Precision 0.99, Recall 0.85, and F1 0.91 for PyPI. In deployment on Ant Group’s mirrors since January 2023, it identified 10,404 malicious NPM packages and 1,235 malicious PyPI packages over 18 months (Zheng et al., 2024). These results frame poisoning as a runtime behavioral problem rather than merely a source-code pattern problem.

The iOS dependency-management literature shows how ecosystem design and binary transparency can make poisoning practical at scale. In a dataset of 9,212 iOS apps, the authors found that 9,866 frameworks from 2,084 apps (22.62%) were not registered in the public CocoaPods repository, making them potentially susceptible to dependency confusion, and conclude that vulnerable dependencies in the dataset could affect 162 apps (1.76%) overall (Schmidt et al., 28 Jan 2026). The same work reports that a single hijacked CocoaPod via an abandoned domain could compromise 63 iOS apps and affect millions of users. CocoaPods is especially exposed because centralized resolution, mixed public/private sources, install-time code execution via prepare_command, and forwarding to external source URLs combine into a broad attack surface; Carthage and SwiftPM remove classic confusion but remain vulnerable to URL hijacking when repository namespaces or hosting domains become reclaimable (Schmidt et al., 28 Jan 2026).

These studies collectively indicate that supply chain poisoning in software ecosystems is not reducible to malicious package publication alone. It also includes ambiguity in dependency resolution, weak ownership validation, URL forwarding, missing traceability from artifact to source, and build automation capable of rewriting the artifact without visibly modifying the program source.

4. Model artifacts, serialization, and training-data poisoning

Model supply chain poisoning has two major technical forms in the cited literature: malicious artifacts whose loading path is itself executable, and malicious adaptation or training data that implants latent behavior. The pickle-based model work identifies 22 distinct pickle-based model loading paths across NumPy, Joblib, PyTorch, TensorFlow/Keras, and NeMo, and reports that 19 are entirely missed by existing scanners (Liu et al., 27 Aug 2025). It also introduces Exception-Oriented Programming (EOP), a scanner-bypass technique based on intentionally triggering exceptions in scanner logic while preserving successful loading in the real framework. The paper reports 9 EOP instances, 7 of which bypass all scanners, and discovers 133 exploitable gadgets, with an almost 100% bypass rate overall and an 89% bypass rate even against the best-performing scanner (Liu et al., 27 Aug 2025). The decomposition into model-loading surface and risky-function surface shows that scanner coverage can fail both before and after deserialization reaches pickle execution.

Transferable backdoors in pre-trained models represent a second mode of poisoning. TransTroj formulates the attack as an embedding-indistinguishability problem in which a backdoored PTM $\widetilde{F}$ should cause a downstream model $\widetilde{f}$ to output a target class $y_t$ for a triggered input:

$$y_t = \widetilde{f}(\boldsymbol{x}\oplus \boldsymbol{t}).$$

The paper decomposes this into pre-indistinguishability and post-indistinguishability and uses a two-stage optimization to separately optimize the trigger and the victim PTM (Wang et al., 2024). It reports nearly 100% attack success rate on most downstream tasks, with the worst cited case at 91.47% on Caltech 256 with VGG-11, and states that it outperforms prior task-agnostic attacks by 18% to 99%, with 68% average improvement (Wang et al., 2024). The central security claim is that fine-tuning does not reliably wash out the backdoor when the malicious association is aligned at the embedding level.

Instruction-tuned LLMs admit a different poisoning objective. PoisonForge studies task-level targeted poisoning in which a small number of crafted instruction-response pairs induce a model to embed attacker-specified entities in outputs for a target task family while behaving normally elsewhere (Sun et al., 22 May 2026). With only 10 poisoned examples among 1,000 fine-tuning examples, 11 of 12 models exceed a 70% attack success rate in their most vulnerable configuration; mean spillover is about 0.47%; and the strongest result reaches 91.5% ASR (Sun et al., 22 May 2026). The paper further reports that full-parameter fine-tuning reduces mean ASR to 4.7% versus 43.1% for LoRA, and full-token loss reduces mean ASR to 17.7% versus 38.6% for completion-only loss (Sun et al., 22 May 2026). This suggests that seemingly small training-design choices can strongly affect susceptibility.

A related line of work on AI agents shows that poisoning can be introduced not only through task datasets but through the agent’s broader training supply chain. The authors report that poisoning as few as 2% of the collected traces can embed a trigger-based backdoor causing an agent to leak confidential user information with over 80% success when the trigger is present, and that this vulnerability holds across direct fine-tuning-data poisoning, environmental poisoning, and pre-backdoored base models (Boisvert et al., 3 Oct 2025). A plausible implication is that training-data provenance and model provenance cannot be treated as separable problems in agentic systems.

5. Agent skills, robotics, and reinforcement-learning supply chains

LLM coding-agent ecosystems extend the supply-chain problem from packages and models to reusable skills. The DDIPE attack embeds malicious logic inside code examples and configuration templates in skill documentation, relying on the agent’s tendency to reuse such examples during normal task completion (Qu et al., 3 Apr 2026). Using an LLM-driven generation pipeline, the authors construct 1,070 adversarial skills from 81 seeds across 15 MITRE ATTACK categories. Across four frameworks and five models, DDIPE yields bypass rates from 11.6% to 33.5%; static analysis catches 90.7% of samples, but 9.3% evade all four detection layers, and 27 undetected samples also bypass model alignment (Qu et al., 3 Apr 2026). The work argues that agent-skill marketplaces function less like documentation hosting and more like executable software distribution, because the same agent that reads the skill can also exercise file I/O, shell access, network access, package installation, and configuration writes.

Robotic systems expose a still more direct physical pathway from supply-chain compromise to unsafe behavior. A proof-of-concept attack on Secure ROS 2 uses a Trojan-infected Debian package to modify ros2 security create_keystore and ros2 security create_enclave, exfiltrating .pem, .key, permissions.xml, and governance.xml over DNS in Base64-encoded chunks (Sakib et al., 31 Oct 2025). Once the attacker reconstructs the keystore, the stolen credentials allow re-entry into the DDS/SROS 2 network as an authenticated participant. On a secure ROS 2 Humble testbed running a four-stop-sign navigation routine, control-topic injections caused forced braking, sustained high-speed acceleration, and continuous turning loops, while perception-topic spoofing induced phantom stop signs and suppression of real detections (Sakib et al., 31 Oct 2025). The attack does not break DDS-Security cryptographically; it steals the trust anchors that make authentication meaningful.

Reinforcement-learning workflows admit a supply-chain backdoor that requires no direct access to victim internals. SCAB assumes the attacker is an externally supplied agent, or an embedded agent in the environment, that interacts with the victim through the normal action interface only (2505.19532). By poisoning a mere 3% of training experiences, SCAB can successfully activate over 90% of triggered actions and reduce the average episodic return by 80% for the victim (2505.19532). The attack is implemented through a finite-state strategy that alternates among Winning, Triggering, Observing, and Rewarding states, causing the victim to learn a malicious association through ordinary gameplay rather than direct reward or observation tampering. This makes the attack structurally analogous to poisoned dependencies that appear benign until a later trigger activates the latent compromise.

6. Detection strategies, trust signals, and persistent limitations

Defensive work in this area falls into three broad categories: policy enforcement on production phases, dynamic behavioral analysis, and lightweight trust signals. Development phase isolation is an explicit policy model for build automation. A build system satisfies phase isolation when each development phase executes under a well-defined set of access permissions, restricting file access, environment-variable access, shell-command execution, and system-call behavior according to least privilege (Pappas et al., 13 Jan 2026). The prototype implementation primarily checks file access by comparing stat() results before and after each phase, but the same paper proposes extending the model to read-versus-write distinctions, command-execution checks, combined static and dynamic analyses, automatic permission inference, and sandboxed enforcement (Pappas et al., 13 Jan 2026). Its scope is deliberately limited to malicious cross-phase information flow rather than all supply-chain threats.

The “software supply chain smell” literature offers a complementary, lightweight view. Dirty-Waters combines dependency manifests or lockfiles, registry metadata, and GitHub repository checks to detect smells such as missing or invalid source URLs, inaccessible release tags or commit SHAs, deprecated packages, forks, missing signatures, invalid signatures, aliases, and absent provenance (Liu et al., 2024, Schmid et al., 25 Mar 2026). In the broader cross-ecosystem study of the 50 most depended-upon packages in Maven and NPM, the authors report 1,891 unique Maven packages and 8,071 unique NPM packages. For Maven, Inaccessible Commit SHA/Release Tag affects 547 packages (62.8%) and No Code Signature affects 249 packages (28.6%); for NPM, No Provenance affects 8,045 packages (99.7%) (Schmid et al., 25 Mar 2026). The same work stresses that the presence of a smell means “investigate further,” not “reject automatically,” and that absence of smells does not imply safety.

The literature also makes the limitations of current defenses explicit. Static detectors in package ecosystems suffer from high false positive rates and brittleness under obfuscation and dynamic execution, while dynamic detectors can miss deeply hidden behavior if they do not exercise the right functionality (Zheng et al., 2024). Pickle-model scanners are shown to have incomplete path coverage, denylist weakness, allowlist weakness, hybrid-scanner weakness, and brittle parsing logic exploitable through EOP (Liu et al., 27 Aug 2025). In agent training pipelines, two guardrail models and one weight-based defense fail to prevent or reliably detect the malicious behavior induced by poisoned traces or backdoored base models (Boisvert et al., 3 Oct 2025). In coding-agent skill ecosystems, explicit instruction attacks can be blocked under strong defenses, but document-embedded code and configuration snippets still achieve direct execution (Qu et al., 3 Apr 2026).

A recurring conclusion is that supply chain poisoning cannot be reduced to vulnerability scanning or signature matching. The defensive problem includes authenticity, traceability, provenance, behavioral observation, and explicit modeling of which components should be allowed to influence which downstream phases. This suggests that effective supply-chain security must cover not only what code or model is fetched, but how it is transformed, loaded, extended, and reused on the path to a release artifact or autonomous action.