Backstabber's Knife Collection¶
Ohm, M., Plate, H., Sykosch, A., & Meier, M. (2020). Backstabber's Knife Collection: A Review of Open Source Software Supply Chain Attacks. Proceedings of DIMVA.
Cited by¶
3 citations across 3 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Associative Property Transfer
- It also appears in brand and marketing (value flowing across endorsement links, scandal contagion to parent brands), in software dependency reasoning (blame assigned by call-graph proximity, risk re-assessed for dependents of a compromised dependency)
This sourceAnalyzes how a compromise in one dependency propagates risk to every downstream dependent along the dependency/call graph — the software-supply-chain instance of property-flow along an associative link.
Supported in partVerified against the work's full text
Shows a malicious or vulnerable package puts dependent projects at risk through dependency trees; says nothing on brand effects, call-graph blame, or re-assessing dependents' risk.
“Open source software supply chain attacks are comparable to the problem of vulnerable open source packages which may pass their vulnerability to dependent software projects.”
- It also appears in brand and marketing (value flowing across endorsement links, scandal contagion to parent brands), in software dependency reasoning (blame assigned by call-graph proximity, risk re-assessed for dependents of a compromised dependency)
- Record-Reality Divergence
- Warehouse and retail inventory (phantom inventory) — stock records diverge from physical counts through shrinkage and mis-scans; replenishment algorithms under- or over-order based on the divergence direction. Software supply chain — lockfiles point at registry artefacts that have been yanked, replaced, or namespace-attacked; build systems install the wrong code.
This sourceDocuments lockfile/registry artefacts being yanked, replaced, or namespace-attacked so build systems install the wrong code — a record (lockfile) diverging from the registry reality it references.
Supported in partVerified against the work's full text
The review documents typosquatting, reuse of withdrawn package identifiers and removed malicious packages, but never discusses lockfiles or build systems installing stale-record targets.
“An attacker might also use the opportunity to reuse the identifier of an existing project, package, or user account withdrawn by its original and legitimate maintainer”
- Warehouse and retail inventory (phantom inventory) — stock records diverge from physical counts through shrinkage and mis-scans; replenishment algorithms under- or over-order based on the divergence direction. Software supply chain — lockfiles point at registry artefacts that have been yanked, replaced, or namespace-attacked; build systems install the wrong code.
Domain-specific¶
- AI Supply-Chain Attack
- Training-data poisoning — web-scraped sets, crowdsourced labels, and continuous-learning feedback loops are paths by which an attacker writes a trigger-conditioned backdoor into the training corpus. Model-hub backdoors — pretrained checkpoints on Hugging Face, TensorFlow Hub, or internal mirrors are replaced or trojaned with hidden behavior that passes standard benchmarks because the evaluation set is not the trigger set. Package and dependency attacks — typosquatted PyPI/conda packages, malicious post-install scripts, and CI/CD compromises, the classical software-supply-chain playbook repurposed AI-side. Tokenizer and prompt-template tampering — subtle changes to upstream tokenizer files or system-prompt templates alter effective model behavior without touching weights. Evaluation-set contamination — writing into a benchmark suite to make a weak model look strong (test-set leakage) or a strong model look weak (planted hard cases). Classical software supply chain (shared substrate) — the SolarWinds / event-stream / xz-utils channel-compromise cases are the same mechanism on the code-only inheritance surface
This sourceReview of open-source software supply-chain attacks, cataloguing the event-stream npm takeover and the reach of such package compromises.
Supported in partVerified against the work's full text
“A recent attack on the npm package event-stream demonstrates the potential reach of such attacks: The alleged attacker was granted ownership of a prominent npm package simply by asking the original developer to take over its maintenance.”
- Training-data poisoning — web-scraped sets, crowdsourced labels, and continuous-learning feedback loops are paths by which an attacker writes a trigger-conditioned backdoor into the training corpus. Model-hub backdoors — pretrained checkpoints on Hugging Face, TensorFlow Hub, or internal mirrors are replaced or trojaned with hidden behavior that passes standard benchmarks because the evaluation set is not the trigger set. Package and dependency attacks — typosquatted PyPI/conda packages, malicious post-install scripts, and CI/CD compromises, the classical software-supply-chain playbook repurposed AI-side. Tokenizer and prompt-template tampering — subtle changes to upstream tokenizer files or system-prompt templates alter effective model behavior without touching weights. Evaluation-set contamination — writing into a benchmark suite to make a weak model look strong (test-set leakage) or a strong model look weak (planted hard cases). Classical software supply chain (shared substrate) — the SolarWinds / event-stream / xz-utils channel-compromise cases are the same mechanism on the code-only inheritance surface
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 3 of 3 citations: 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:ffc0a11e4bdc · see in the full table