Software Supply Chain Security in the Age of AI  🔗 **Source:** [Software Supply Chain Security in the Age of AI](https://www.youtube.com/watch?v=B-LpjJZdDGg#transcript) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > --- > tags: [software-supply-chain, npm-security, ai-hallucinated-packages, github-actions-hardening, dependency-management, wordpress-security] > author: Jonathan > source: WordCamp US 2026 > reference: https://www.youtube.com/watch?v=B-LpjJZdDGg > date created: 2026-08-19 > > --- > > # 🏷️ Title: Software Supply Chain Security in the Age of AI > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [npm registry](https://www.npmjs.com/) — package registry discussed throughout - [Packagist / Composer](https://getcomposer.org/) — PHP package registry and CLI tool discussed for WordPress ecosystem - [Sonatype State of the Software Supply Chain report](https://www.sonatype.com/state-of-the-software-supply-chain) — source of the LLM-hallucinated-version and other statistics cited - [Snyk](https://snyk.io/) — source of the "61% of npm packages unreleased in 12 months" abandonment statistic - [Zizmor](https://woodruffw.github.io/zizmor/) — static analysis tool for GitHub Actions workflows demoed in the talk - [GitHub Dependabot](https://docs.github.com/en/code-security/dependabot) — referenced for update PRs and cooldown/min-release-age configuration - Log4Shell (CVE-2021-44228) — cited as the canonical abandoned/legacy-vulnerability example ## 📝 Summary - **What happened:** Jonathan (a WordPress core-adjacent security speaker) gave a WordCamp US 2026 talk arguing that software supply chain attacks are accelerating in frequency and sophistication because of AI, using two 2026 worm-style npm attacks — Axios (March) and Tanstack (May) — as centerpiece case studies, then walked through the mechanics of transitive dependencies, SBOMs, package abandonment, lock files, and GitHub Actions hardening as the practical defenses available today. - **Why it matters:** The talk reframes supply chain risk as a systemic, cultural problem rather than a one-off patching exercise. Its most consequential claim is that AI is now attacking *and* defending on both sides — AI coding assistants recommend non-existent package versions at meaningful scale (27% of examined recommendations per Sonatype), while attackers use AI-accelerated tooling to chain vulnerabilities (e.g., three chained GitHub Actions bugs in the Tanstack attack) faster than defenders can respond. - **Key stakeholders:** Package maintainers (individual and corporate), the WordPress project specifically (Core, Core Program Team, security team — WordPress Develop has ~5,000 dependencies, Gutenberg ~3,800), npm/Packagist registry operators, GitHub (Actions platform and Dependabot), enterprise security/AppSec teams who triage vulnerability notifications, and end users whose credentials/tokens are the ultimate attack target. - **Risks and tradeoffs:** Aggressive dependency trimming reduces attack surface but sacrifices battle-tested, expert-built code and adds maintenance burden to reimplement it in-house. Fatal-error-on-install behavior (Composer 2.9) improves security defaults but can break CI/CD pipelines outright if a vulnerability is a false positive for the specific codebase. Cooldown/min-release-age settings reduce zero-day exposure but delay legitimate urgent security patches. - **Bottom line:** No single tool closes this gap. The talk's throughline is that supply chain security is a portfolio of imperfect, layered mitigations (SBOMs, lock files, audit-on-install, Actions hardening, cooldown windows) combined with a cultural shift — treating dependency maintenance as everyone's ongoing job rather than a rare fire drill. ## 📖 Main Content ### 🗒️ Notes - **The scenario framing:** The talk opens with a guided-imagery exercise (eyes closed) walking the audience through three escalating vulnerability-notification scenarios — checking dependencies safely twice, then discovering on a Saturday that a package you *maintain* was exploited less than an hour after a researcher's disclosure, while you were at lunch. This sets up the core argument: reactive vulnerability response no longer scales against attack speed. - **Scale context:** Over 30,000 releases are published to npm daily (11 million total in 2025). Across four major registries, there were 9.8 trillion downloads in 2025. - **AI's dual role:** AI both accelerates defenders (recommendation tooling, Copilot-assisted dependency-update review) and actively degrades the supply chain — Sonatype's analysis of 36,000 LLM-generated upgrade recommendations found over 27% referenced non-existent package versions, including 10,000 fully hallucinated releases that would simply fail to resolve. Separately, AI lowers the bar for both writing vulnerable code and for attackers finding/exploiting it faster than maintainers can respond. - **Case study — Axios (March):** A postinstall script in a compromised release of the widely-used Axios JS HTTP client dropped a fully functional cross-platform remote access Trojan that harvested SSH keys, cloud provider tokens, and environment secrets, then deleted itself from `node_modules` to evade detection while remaining resident and capable of executing arbitrary shell commands on demand. Some security vendors detected exploitation in under 89 seconds after publish. - **Case study — Tanstack (May):** Tanstack (80–133M weekly downloads across ~200 npm packages) had 84 malicious releases published across 42 packages within a six-minute window. The payload harvested GitHub, npm, AWS, Kubernetes, and HashiCorp Vault tokens and was self-propagating — it used stolen publish tokens to inject itself into further packages the victim could publish to, spreading automatically. It also carried a destructive dead-man's-switch: a background process polling the stolen GitHub token every 60 seconds that wiped the user's entire home directory if that token was revoked (the standard incident-response action). The attack was pulled within 20–25 minutes but had already spread to 160 additional npm/PyPI packages. Initial access required no stolen credentials or phished maintainer — attackers chained three separate GitHub Actions bugs to hijack an authentication token directly out of a CI container. - **Forged provenance — the novel part:** Provenance certificates are cryptographic records generated at release time that attest to the source repository, commit, and build system, letting downstream consumers verify a package wasn't tampered with. The Tanstack-family attack is described as the first known supply chain worm to ship with *valid, signed* provenance certificates — defeating a control that was specifically designed to prevent this class of attack. - **Transitive dependencies as the core structural risk:** Direct dependencies (defined in a manifest like `package.json`) themselves have dependencies, which have dependencies — code from any of them can execute in your codebase, deployment pipeline, or local machine. These are mostly invisible to teams unless explicitly analyzed. Small-to-midsize JS projects commonly exceed 1,000 transitive dependencies; WordPress Develop has ~5,000 and Gutenberg ~3,800. - **SBOMs:** A Software Bill of Materials is a machine-parsable JSON inventory of every dependency, exportable directly from GitHub's Insights tab, enabling programmatic analysis rather than manual dependency-tree reading. - **Package proliferation and abandonment:** ~750,000 new packages were published to npm in 2025 alone, pushing the total past 5.6 million — but the speaker argues most recent growth is "synthetic" rather than organic (solving new problems), partly attributable to AI-assisted publishing. Snyk estimates 61% of all npm packages haven't had a release in 12 months (the common "abandoned" threshold); more broadly ~95% of new open source projects are abandoned within their first year. Applying the 61% abandonment rate as a rough proxy across 2025's 9.8 trillion total downloads yields an estimated 58.8 billion downloads of abandoned packages. Abandoned doesn't automatically mean insecure, but risk compounds with age — Log4Shell (fixed in 2021) still accounted for 13% of all downloads of that library being vulnerable versions in 2025. - **Lock files** are presented as the original, imperfect de facto defense: pinning exact resolved versions/hashes at install time for reproducibility, which incidentally blocks silently pulling newer (possibly compromised) versions. - **Composer 2.9 (WordPress/PHP ecosystem):** Since 2022, `composer audit` has flagged available security updates. As of Composer 2.9 (November), a detected vulnerability now causes a **fatal error that blocks installation entirely**, rather than just warning — a stronger secure-by-default posture, though it still depends on the vulnerability having been found, verified, and added to the advisory database, leaving a window of hours-to-days of exposure. Teams can mark a specific advisory as not-applicable to their codebase, but the recommended path is always upgrading. - **npm-side tooling:** `npm audit` / `npm audit fix`, `save-exact` (pins exact versions instead of ranges), and `npm ci` (fails hard if the lock file doesn't exactly match, mirroring Composer's new behavior) versus plain `npm install` (silently regenerates the lock file and can pull vulnerable transitive versions). npm 11.5 added "install changed" warnings; npm 12 will disable install scripts by default — the exact mechanism that made the Axios and Tanstack postinstall payloads possible. - **GitHub Actions hardening:** Demonstrated live with Zizmor, a static analyzer for Actions workflows. Key anti-patterns flagged: interpolating untrusted user input (e.g., a PR title) directly into a run step (template-injection risk — fix: pass through an env var so GitHub escapes it); referencing third-party Actions by mutable tag/branch instead of a full-length pinned commit hash; persisting checkout credentials/tokens unnecessarily; and overly permissive default `GITHUB_TOKEN` scopes (recommendation: zero out permissions at the top of every workflow, then explicitly grant only the ~20 available scoped capabilities a job actually needs). GitHub Actions is called out as one of the most common vectors for token/key exposure specifically, separate from registry-package compromise. - **Cooldown / min-release-age:** A defensive pattern where you define a minimum age a dependency version must reach before your tooling will install it (npm: `min-release-age` in `.npmrc`; also configurable in Dependabot), preventing the "PR opens, gets auto-merged 5 minutes after a malicious release" failure mode. - **Cultural argument:** The talk closes by reframing dependency/supply-chain health as a shared team responsibility rather than an individual or one-time task, comparable to ongoing maintenance rather than a fire-and-forget install. It also encourages active dependency reduction during routine updates (using AI-assisted PR review to ask whether an update is even needed, or whether a dependency can be consolidated/removed) — while acknowledging that fewer dependencies also means less battle-tested code and more owned technical debt. - **Q&A themes:** (1) How to avoid alert fatigue from mostly-irrelevant npm vulnerability notifications — speaker's answer: use AI-assisted Dependabot PR triage to add context/actionability, and normalize checking updates weekly across the team rather than batching monthly. (2) What to do if you hit a destructive package (home-directory wipe) — isolate/wipe the affected machine, lean on the open source community and security researchers who often respond within minutes, and escalate to the registry or GitHub if the package is large enough to warrant coordinated response. (3) Why vulnerable old package versions still exist and get reinstalled — registries are reluctant to hard-delete old versions because it breaks everything depending on them; responsibility functionally shifts to consumers to track updates, though the WordPress.org GitHub org is piloting an org-wide required workflow (moving toward an org-wide Zizmor scan) to catch these patterns automatically across all repos. ## 📚 References - Sonatype, *State of the Software Supply Chain* (annual report) — https://www.sonatype.com/state-of-the-software-supply-chain - Snyk abandonment/package-health research — https://snyk.io/ - Zizmor (GitHub Actions static analyzer) — https://woodruffw.github.io/zizmor/ - npm Blog / release notes for npm 11.5–12 (install-changed warnings, install-scripts default change) — https://blog.npmjs.org/ - Composer 2.9 release notes (fatal-error audit-on-install behavior) — https://getcomposer.org/ - Log4Shell / CVE-2021-44228 — https://logging.apache.org/log4j/2.x/security.html - GitHub Docs, Dependabot version updates / cooldown — https://docs.github.com/en/code-security/dependabot ## 🗣️ Paraphrase - The opening scenario paraphrases as: even a maintainer who diligently checks every vulnerability disclosure can still be blindsided, because attack-to-exploitation timelines have compressed to minutes, and normal life (a Saturday lunch) is enough of a gap for real damage. - The scale/AI section paraphrases as: AI isn't just a new attack surface, it's actively polluting the dependency-resolution process itself through hallucinated package versions, while simultaneously giving attackers better tooling to find and chain exploits. - The Axios/Tanstack case studies paraphrase as: 2026's worm-style attacks are qualitatively different from prior credential-theft incidents — they self-propagate using stolen publish rights, carry destructive fail-safes, and (in Tanstack's case) exploited CI pipeline weaknesses rather than any human error, meaning "don't get phished" is no longer sufficient defense. - The provenance-certificate section paraphrases as: a control built specifically to let you trust a package's origin was itself forged with valid signatures — meaning provenance alone is necessary but not sufficient, and the trust chain further upstream (how tokens/CI credentials get provenance signing rights in the first place) is the real thing that needs hardening. - The transitive-dependency/SBOM/abandonment sections paraphrase as: most of the actual attack surface is invisible by default (transitive graphs, unmaintained packages nobody remembers depending on), so the practical fix is making that surface visible and parsable (SBOMs, GitHub Insights) rather than relying on manual awareness. - The tooling section (lock files, Composer 2.9, npm audit/ci, Zizmor, cooldowns) paraphrases as: each individual control is leaky on its own — lock files require diligence, audit tools flag mostly-irrelevant findings, hard-fail-on-install can break builds, Actions hardening requires manually revisiting every workflow — but stacked together and paired with a cooldown window, they meaningfully narrow the exploitable window. - The closing cultural argument paraphrases as: tooling alone won't fix this because no single person or team currently owns transitive-dependency risk; it has to become a default team practice, similar to how code review or testing became normalized, not an occasional security-team task. ## 📰 Newsletter Two 2026 npm worm attacks (Axios in March, Tanstack in May) turned "check your dependency tree" into "assume something in it is already compromised." In a WordCamp US talk, a WordPress-adjacent security speaker walked through how Tanstack's malware chained three separate GitHub Actions bugs to steal a CI token — no phishing, no leaked password required — then self-propagated using that stolen publish access, complete with forged-but-*validly-signed* provenance certificates and a destructive dead-man's-switch that wiped home directories if its stolen GitHub token got revoked. For the WordPress ecosystem specifically (WordPress Develop: ~5,000 dependencies; Gutenberg: ~3,800), the practical takeaways are concrete: Composer 2.9 now hard-fails installs on known vulnerabilities instead of just warning; `npm ci` and `save-exact` close the "silent lock-file regeneration" gap that `npm install` leaves open; Zizmor will catch the classic GitHub Actions anti-patterns (unpinned Action versions, unescaped PR-title interpolation, over-permissive default tokens) before they ship; and cooldown/min-release-age settings buy time before a zero-day-fresh release can auto-merge into your pipeline. None of these are silver bullets — the talk's real ask is cultural: make dependency and Actions hygiene a standing team habit, not a once-a-quarter fire drill. ## ✅ Action Items #### DevRel - Developer advocacy: Build a WordCamp/meetup talk or workshop series specifically walking maintainers through Zizmor + Composer 2.9 audit-on-install + npm ci adoption, with before/after workflow diffs. - Education: Publish a short internal runbook for "what to do in the first hour of a supply chain compromise notification" based on the talk's Q&A guidance (isolate machine, check security-vendor writeups, escalate to registry/GitHub if package is large). - Developer experience: Provide a starter Zizmor GitHub Actions config and a Dependabot cooldown/min-release-age config snippet as copy-paste templates for WordPress plugin/theme repos. - Developer marketing: Amplify the Axios/Tanstack case studies (with attribution) as cautionary examples in developer-facing security content. - Community management: Track recurring "why do I keep getting flagged for irrelevant npm CVEs" complaints (raised directly in the Q&A) and route to a shared triage FAQ. - Internal/external/cross-project: Coordinate with the WordPress.org GitHub org's in-progress org-wide required-workflow effort (Zizmor-across-all-repos) mentioned in Q&A, rather than duplicating it per-plugin. #### OSPO - Policy & Governance: Draft a minimum-viable supply chain policy for owned repos: lock-file enforcement (`npm ci` / Composer install without `--ignore-platform-reqs`), pinned Action SHAs, zeroed default permissions. - License Compliance: Not directly addressed in this source — no license-specific claims were made; treat as out of scope for this talk. - Security Management: Formalize an SBOM-generation step (GitHub Insights export or equivalent) in CI for every actively maintained repo. - Software Inventory: Establish an owner/freshness SLO per dependency category, informed by the abandonment statistics cited (61% of npm packages stale >12 months). - Developer Support: Offer office hours or a Slack channel for teams adopting Composer 2.9's fatal-error install behavior, since it can break CI without warning on first rollout. - Community Engagement: Consider funding or upstream contribution to Zizmor or provenance-verification tooling given how directly this talk's central incident (forged-but-signed provenance) exposes a gap in that space. - Strategic Alignment: Add "% of repos with pinned Action SHAs" and "% of repos with cooldown configured" as trackable KPIs. #### Community - Maintainers: Circulate the cooldown/min-release-age and `npm ci` / Composer 2.9 guidance to plugin/theme maintainers as a low-effort, high-leverage change. - Contributors: Add "review this PR against Zizmor findings" as a first-issue-friendly onboarding task. - Sponsors: Not directly addressed in this source. - Ecosystem: Propose a coordinated-disclosure/incident-drill exercise modeled on the Tanstack timeline (six-minute propagation window) to pressure-test response speed. #### WordPress - Core: Track the WordPress.org GitHub org's stated multi-repo Zizmor rollout (referenced directly in the Q&A) and confirm it covers wp-cli/plugin-review-adjacent repos too. - Core Performance: Not directly addressed in this source. - Core AI: Given the 27%-hallucinated-version statistic, add a check step for any AI-assisted dependency-update tooling used internally to verify recommended versions actually resolve before merging. - **Core Program Team:** Coordinate the org-wide Actions-hardening rollout mentioned in Q&A as a tracked cross-repo initiative with a completion dashboard. - Mobile: Not directly addressed in this source. - Playground: Consider a Playground-based reproducible demo of the Axios/Tanstack attack mechanics (sandboxed) for education purposes. - Community: Feed this talk's content into WordCamp organizer talk-topic suggestions for regional events lacking a supply-chain-security session. - Training: Build a Learn WordPress course module on SBOMs, lock files, and Composer 2.9 behavior specifically for plugin/theme developers. - Marketing: Not directly addressed in this source. - Support: Prepare a support-team FAQ for "why did my site break after a Composer update" given the new fatal-error-on-audit-failure behavior. - Design: Not directly addressed in this source. - Documentation: Add a DevHub/HelpHub page on GitHub Actions hardening (Zizmor, pinned SHAs, zero-trust permissions) referencing this talk's demonstrated anti-patterns. - Photos: Not directly addressed in this source. - TV: Publish this talk's WordCamp recording with accurate chaptering/captions once available via WordPress.tv. - Polyglots: Not directly addressed in this source. - Accessibility: Not directly addressed in this source (see Accessibility Assessment section below for the talk's own presentation accessibility, which is distinct from this action item). - Meta: Evaluate whether .org's own plugin/theme review tooling could surface transitive-dependency SBOM data to reviewers. - CLI: Evaluate adding a `wp` CLI subcommand or plugin-scaffold default that wires up `npm ci`/`composer install --no-scripts`-equivalent safe defaults. - Hosting: Share the Composer 2.9 fatal-error behavior change with hosting partners so their deploy pipelines don't silently fail without diagnostic messaging. - Tide: Cross-reference Tide's existing scoring with the SBOM/dependency-freshness signals discussed here. - Openverse: Not directly addressed in this source. - Themes: Extend theme review guidelines to check for pinned build-tool dependency versions. - Plugins: Extend plugin review guidelines to flag unpinned GitHub Actions in bundled CI configs and unreviewed postinstall scripts. #### The WPOCC - Programs: Consider a microgrant/stipend track specifically for maintainers doing supply-chain hardening work (Actions pinning, SBOM adoption) across widely-depended-upon WordPress-ecosystem packages. - Projects: Sponsor a governance clinic on "who owns transitive dependency risk" given the talk's explicit point that no one currently feels accountable for these upgrades. - Funding experiments: Explore matched-grant funding for maintainers of high-download, low-maintenance-capacity packages identified via the abandonment statistics cited. ### FAIR - Technical independence: The forged-but-validly-signed provenance certificate incident is directly relevant to FAIR's emphasis on local/independent provenance verification — treat as a case study for why provenance checks can't rely solely on the signing chain being intact. - Policies and covenants: Not directly addressed in this source. - Productized governance artifacts: Consider adapting the talk's GitHub Actions hardening checklist (zero-trust permissions, pinned SHAs, Zizmor) into a FAIR operator-agreement scorecard item. ## 🧪 Hypotheses 1. Repos that adopt `npm ci` / Composer 2.9's audit-on-install behavior will show measurably fewer post-deploy vulnerable-dependency incidents than repos relying on `npm install` / manual `composer audit` alone. 2. Pinning GitHub Actions to full-length commit SHAs (versus tag/branch references) meaningfully reduces the incidence of supply-chain-sourced token exfiltration in CI, independent of other hardening steps. 3. Teams that adopt a cooldown/min-release-age window (e.g., 24–72 hours) will show lower exposure to "zero-day-fresh" malicious releases than teams merging Dependabot PRs on a fixed schedule without a delay. 4. AI-assisted dependency-update review (e.g., Copilot-prompted PR analysis) reduces total dependency count over time relative to teams doing manual dependency review, without a corresponding increase in build breakage. 5. Packages with valid provenance certificates are not meaningfully less likely to be compromised than packages without them, once an attacker has legitimate CI-level publish access — i.e., provenance verifies origin, not trustworthiness of the origin's access controls. 6. The rate of AI-recommended non-existent package versions (currently ~27% per Sonatype) will decline as coding-assistant tooling adds live registry-resolution checks, but will not reach zero without such a check being made mandatory rather than optional. ### 📊 Methodology - **H1/H3 (audit-on-install / cooldown effectiveness):** A retrospective cohort study across public GitHub/GitLab repos, comparing security-incident rates (via GitHub Security Advisories or Dependabot alert-to-remediation timelines) between repos with `npm ci`/Composer 2.9-equivalent enforcement vs. without, controlling for repo size and update cadence. - **H2 (Actions SHA pinning):** A controlled analysis of publicly disclosed CI-token-exfiltration incidents, coding each incident's root cause (unpinned Action, over-permissive token, etc.) against whether the affected workflow used SHA pinning, sourced from GitHub Security Lab / Zizmor's own incident database if one exists. - **H4 (AI-assisted dependency review):** A before/after study on a sample of repos adopting the Copilot-prompted dependency-review pattern described in the talk, tracking dependency count and CI failure rate over a 6-month window. - **H5 (provenance vs. compromise likelihood):** A comparative incident analysis of npm/PyPI packages with and without provenance attestation, examining whether provenance presence correlates with lower compromise rates or is orthogonal once CI-level access is the attack vector (as in Tanstack). - **H6 (hallucinated-version decline):** A longitudinal repeat of Sonatype's methodology (sampling LLM-generated upgrade recommendations against actual registry state) run annually to track the 27% baseline over time as tooling changes. ### ❓ Questions - What proportion of the "90–95% of flagged vulnerabilities are not actually relevant" figure (cited in Q&A) is attributable to dev/local-only tooling versus genuinely low-severity issues in production paths? - Given that registries won't hard-delete old vulnerable versions (because it breaks dependents), is there a viable middle path — e.g., a registry-level "quarantine" state that requires explicit opt-in to install a known-vulnerable version? - How does the WordPress.org org-wide required-workflow effort (mentioned in Q&A) plan to handle repos maintained by third-party plugin/theme authors who don't opt into WordPress.org's own CI conventions? - Could provenance certificate issuance itself require a secondary, harder-to-steal attestation (e.g., hardware-backed signing) specifically because this attack demonstrated that CI-level token theft is sufficient to forge a "valid" one? - Is there a practical way to make transitive-dependency ownership assignable (per the talk's point that "no single person or team ever feels accountable") without creating a bottleneck role that itself becomes a burnout risk? ### 🔮 Future Research - Empirical study of cooldown-window length vs. security benefit vs. patch-delay cost, to find a defensible default recommendation (the talk mentions the mechanism but not a specific recommended duration). - Research into detecting self-propagating worm behavior in CI *before* publish, rather than relying on post-publish detection speed (the talk notes some vendors caught Axios in under 89 seconds, but that's still after exploitation began). - Investigation of whether "AI reviews AI's own dependency-update recommendations" creates a meaningful check, or whether shared training-data blind spots make it circular. - Study of maintainer burnout specifically correlated with supply-chain security burden (abandonment stats suggest a link, but the talk doesn't quantify it directly). ### 💡 Implications - **Practice:** Teams should treat lock-file enforcement (`npm ci`, Composer's new default) and Actions SHA pinning as baseline hygiene, not advanced security work, given how directly they map to this year's actual incidents. - **Policy:** Organizations (including WordPress.org, per the Q&A) are moving toward org-wide *mandatory* workflows rather than per-repo opt-in, which has governance implications for who can override or exempt a repo. - **Security:** Provenance/signing infrastructure needs a threat model that assumes CI-level access can be stolen, not just that the signing keys themselves are safe — the "valid signature" framing needs public recalibration. - **Education:** The talk models a specific instructional technique (guided-imagery scenario framing) worth studying as a device for security awareness training generally. - **Funding models:** The abandonment/synthetic-growth statistics strengthen the case for funding maintainer sustainability (stipends, microgrants) as a security investment, not just a goodwill gesture. ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 10–11 (formula: 0.39 × avg words/sentence + 11.8 × avg syllables/word − 15.59), reflecting long, run-on spoken sentences with moderate technical vocabulary (transitive dependencies, provenance, SBOM) that a general developer audience would follow but a non-technical reader would not. #### 👀 Visual learners - Present: The live demo (Zizmor scanning an actual workflow file, GitHub Insights dependency tab, SBOM export button) are described in the transcript but not reproduced as images/diagrams in this text-only capture. - Improve: Add an architecture diagram showing the Tanstack attack chain (CI bug → token theft → self-propagation → destructive trigger) and a before/after screenshot pair of the flagged GitHub Actions anti-pattern and its fix. #### 🔊 Aural learners - Present: This source *is* the audio/video talk itself — full narration, live Q&A exchange. - Improve: A 2–3 minute audio-only summary extracting just the Axios/Tanstack case studies and the concrete fixes would serve time-constrained listeners. #### 🗣️ Verbal learners - Present: The talk defines key terms in plain language as it introduces them (supply chain attack, transitive dependency, SBOM, provenance). - Improve: A glossary sidebar (SBOM, provenance, cooldown, lock file, transitive dependency) would help readers who skip to specific sections. #### 🧩 Kinesthetic learners - Present: The Zizmor demo and GitHub Insights/SBOM-export walkthrough are hands-on-tool demonstrations. - Improve: A companion "try it yourself" checklist (run Zizmor on your own workflow, export your own SBOM, check your `.npmrc` for `min-release-age`) would convert the demo into a repeatable exercise. #### 🧠 Logical learners - Present: The talk builds a clear causal chain (AI lowers cost of attack + lowers cost of hallucinated trust → more sophisticated worms → existing tools only partially mitigate → cultural fix required). - Improve: A decision-tree or RACI table for "who owns this dependency risk and when do they act" would formalize the talk's closing cultural argument into something actionable. #### 🧑‍🤝‍🧑 Social learners - Present: The live Q&A segment itself is a social-learning artifact — three audience questions extend and pressure-test the talk's claims. - Improve: A moderated discussion guide for teams to work through the Q&A questions together (e.g., "how would we respond to a home-directory-wipe payload") would extend this into a workshop format. #### 🧘‍♀️ Solitary learners - Present: The talk is structured as a linear narrative that a solitary reader/listener can follow start to finish without external interaction. - Improve: Self-check questions after each major section (e.g., "can you name your project's top 3 transitive-dependency risks?") would support self-paced reflection. #### 🌿 Naturalistic learners - Present: The talk implicitly uses an ecosystem metaphor (packages "live under the water," abandoned packages "collect dust," "help lift the boat with the rising tide"). - Improve: Explicitly extending the ecosystem/food-web metaphor (e.g., mapping dependency graphs to trophic levels) could make the systemic-risk argument more intuitive for this learner type. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: The Reader-scraped transcript is plain paragraph text with no heading structure of its own (single continuous talk transcript). - Improve: The notes document (this file) adds semantic headings; the source video itself would benefit from chapter markers aligned to major topic shifts (case studies, tooling sections, Q&A) for screen-reader and keyboard chapter navigation on YouTube. #### Keyboard navigation - Present: Not directly assessable from a transcript-only capture; YouTube's native player provides standard keyboard controls. - Improve: Chapter markers (see above) would let keyboard users jump directly to sections like "Zizmor demo" or "Q&A" without scrubbing. #### Contrast and readability - Present: Not applicable — this source is video/audio; no on-screen text contrast was captured in the transcript-only fetch. - Improve: If slides are reused as a blog post or deck, ensure code snippets and terminal output maintain 4.5:1 contrast in both light and dark themes. #### Text resizing and reflow - Present: Not applicable to a video source; addressed at the platform (YouTube) level, not the content level. - Improve: Not applicable to this source. #### Media and captions - Present: This document itself was created specifically because the video's auto-captions were fetched via vidIQ transcript API (not YouTube's own scrape) after an IP-block prevented normal caption retrieval — indicating captions do exist for the source video. - Improve: A human-reviewed transcript (correcting mis-transcribed terms like "Sonotype" for "Sonatype," "Hashior" for "HashiCorp," "Log forj" for "Log4j," and "Zismore"/"more" for "Zizmor" throughout) would materially improve both accessibility and searchability. This notes document does not silently correct the source transcript's mis-hearings within its own body text below, but flags them here. #### Forms and interactions - Present: Not applicable — no forms/interactive elements in a talk recording. - Improve: Not applicable to this source. #### Standards reference - Gaps map primarily to WCAG 2.2 AA success criteria 1.2.2 (Captions - Prerecorded, met via auto-captions but with accuracy gaps), 2.4.5/2.4.10 (navigable sections, not met — no chapters), and 3.1.2 (Language of Parts, not applicable — single-language talk). ### 🌍 DEIB Assessment #### Cultural breadth - Present: The talk's examples are drawn primarily from the JavaScript/npm and WordPress/PHP ecosystems, with a global-scale framing (registry download counts, worldwide package counts) rather than region-specific examples. - Improve: Including examples from non-Western package registries or maintainer communities (e.g., regional open-source foundations) would broaden the cultural frame beyond the US/WordPress-core-centric Q&A audience. #### Inclusive language - Present: The speaker uses accessible, jargon-defined language throughout and avoids gendered or exclusionary phrasing; the opening scenario uses "you" and non-specific family/pet framing that doesn't assume a particular household structure. - Improve: A few idioms ("lift the boat with the rising tide," "battle-clad") could be flagged for non-native-English-speaker audiences and paired with plainer alternatives in written derivatives. #### Neurodiversity support - Present: The talk uses a structured narrative arc (scenario → data → case studies → defenses → culture → Q&A) that is broadly predictable. - Improve: The opening guided-imagery/eyes-closed exercise may be uncomfortable or inaccessible for some neurodivergent or sensory-sensitive audience members; an opt-out framing ("follow along or just read the next slide") would be more inclusive. #### Representation - Present: The Q&A shows a range of audience members engaging (three distinct questioners), though names/identities aren't captured in this transcript. - Improve: Not enough information in the transcript alone to assess presenter/audience representation further; would need visual/video review. #### Psychological safety - Present: The speaker explicitly normalizes not knowing the answer ("this is uncharted territory," "I hope that's helpful") and treats audience questions charitably, including one questioner admitting to "poor practice" (reinstalling old packages) without any shaming in the response. - Improve: None specifically needed; this section already models good psychological-safety practice for a technical Q&A. ### ✅ Logical Validity #### Strong reasoning - **Causal chain (strong):** The Tanstack case study is presented with a clear, specific causal chain (three chained Actions bugs → CI token theft → self-propagation via stolen publish rights → destructive trigger on token revocation) rather than a vague "AI made attacks worse" claim — this is a well-evidenced example supporting the broader thesis. - **Inductive generalization (moderate-strong, appropriately hedged):** The move from "61% of npm packages are stale" to "therefore an estimated 58.8 billion downloads were of abandoned packages" is explicitly flagged by the speaker as "not an exact science" and an illustrative exercise, not a rigorous statistic — this hedging is a mark of intellectual honesty that strengthens rather than weakens the argument. #### Fallacies - **Hasty generalization (mild, self-corrected):** The claim that "most of the recent growth is not organic... it's mostly synthetic growth" is asserted without a cited source or methodology in the transcript, unlike the Sonatype/Snyk-attributed statistics elsewhere in the talk. *Location:* the SBOM/package-proliferation section. *Fix:* attribute this specific claim to a named source or explicitly label it as the speaker's own inference, consistent with how the talk sources its other statistics. - **False dilemma risk (mild):** The framing "we have to assume that everybody's using AI and we also have to assume that everybody's using it poorly" risks collapsing a spectrum of AI-usage quality into a binary. *Location:* the "how can we prevent this" transition section. *Fix:* soften to "assume some non-trivial share of maintainers are using AI without security review" to avoid implying universal poor practice. #### Tone of voice - Conversational, self-deprecating, and audience-inclusive (jokes about who fell asleep during the guided-imagery opener), shifting to matter-of-fact and data-driven in the statistics sections, and collegial/non-defensive in the Q&A — consistent with a practitioner sharing hard-won operational knowledge rather than a vendor pitch. ### 🛡️ DARVO Analysis Not applicable to this source — DARVO (Deny, Attack, Reverse Victim/Offender) analysis is designed to detect deflection patterns in accounts of interpersonal or institutional wrongdoing. This talk is a technical security presentation with no accusation being deflected; the speaker discusses attackers and vulnerabilities in third person without any personal or organizational culpability at stake. ## 🎯 Conclusion - **Bottom line:** Supply chain attacks in 2026 are faster, more automated, and increasingly capable of defeating trust mechanisms (forged-but-valid provenance) that were built specifically to prevent them — and AI is accelerating both the attack side (exploit chaining, hallucinated trust signals) and, unevenly, the defense side (AI-assisted dependency review). No single tool fixes this; the practical response is a layered stack of lock-file enforcement, Actions hardening, cooldown windows, and SBOM visibility, backed by a cultural shift that makes dependency hygiene a standing team responsibility rather than an occasional fire drill. - **Practical next steps for readers:** (1) Turn on `npm ci` / Composer 2.9's fatal-error audit behavior in CI. (2) Run Zizmor against every GitHub Actions workflow and pin third-party Actions to full commit SHAs. (3) Zero out default `GITHUB_TOKEN` permissions and grant only what each job needs. (4) Configure a cooldown/min-release-age window in npm/Dependabot config. (5) Export an SBOM for every actively maintained repo and assign an owner to review it periodically. (6) Treat AI-recommended dependency versions as unverified until confirmed against the actual registry. ## 🔄 Refactor Appendix — Software Supply Chain Security in the Age of AI > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Worm attacks now ship with forged, validly-signed provenance > [!quote] ID:rw_wcus2026-01 > "What was unique about this attack was that these forged packages all carried valid signed Providence certificates." **Context & use**: - From the Tanstack/provenance section of the talk, discussing the May npm worm. - Matters because it shows a security control (provenance) can be technically valid while still being attacker-controlled if CI-level publish access is compromised — trust-the-signature is not sufficient on its own. **Tags**: #xref **Highlight**: [view highlight](readwise://doc/01m0czwet92er2geh36bgy1z02) <!-- atomicity: 1 idea ✓ --> #### [H2] AI recommends nonexistent package versions at scale > [!quote] ID:rw_wcus2026-02 > "across 36,000 upgrade recommendations made by LLMs that they examined, over 27% were referencing non-existent versions" **Context & use**: - From the Sonatype-report section early in the talk. - Matters because it quantifies AI's supply-chain-degrading effect independent of any malicious actor — this is friction/breakage, not just security risk. **Tags**: #xref **Highlight**: [view highlight](readwise://doc/01m0czwet92er2geh36bgy1z02) <!-- atomicity: 1 idea ✓ --> #### [H3] Composer 2.9 now fatally blocks installs with known vulnerabilities > [!quote] ID:rw_wcus2026-03 > "when someone attempts to install packages, Composer will perform that same analysis, but it will return a fatal error and it will not install anything." **Context & use**: - From the Composer/lock-file tooling section, directly relevant to WordPress/PHP ecosystem repos. - Matters as a concrete, adoptable-today control with a clear before/after (warning → hard fail). **Tags**: #xref #share **Highlight**: [view highlight](readwise://doc/01m0czwet92er2geh36bgy1z02) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Provenance verifies origin, not the origin's access control **Claim** (one sentence, Courtney's voice): A provenance certificate proves a package build came from a specific repo/commit/system, but it says nothing about whether the credentials that produced that build were stolen. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds whenever CI-level publish access itself is the attack vector (as in the Tanstack case); doesn't hold for attacks that bypass CI entirely (e.g., a compromised maintainer's local machine directly publishing) — provenance would correctly flag those as anomalous if the local machine differs from the registered CI system. **Links** (≥1 with annotation): - [[Zero-trust CI permissions]] — because extends (the fix for stolen-CI-token attacks is scoping what a token can do, not just verifying what it signed) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether npm/PyPI have published or are drafting a hardware-backed or multi-party provenance-signing scheme in response to the Tanstack-style forged-provenance attack — WCUS2026 Jonathan talk #xref - [F2] Look up whether WordPress.org's org-wide Zizmor rollout (mentioned in Q&A) has a public tracking issue or dashboard — #xref ### → Things 3 (max 2 actions) - [ ] Confirm whether Zizmor is already running against WPOCC/personal-maintained repo GitHub Actions workflows — #things - [ ] Check personal/maintained npm or Composer projects for `npm ci`/Composer 2.9 audit-on-install adoption status — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Software Supply Chain Security in the Age of AI.md|Software Supply Chain Security in the Age of AI by Jonathan]] ## Highlights - There's a security company Sonotype that publishes a state of the software supply chain report every year. And I was looking through that report while preparing for my talk. I'll reference that a few times throughout with some numbers that kind of stood out to me uh in the context of this talk. The first one was that across 36,000 upgrade recommendations made by LLMs that they examined, over 27% were referencing non-existent versions. And that included 10,000 of them that hallucinated package releases that would result in commands never resolving. So AI is not just stressing and polluting our supply chain, it's breaking it and slowing us down. Attackers are using AI to find and exploit weaknesses faster than defenders can respond. This is especially true in open source where contributor and maintainer time is very limited. And a single compromised AI dependency can cascade across thousands of of different packages and organizations in a matter of minutes. ([View Highlight](https://read.readwise.io/read/01m0d09c68zvtv5h978k9bmb2e)) - Note: Sonatype: 27% of 36,000 LLM-generated upgrade recommendations referenced non-existent package versions; 10,000 fully hallucinated. - Tags: ai-hallucinated-packages, atom/literature/h2 - Tanstack is a popular open source application for the web and they receive over 80 133 million weekly downloads a week across their 200 different mpm packages. In May, attackers published 84 malicious releases across 42 of them within a six-minute window. Once installed, the payload would again harvest secrets for GitHub, mpm, AWS, Kubernetes, Hashior vault tokens. It was also self-propagating. It used the stolen tokens and it found other packages that the victim could publish to. It injected itself into those, spreading it automatically across the ecosystem. It also had a destructive trigger. There was a background process that pulled the stolen GitHub token and every 60 seconds if someone happened to revoke that token which is a standard response to um a token being exposed the entire user's home directory directory was completely wiped. This attack was removed within 20 to 25 minutes, but by then it had already spread across 160 additional MPM and Pippi packages. 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. ([View Highlight](https://read.readwise.io/read/01m0d09gf5s6mz7w78cat39atd)) - Note: Tanstack May 2026 attack: 84 malicious releases across 42 packages in 6 minutes, self-propagating via stolen tokens, destructive home-directory-wipe trigger, initial access via 3 chained GitHub Actions bugs. - Tags: atom/literature/h1, supply-chain-worm - In software, there is a concept called providence. A secure providence certificate is a cryptographic record that is generated automatically during a package release. And it verifies where the code came from, which repository, which commit, and even which system was responsible for producing it. It's meant to let anybody know that when they download that package, they can confirm that it wasn't tampered with and it was actually legitimate. What was unique about this attack was that these forged packages all carried valid signed Providence certificates. It was the first known supply chain attack uh that was a worm that was shipping with legitimate cryptographic signatures. ([View Highlight](https://read.readwise.io/read/01m0d09kp9anskgadkqp7y6sd6)) - Note: First known supply chain worm to ship with valid, signed provenance certificates — a control designed to prevent exactly this class of attack. - Tags: provenance, atom/literature/h1 - WordPress and the surrounding ecosystem generally depend on two package registries, mpm and packages. Packages is used for PHP dependencies and composer is a tool that's used to manage them. In 2022, Composer introduced a Composer audit command which will analyze your dependencies and tell you if there are available security updates. In November, Composer 2.9 changed this behavior. Now, when someone attempts to install packages, Composer will perform that same analysis, but it will return a fatal error and it will not install anything. It's a great way to short circuit things and keep people secure. But of course, this depends on action being taken. It's not foolproof or a full solution because it requires a vulnerability to be found, reviewed, verified, and eventually added to the vulnerability database. That potentially still leaves hours or even days between the vulnerable version being uh released and your machine or your pipeline installing it. And you can see here that I've gone and I've actually instead of you have two options. You can manually define a specific vulnerability as not relevant to your project. So perhaps you're not using the code or it's not affect it's not exploitable in your codebase. But of course the best way is to upgrade your dependencies. ([View Highlight](https://read.readwise.io/read/01m0d09qxpn3naqprm5y0bwdzc)) - Note: Composer 2.9 (Nov) changed audit-on-install from a warning to a fatal error that blocks installation entirely when a known vulnerability is detected. - Tags: atom/literature/h3, wordpress-ecosystem, composer - GitHub actions is also another really common way that uh projects are compromised. GitHub actions is a CI/CD platform where people can run tests, they can build their software, they can deploy it to servers or even publish releases to the package registries. By default, it's a very permissive environment and so there's often things that you must do to ensure that your actions remain secure. So here I have a file with a lot of antiatterns and it's going to go through and use a tool called Zismore. Zismore is a static analysis tool for GitHub actions workflows and it will flag all different kinds of vulnerabilities uh things that could potentially lead to vulnerabilities in your codebase. So here we have a simple workflow that's meant to um run our PHP unit tests. And in this case, this is very dangerous because this request pull request title is user controlled. And so by putting it there, we risk falling victim to a template uh injection attack. And this is more we'll flag that. And the fix for things like this is fairly simple. It's just to move that variable to an environment variable because then GitHub will actually escape that and ensure that it's a safe and secure value for you to use. Even though many of the recent vulnerabilities published has been package registries and not in GitHub actions. I would say that GitHub actions is probably one of the most common ways that tokens and keys are exposed in a way that attacker can grab it and use it to do other things. ([View Highlight](https://read.readwise.io/read/01m0d09v53x58whgn3apt25c9d)) - Note: Zizmor static analysis flags GitHub Actions anti-patterns like unescaped PR-title interpolation (template injection risk); fix is moving the value to an env var so GitHub escapes it. - Tags: atom/literature/h2, zizmor, github-actions-hardening - Another popular thing that we're seeing is something called a cooldown feature. So this is a way that you can define a minimum age that you uh you expect your dependencies to have before you're allowed to install them. So npm you can use something called min release age in your npmrc file which instructs npm how to behave. But then also if you have dependabot configured to monitor your dependencies for updates you can actually define that in here as well. So there's no more pull requests being opened and then accidentally merging something with a vulnerability. Uh you know, you happen to be in there, it was released, and 5 minutes later you have a PR that you just merge. ([View Highlight](https://read.readwise.io/read/01m0d09y44g3cqbp8bbnny6afs)) - Note: Cooldown / min-release-age: define a minimum age a dependency version must reach (npmrc min-release-age, or Dependabot config) before it can be installed, preventing auto-merge of a just-published malicious release. - Tags: atom/literature/h3, dependabot, cooldown