Summary: Wiki pages for raw/Supply-chain-attacks/ — the AI supply chain taxonomy and its attacks, plus (filed here but topically adjacent) securing LLM applications and AI coding assistants.
Sources: raw/Supply-chain-attacks/ (8 files, ~39,400 words)
Last updated: 2026-07-29
Pages
| Page | Covers |
|---|---|
| ai-supply-chain | The five-layer taxonomy, grey zones, what differs from traditional software |
| supply-chain-attacks | Five attack paths, with real incidents |
| provenance-and-assurance | SLSA, SBOM, in-toto, signing — the defensive centre of gravity |
| do-users-write-insecure-code | Stanford CCS ‘23 — the vault’s best empirical evidence on AI coding risk |
| ai-assistant-instructions | OpenSSF guidance on instruction files as a security control |
| securing-llm-applications | Defences for code that calls models — a previously uncovered layer |
Two primary sources worth knowing
Plexal & Oxford GCSCC, Securing the AI Supply Chain (March 2026), supported by LASR — the first non-vendor institutional supply-chain source in the vault. Workshop-derived, and the origin of the five-layer taxonomy.
Perry, Srivastava, Kumar & Boneh (Stanford), Do Users Write More Insecure Code with AI Assistants?, ACM CCS ‘23 — peer-reviewed controlled study, 47 participants, five tasks, three languages.
Between them these are the two most citable sources added to the vault in the last three ingests.
Five findings
- 78% of organisations have limited or partial visibility of their own AI supply chain; 28% had changed vendors over trust or compliance concerns (Plexal/Oxford).
- Developers with AI assistants wrote less secure code — and were more confident it was secure. The tool inverts the calibration between confidence and correctness. See do-users-write-insecure-code.
- The CIA triad is insufficient for AI supply chain risk. Plexal/Oxford add explainability, fairness, robustness, reproducibility and accountability — reaching independently a list that overlaps NIST’s seven characteristics.
- Provenance beats detection when the artifact isn’t inspectable. Google’s argument for models mirrors CMU’s for training data (chain of custody) — two domains, one conclusion.
model.load()is a code-execution sink. Wiz’s s1ngularity case and OWASP’s “malicious pickling” describe the same mechanism from two directions.
Real incidents documented here
- Ultralytics — widely-used AI library compromised via GitHub, shipping cryptominers into training and inference environments
- s1ngularity — malicious payloads embedded in trusted model artifacts, “turning the model loading process itself into an execution vector”
- CVE-2025-23266 “NVIDIAScape” — privileged GPU-runtime vulnerability exposing shared workloads
A scope note
The folder name says supply chain; three of the eight sources are about AI coding assistants and LLM application security instead. Pages follow the raw-folder convention, but topically:
- do-users-write-insecure-code and ai-assistant-instructions belong with Secure Coding Patterns
- securing-llm-applications fills the “code that calls models” gap that collection flagged as uncovered vault-wide
All are cross-linked both ways. Full note in log.
Gaps this closes, and one it opens
Closed: the vault’s last empty source folder; the “secure patterns for building LLM applications” gap; and the absence of vendor-independent evidence on AI coding risk.
Opened: multimodal prompt injection — instructions embedded in images that vision models interpret and follow — has no PITAX technique and no ATLAS technique. Nearest neighbours are T26 Spatial Byte Arrays and T03 Binary Streams, neither of which covers vision-model instruction-following.
Cross-collection links
- Slopsquatting — the supply-chain attack your own tooling recommends
- Data Poisoning — the AI-core layer under attack
- LLM04 — supply chain and malicious pickling
- Model Theft — exposed inference endpoints as a supply-chain exit
- Root index
Log
See log.