npm Provenance Attestations & SLSA Build Level 3 in 2026: What Mini Shai-Hulud Forged and What Would Have Stopped ItAttestations de Provenance npm & SLSA Build Level 3 en 2026 : Ce que Mini Shai-Hulud a Forgé et Ce Qui L’Aurait Arrêté

On May 11, 2026, attackers published 84 malicious @tanstack/* versions in under six minutes — and every single package carried a cryptographically valid SLSA provenance attestation. The packages were signed by Sigstore. The attestations verified correctly. Yet the ecosystem had just been hit by the Mini Shai-Hulud worm, the first npm supply chain attack specifically documented for bypassing SLSA Build Level 3 guarantees. Three weeks later, on June 10, 2026, the Open Source Security Foundation published its post-mortem: "Mini Shai-Hulud: Where SLSA's Boundaries Fall."

Le 11 mai 2026, des attaquants ont publié 84 versions malveillantes de packages @tanstack/* en moins de six minutes — et chaque package portait une attestation de provenance SLSA cryptographiquement valide. Les packages étaient signés par Sigstore. Les attestations se vérifiaient correctement. Pourtant l'écosystème venait d'être frappé par le ver Mini Shai-Hulud, la première attaque supply chain npm spécifiquement documentée pour avoir contourné les garanties du SLSA Build Level 3. Trois semaines plus tard, le 10 juin 2026, l'Open Source Security Foundation a publié son post-mortem : « Mini Shai-Hulud : Où s'Arrêtent les Frontières de SLSA ».

This article explains exactly how npm provenance works, what SLSA Build Level 3 actually guarantees (and does not), what the TanStack attack forged and why, and how you can verify package provenance in your own CI/CD pipeline today. Because understanding the boundary of a security control is the only way to correctly rely on it.

Cet article explique exactement comment fonctionne la provenance npm, ce que le SLSA Build Level 3 garantit réellement (et ne garantit pas), ce que l'attaque TanStack a forgé et pourquoi, et comment vous pouvez vérifier la provenance des packages dans votre propre pipeline CI/CD dès aujourd'hui. Car comprendre la limite d'un contrôle de sécurité est la seule façon de s'y fier correctement.

What Is npm Package Provenance?

Qu'est-ce que la Provenance de Package npm ?

npm package provenance, introduced in May 2023 and reaching General Availability in October 2023, is a system that cryptographically links a published npm package to the exact source commit and CI/CD workflow that produced it. When a maintainer publishes with npm publish --provenance, the registry stores a SLSA provenance attestation alongside the package tarball. This attestation is signed via Sigstore, and the signature is anchored in the Rekor transparency log — a tamper-evident public ledger.

La provenance de package npm, introduite en mai 2023 et passée en disponibilité générale en octobre 2023, est un système qui lie cryptographiquement un package npm publié au commit source exact et au workflow CI/CD qui l'a produit. Quand un mainteneur publie avec npm publish --provenance, le registre stocke une attestation de provenance SLSA aux côtés du tarball du package. Cette attestation est signée via Sigstore, et la signature est ancrée dans le journal de transparence Rekor — un registre public infalsifiable.

As of npm CLI v11.5.1 (July 2025), packages published via Trusted Publishing — GitHub Actions with OIDC — automatically receive provenance attestation by default. The --provenance flag is no longer required when publishing through supported CI platforms. The registry serves attestation data at https://registry.npmjs.org/-/npm/v1/attestations/<name>@<version>.

Depuis npm CLI v11.5.1 (juillet 2025), les packages publiés via Trusted Publishing — GitHub Actions avec OIDC — reçoivent automatiquement une attestation de provenance par défaut. Le flag --provenance n'est plus requis pour la publication via les plateformes CI supportées. Le registre sert les données d'attestation à https://registry.npmjs.org/-/npm/v1/attestations/<name>@<version>.

What provenance records for each published version:

Ce que la provenance enregistre pour chaque version publiée :

• The source repository URL and the exact git commit SHA at publish time
• L'URL du dépôt source et le SHA du commit git exact au moment de la publication
• The CI/CD workflow path (e.g. .github/workflows/publish.yml)
• Le chemin du workflow CI/CD (ex. .github/workflows/publish.yml)
• The build platform identity (GitHub Actions, GitLab CI, etc.)
• L'identité de la plateforme de build (GitHub Actions, GitLab CI, etc.)
• The Sigstore certificate chain proving the build system's OIDC identity
• La chaîne de certificats Sigstore prouvant l'identité OIDC du système de build

SLSA Build Levels Explained: L0 to L3

Les Niveaux SLSA Build Expliqués : L0 à L3

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework published by the Open Source Security Foundation. The current version is SLSA v1.2, released in 2025, which clarified isolation requirements and updated the provenance schema. The Build Track has four levels:

SLSA (Supply-chain Levels for Software Artifacts, prononcé "salsa") est un cadre de sécurité publié par l'Open Source Security Foundation. La version actuelle est SLSA v1.2, publiée en 2025, qui a clarifié les exigences d'isolation et mis à jour le schéma de provenance. La Build Track compte quatre niveaux :

The critical insight: SLSA L2 guarantees that a build platform produced the provenance, and that the package matches the linked source. It does not guarantee that the build platform's environment was uncompromised when it produced that attestation.

L'insight critique : SLSA L2 garantit qu'une plateforme de build a produit la provenance, et que le package correspond à la source liée. Cela ne garantit pas que l'environnement de la plateforme de build n'était pas compromis au moment de produire cette attestation.

The Mini Shai-Hulud Attack: How Cryptographically Valid Attestations Were "Forged"

L'Attaque Mini Shai-Hulud : Comment des Attestations Cryptographiquement Valides Ont Été « Forgées »

The TanStack attack on May 11, 2026 (CVE-2026-45321, CVSS 9.6) did not forge attestations in the traditional sense. The attackers did not break Sigstore's cryptography or bypass Rekor's transparency log. Instead, they chained three vulnerabilities to take control of the legitimate CI/CD pipeline itself, then let npm's provenance system faithfully record what had happened:

L'attaque TanStack du 11 mai 2026 (CVE-2026-45321, CVSS 9.6) n'a pas forgé d'attestations au sens traditionnel. Les attaquants n'ont pas cassé la cryptographie de Sigstore ni contourné le journal de transparence Rekor. Ils ont plutôt chaîné trois vulnérabilités pour prendre le contrôle du pipeline CI/CD légitime lui-même, puis laisser le système de provenance npm enregistrer fidèlement ce qui s'était passé :

1. GitHub Actions workflow misconfiguration — a pull_request_target trigger allowed external contributors to run workflows with write permissions to the repository
2. Mauvaise configuration workflow GitHub Actions — un déclencheur pull_request_target permettait à des contributeurs externes de lancer des workflows avec des permissions d'écriture sur le dépôt
3. Runner cache poisoning — the attacker's PR modified build tooling (installed during the cache-restore step) to include a credential harvesting payload. The cache key matched legitimate builds
4. Empoisonnement du cache runner — le PR de l'attaquant modifiait les outils de build (installés lors de l'étape de restauration du cache) pour inclure un payload de récolte de credentials. La clé de cache correspondait aux builds légitimes
5. OIDC token extraction from runner memory — the poisoned build step extracted the GitHub Actions OIDC token from process memory and used it to authenticate a second npm publish call alongside the legitimate one
6. Extraction du token OIDC depuis la mémoire du runner — l'étape de build empoisonnée extrayait le token OIDC GitHub Actions depuis la mémoire du processus et l'utilisait pour authentifier un second appel npm publish en parallèle du légitime

The result: npm received two publish calls from what appeared to be the same legitimate GitHub Actions runner. Both packages received SLSA L2 attestations signed by Sigstore with the same GitHub workflow identity. The registry had no way to distinguish them — because both were technically produced by the GitHub Actions platform, exactly as SLSA L2 records.

Le résultat : npm a reçu deux appels de publication provenant de ce qui semblait être le même runner GitHub Actions légitime. Les deux packages ont reçu des attestations SLSA L2 signées par Sigstore avec la même identité de workflow GitHub. Le registre n'avait aucun moyen de les distinguer — car les deux étaient techniquement produits par la plateforme GitHub Actions, exactement comme SLSA L2 le documente.

"Build platforms can accurately record what ran within their trust boundary, but they cannot vouch for whether what ran produced an uncompromised artifact. The boundary of observability is the boundary of the trust context." — OpenSSF, June 10, 2026

« Les plateformes de build peuvent enregistrer précisément ce qui s'est exécuté dans leur périmètre de confiance, mais elles ne peuvent pas garantir que ce qui s'est exécuté a produit un artefact non compromis. La limite de l'observabilité est la limite du contexte de confiance. » — OpenSSF, 10 juin 2026

What SLSA Build Level 3 Would Have Done Differently

Ce que le SLSA Build Level 3 Aurait Fait Différemment

SLSA L3 requires that signing secrets are isolated from the build environment itself. In a true L3 compliant system, the OIDC token used to sign the provenance attestation is never accessible from within the build process — it is managed by the build platform infrastructure, not the runner. The cache poisoning vector would have been unable to access the OIDC signing token because it would not exist in the runner's process space.

Le SLSA L3 exige que les secrets de signature soient isolés de l'environnement de build lui-même. Dans un système conforme L3 réel, le token OIDC utilisé pour signer l'attestation de provenance n'est jamais accessible depuis le processus de build — il est géré par l'infrastructure de la plateforme de build, pas par le runner. Le vecteur d'empoisonnement de cache n'aurait pas pu accéder au token OIDC de signature car il n'existerait pas dans l'espace de processus du runner.

As of June 2026, no major public CI/CD platform (GitHub Actions, GitLab CI, CircleCI) has achieved SLSA L3 for npm publishing. Practical L3 requires:

En juin 2026, aucune grande plateforme CI/CD publique (GitHub Actions, GitLab CI, CircleCI) n'a atteint SLSA L3 pour la publication npm. Un L3 pratique exige :

• A hardened build service separate from the user-controlled runner (the build steps run in one environment; signing happens in another with no network path between them)
• Un service de build durci séparé du runner contrôlé par l'utilisateur (les étapes de build s'exécutent dans un environnement ; la signature se produit dans un autre sans chemin réseau entre eux)
• No access to signing keys or OIDC credentials from within the build environment, even by the code being built
• Aucun accès aux clés de signature ou aux credentials OIDC depuis l'environnement de build, même par le code en cours de construction
• Verified source integrity — the build platform independently validates the source before building, rather than trusting what the runner fetched
• Intégrité de source vérifiée — la plateforme de build valide indépendamment la source avant de construire, plutôt que de faire confiance à ce que le runner a récupéré
• An isolated ephemeral build environment per build, with no shared mutable state between builds (preventing cache poisoning across runs)
• Un environnement de build éphémère isolé par build, sans état mutable partagé entre les builds (empêchant l'empoisonnement de cache entre les runs)

SLSA L3 generators currently exist for GitHub Actions via the slsa-github-generator project. GitLab, Jenkins and other platforms have less mature or community-maintained solutions. The challenge is that L3 requires the platform to enforce isolation — consumer-side configuration cannot achieve it.

Des générateurs SLSA L3 existent actuellement pour GitHub Actions via le projet slsa-github-generator. GitLab, Jenkins et d'autres plateformes ont des solutions moins matures ou maintenues par la communauté. Le défi est que L3 exige que la plateforme impose l'isolation — la configuration côté consommateur ne peut pas l'atteindre.

How to Verify npm Package Provenance Today

Comment Vérifier la Provenance d'un Package npm Aujourd'hui

For packages that publish with provenance, verification is straightforward using the npm CLI or cosign:

Pour les packages qui publient avec provenance, la vérification est simple avec le CLI npm ou cosign :

# Method 1: npm audit signatures (checks all installed packages)
npm audit signatures

# Output:
# audited 847 packages in 3s
# 312 packages have verified registry signatures
# 23 packages have verified attestations

# Method 2: cosign (for detailed provenance verification)
# Install cosign: https://docs.sigstore.dev/quickstart/quickstart-cosign/

# Get the package tarball and its attestation bundle
npm pack express@5.1.0
ATTESTATION=$(curl -s "https://registry.npmjs.org/-/npm/v1/attestations/express@5.1.0" | jq -r '.attestations[0].bundle')

# Verify with cosign (GitHub Actions workflow identity)
cosign verify-blob-attestation \
  --bundle <(echo "$ATTESTATION") \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp "https://github.com/expressjs/express/.github/workflows/publish.yml@.*" \
  express-5.1.0.tgz

# Method 3: slsa-verifier (recommended for SLSA compliance)
slsa-verifier verify-npm-package \
  --package-name express \
  --package-version 5.1.0 \
  --source-uri github.com/expressjs/express

What each tool checks: npm audit signatures verifies that registry signatures (Ed25519) match the package content — preventing tampering after upload. It also checks provenance attestations when present. cosign verify-blob-attestation additionally validates the build workflow identity against your expected repository and workflow path, giving you confidence in the supply chain origin.

Ce que chaque outil vérifie : npm audit signatures vérifie que les signatures de registre (Ed25519) correspondent au contenu du package — empêchant le tampering après l'upload. Il vérifie également les attestations de provenance quand elles sont présentes. cosign verify-blob-attestation valide également l'identité du workflow de build par rapport à votre dépôt et chemin de workflow attendus, vous donnant confiance dans l'origine de la chaîne d'approvisionnement.

Publishing with npm Provenance: Step-by-Step GitHub Actions Workflow

Publier avec Provenance npm : Workflow GitHub Actions Étape par Étape

If you maintain an npm package and want to publish with SLSA L2 provenance, here is a minimal GitHub Actions workflow. After the Mini Shai-Hulud incident, it also includes mitigations for the exact attack vectors used:

Si vous maintenez un package npm et voulez publier avec la provenance SLSA L2, voici un workflow GitHub Actions minimal. Après l'incident Mini Shai-Hulud, il inclut également des mitigations pour les vecteurs d'attaque exacts utilisés :

# .github/workflows/publish.yml
name: Publish npm Package with Provenance

on:
  push:
    tags: ["v*"]  # Only publish on version tags — avoids pull_request_target risks

permissions:
  contents: read
  id-token: write  # REQUIRED for Sigstore provenance signing

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: npm-publish  # Use a protected environment with required reviewers

    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false  # Don't persist GitHub token in the checkout

      # Pin the Node.js setup action to a specific commit SHA (not a tag)
      - uses: actions/setup-node@1a4442cacd436585916779262731d1f68a3d8b6  # v3.8.0
        with:
          node-version: "22"
          registry-url: "https://registry.npmjs.org"
          # Do NOT use cache: "npm" here if you want to avoid cache poisoning
          # Use a content-addressed approach instead

      - name: Verify npm lockfile integrity
        run: npm ci --ignore-scripts  # Never run postinstall scripts on publish machines

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build --if-present

      - name: Publish with provenance
        run: npm publish --provenance --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
          # npm will use the id-token permission above to request OIDC token
          # and sign the provenance attestation via Sigstore automatically

Key hardening decisions in this workflow:

Décisions de durcissement clés dans ce workflow :

• Tag trigger only — push.tags instead of pull_request_target eliminates the primary attack vector used in TanStack. Pull requests from forks never trigger publish workflows
• Déclencheur sur tag uniquement — push.tags au lieu de pull_request_target élimine le vecteur d'attaque principal utilisé dans TanStack. Les pull requests de forks ne déclenchent jamais les workflows de publication
• Protected environment — environment: npm-publish requires human review before the workflow proceeds, and environment secrets (like NPM_TOKEN) are only available after approval
• Environnement protégé — environment: npm-publish exige une revue humaine avant que le workflow ne procède, et les secrets d'environnement (comme NPM_TOKEN) ne sont disponibles qu'après approbation
• Pinned action SHA — instead of actions/setup-node@v3 (a mutable tag), use the specific commit SHA. This prevents action hijacking even if the tag is rewritten
• SHA d'action épinglé — au lieu de actions/setup-node@v3 (un tag mutable), utilisez le SHA de commit spécifique. Cela empêche le hijacking d'action même si le tag est réécrit
• No lifecycle scripts — --ignore-scripts during install on the publish machine prevents postinstall hooks from exfiltrating the OIDC token before signing
• Pas de scripts lifecycle — --ignore-scripts lors de l'installation sur la machine de publication empêche les hooks postinstall d'exfiltrer le token OIDC avant la signature

Consuming Packages: Enforcing Provenance in Your CI/CD

Consommer des Packages : Imposer la Provenance dans Votre CI/CD

As a package consumer, you can add provenance verification as a gate in your CI/CD pipeline. This doesn't protect you from the Mini Shai-Hulud scenario (where the attacker controlled the provider's pipeline), but it does protect against many other threat vectors — package substitution, registry poisoning, compromised registry credentials — that SLSA L2 attestations do block effectively:

En tant que consommateur de packages, vous pouvez ajouter la vérification de provenance comme un portail dans votre pipeline CI/CD. Cela ne vous protège pas du scénario Mini Shai-Hulud (où l'attaquant contrôlait le pipeline du fournisseur), mais cela protège contre de nombreux autres vecteurs de menace — substitution de package, empoisonnement de registre, credentials de registre compromis — que les attestations SLSA L2 bloquent efficacement :

# In your CI/CD pipeline, after npm ci:
npm audit signatures

# Exit code 0 = all signatures valid (registry + provenance where present)
# Exit code 1 = signature mismatch — STOP THE BUILD

# For critical dependencies, go further with slsa-verifier:
slsa-verifier verify-npm-package \
  --package-name @tanstack/react-query \
  --package-version $(node -e "console.log(require('./package-lock.json').packages['node_modules/@tanstack/react-query'].version)") \
  --source-uri github.com/TanStack/query

# Automate in GitHub Actions:
- name: Verify dependency provenance
  run: |
    npm audit signatures
    echo "Provenance check passed"

Note that provenance verification only works for packages that publish with provenance. As of 2026, npm ecosystem adoption is still growing — most packages do not yet publish with attestations. Use npm audit signatures as a minimum baseline: it at least validates that the package content has not been tampered with since it was uploaded to the registry.

Notez que la vérification de provenance ne fonctionne que pour les packages qui publient avec provenance. En 2026, l'adoption dans l'écosystème npm est encore en croissance — la plupart des packages ne publient pas encore avec attestations. Utilisez npm audit signatures comme base minimale : cela valide au moins que le contenu du package n'a pas été altéré depuis qu'il a été uploadé sur le registre.

Beyond Provenance: Defense in Depth for npm Supply Chain Security

Au-Delà de la Provenance : Défense en Profondeur pour la Sécurité Supply Chain npm

Provenance attestations are one layer of defense, not a complete solution. The Mini Shai-Hulud attack demonstrates that supply chain security requires layered controls. Here is what a complete supply chain security posture looks like in 2026, ordered from highest to lowest impact:

Les attestations de provenance sont une couche de défense, pas une solution complète. L'attaque Mini Shai-Hulud démontre que la sécurité supply chain exige des contrôles en couches. Voici à quoi ressemble une posture de sécurité supply chain complète en 2026, ordonnée du plus au moins impactant :

1. Lockfile integrity in CI/CD — use npm ci (not npm install) in every CI environment. npm ci requires an exact package-lock.json match and fails on deviation. This is your first line of defense against dependency substitution
2. Intégrité du lockfile en CI/CD — utilisez npm ci (pas npm install) dans tout environnement CI. npm ci exige une correspondance exacte du package-lock.json et échoue en cas de déviation. C'est votre première ligne de défense contre la substitution de dépendances
3. Pin action versions to commit SHAs — never use mutable tags like @v3 for GitHub Actions. Use ratchet or StepSecurity Harden-Runner to enforce this automatically
4. Épingler les versions d'actions aux SHAs de commits — n'utilisez jamais de tags mutables comme @v3 pour les actions GitHub. Utilisez ratchet ou StepSecurity Harden-Runner pour l'imposer automatiquement
5. Avoid pull_request_target for untrusted code — if you must use it, ensure that any step that runs untrusted code has no access to secrets or OIDC token permissions. Use permissions: {} for those specific steps
6. Éviter pull_request_target pour le code non fiable — si vous devez l'utiliser, assurez-vous que toute étape qui exécute du code non fiable n'a aucun accès aux secrets ou permissions de token OIDC. Utilisez permissions: {} pour ces étapes spécifiques
7. Verify provenance attestations — run npm audit signatures in CI and add slsa-verifier checks for your highest-risk dependencies (build tooling, authentication libraries, crypto packages)
8. Vérifier les attestations de provenance — exécutez npm audit signatures en CI et ajoutez des vérifications slsa-verifier pour vos dépendances à plus haut risque (outils de build, bibliothèques d'authentification, packages crypto)
9. Automated CVE monitoring — provenance tells you where a package came from. CVE monitoring tells you if a package you're running has a known vulnerability. Both are necessary; neither replaces the other
10. Monitoring CVE automatisé — la provenance vous dit d'où vient un package. Le monitoring CVE vous dit si un package que vous utilisez a une vulnérabilité connue. Les deux sont nécessaires ; aucun ne remplace l'autre

Frequently Asked Questions

Questions fréquentes