# Software Supply Chain Security in the Age of AI (Jonathan) > [!question] Lingering Questions > - What proportion of the "90–95% of flagged vulnerabilities are not actually relevant" figure (cited in Q&A) is dev/local-only tooling vs. genuinely low-severity production issues? > - Since registries won't hard-delete old vulnerable versions, is there a viable middle path — e.g., a registry-level "quarantine" state requiring explicit opt-in? > - Could provenance certificate issuance require a secondary, harder-to-steal attestation, given that this attack proved CI-level token theft is sufficient to forge a "valid" one? > - Is there a practical way to make transitive-dependency ownership assignable without creating a bottleneck role that itself becomes a burnout risk? > [!tip] Article Ideas > - A starter Zizmor config plus a Dependabot cooldown/min-release-age snippet as copy-paste templates for WordPress plugin/theme repos. > - A short runbook for "the first hour of a supply-chain compromise notification" (isolate machine, check vendor writeups, escalate to registry/GitHub) drawn from this talk's Q&A guidance. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Signing Narrows Trust to the Build System, It Doesn't Eliminate It]] — the Tanstack forged-provenance incident is a second, independent piece of evidence for exactly this note's claim: a control that verifies one link in the trust chain (here, package origin) leaves every other link — especially CI-level publish access — exactly where it was. > - [[3. Resources/Permanent Notes/Adopting an Ecosystem Component Inherits Its Maintenance Risk]] — the abandonment statistics (61% of npm packages stale >12 months; ~95% of new OSS projects abandoned within a year) are the quantitative backdrop for this claim. > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — Composer 2.9's fatal-error-on-install behavior is a directly relevant, adoptable control for WordPress/PHP-ecosystem repos. > [!example] Fiction & Worldbuilding > None. > [!quote] Vocabulary > - **Provenance certificate** — a cryptographic record generated at release time attesting to a package's source repo, commit, and build system. > - **SBOM** — Software Bill of Materials; a machine-parsable inventory of every dependency, exportable from GitHub's Insights tab. > - **Cooldown / min-release-age** — a defensive setting that blocks installing a dependency version until it's reached a minimum age, preventing auto-merge of a just-published malicious release. > - **Transitive dependency** — a dependency of a dependency; invisible to a team unless explicitly analyzed. ## Bib capsule Jonathan (WordPress-adjacent security speaker), "Software Supply Chain Security in the Age of AI," WordCamp US 2026 talk. https://www.youtube.com/watch?v=B-LpjJZdDGg — walks through two 2026 npm worm attacks (Axios, Tanstack) and the practical layered defenses (SBOMs, lock files, Composer/npm audit-on-install, GitHub Actions hardening, cooldown windows) available today. ## Author's thesis **Q1 (what's the talk about):** Why software supply chain attacks are accelerating in frequency and sophistication, and what practical, adoptable defenses exist right now. **Q2 (how does it develop that):** Jonathan centers two 2026 npm worm-style attacks (Axios, Tanstack) as case studies showing attackers now self-propagate via stolen CI tokens rather than phishing, then walks the mechanics of transitive dependencies, SBOMs, abandonment, lock files, and GitHub Actions hardening as the layered, individually-imperfect mitigations available today — closing on a cultural argument that dependency hygiene needs to become a standing team practice, not an occasional fire drill. ## Key arguments 1. AI now pollutes the supply chain independent of any attacker — 27% of 36,000 examined LLM-generated upgrade recommendations referenced non-existent package versions. 2. 2026's worm-style attacks are qualitatively different: they self-propagate using stolen CI/publish access rather than phished credentials, and in Tanstack's case shipped with forged-but-validly-signed provenance certificates — defeating a control built specifically to prevent that class of attack. 3. No single tool closes the gap; the practical response is a layered stack (lock-file enforcement, Actions hardening, cooldown windows, SBOM visibility) paired with a cultural shift making dependency hygiene a shared, standing responsibility. ### Worm attacks now ship with forged validly-signed provenance > [!quote] ID:rw_atom1 > What was unique about this attack was that these forged packages all carried valid signed Providence certificates. The Tanstack case study's most consequential detail — a security control designed to prevent exactly this class of attack was itself defeated, not bypassed. ### AI recommends nonexistent package versions at scale > [!quote] ID:rw_atom2 > across 36,000 upgrade recommendations made by LLMs that they examined, over 27% were referencing non-existent versions Early scale-setting statistic (Sonatype) — quantifies AI's supply-chain-degrading effect as friction/breakage, independent of any malicious actor. ### Tanstack's attack chained CI bugs not stolen credentials > [!quote] ID:rw_atom3 > The attack succeeded without stealing any credentials or fishing any maintainers. Instead, it chained together three different GitHub actions bugs and it was able to hijack an authentication token directly out of the continuous integration container. The case study's core mechanism — the "don't get phished" defense model no longer covers this attack class. ### Composer 2.9 now fatally blocks installs with known vulnerabilities > [!quote] ID:rw_atom4 > Composer will perform that same analysis, but it will return a fatal error and it will not install anything. Directly relevant to WordPress/PHP-ecosystem repos — a concrete, adoptable-today control with a clear before/after (warning → hard fail). ### Cooldown windows delay installing a just-published version > [!quote] ID:rw_atom5 > npm you can use something called min release age in your npmrc file which instructs npm how to behave. A defensive pattern preventing the "PR opens, gets auto-merged 5 minutes after a malicious release" failure mode described earlier in the talk. ## Permanent candidates - **rw_atom1** (forged, validly-signed provenance) — not promoted; the general mechanism — a trust control that closes one gap still leaves every other trust dependency (here, CI-level publish access) exactly where it was — is already the exact claim of the existing [[3. Resources/Permanent Notes/Signing Narrows Trust to the Build System, It Doesn't Eliminate It]]. This talk's Tanstack incident is added there as a second concrete instance rather than duplicated as a new note. - **rw_atom2, rw_atom4, rw_atom5** — concrete, useful facts/tool behaviors, but not independently generalizable claims; retained as claim atoms only. - **Net result: 0 Permanent Notes from this source** — resonance filter applied; the one candidate that would generalize duplicates an existing note. ## Processing checklist - [x] Checked for existing Literature Note — none found for this talk. - [x] Checked for existing Permanent Notes — [[3. Resources/Permanent Notes/Signing Narrows Trust to the Build System, It Doesn't Eliminate It]] already covers the strongest candidate claim (provenance/signing narrows but doesn't eliminate trust dependency); no new Permanent Note created. - [ ] Registered in MOC(s) — orchestrator to add to [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] (primary: Composer 2.9, Actions hardening, cooldown windows) and [[3. Resources/MOCs/Open Source Governance MOC]] (secondary: package abandonment / maintainer-attention scarcity statistics). ## Links - [[3. Resources/Literature Notes/What's in Your AI — The Case for AI Bills of Materials (Alan Friedman, RSAC)]] — because these are two 2026 talks on the same problem; compare what each treats as the binding constraint.