Ce que l'incident AsyncAPI a changé
Pendant deux semaines de juillet 2026, cinq versions de packages AsyncAPI ont circulé avec une provenance OIDC signée — un mécanisme introduit précisément pour garantir l'origine d'un package. Les attaquants avaient compromis le pipeline de publication, pas la clé de signature. Résultat : npm audit signatures retournait un résultat propre, et les gestionnaires de dépendances ne levaient aucune alerte. Cela change la manière dont on doit penser la sécurité des dépendances : la signature prouve l'intégrité du paquet au moment de sa publication, pas l'intégrité du processus qui l'a produit.
Mesures concrètes à mettre en place
- **Politique --frozen-lockfile** — interdire toute modification silencieuse du package-lock.json en CI (
npm cil'impose nativement,--frozen-lockfilepour yarn/pnpm). - **Vérification des hashes en CI** — ajouter un job qui compare les hashes SHA-512 du lockfile aux registres npm et détecte toute divergence.
- **SCA automatisé** — intégrer un scanner de composition logicielle (OWASP Dependency-Check, Trivy, Snyk) comme étape bloquante du pipeline.
- **Provenance SLSA niveau 2 minimum** — lors de vos publications, générer et attacher les attestations SLSA ; lors de vos consommations, vérifier que les packages critiques en disposent.
- **Surveillance des digests d'image** — ancrer chaque image Docker sur son digest sha256 plutôt que sur un tag flottant.
- **Alertes sur les nouvelles versions non planifiées** — configurer Dependabot ou Renovate pour notifier toute version publiée hors de votre fenêtre habituelle.
Ce que le lockfile garantit — et ce qu'il ne garantit pas
Le package-lock.json enregistre la version exacte et le hash de chaque dépendance résolue. Il empêche une montée de version silencieuse lors d'un npm install ultérieur. Ce qu'il ne fait pas : vérifier que le contenu du package correspondant n'a pas changé côté registry après sa résolution initiale, ni que le pipeline qui a produit le package était lui-même sain. Le lockfile est un instantané de ce que vous avez résolu un jour donné — pas une garantie sur la chaîne de fabrication amont.
Durcir votre pipeline CI étape par étape
Passer à `npm ci` et bannir `npm install` en CI
Remplacez tout npm install dans vos workflows par npm ci. La commande refuse de s'exécuter si le package-lock.json est absent ou diverge du package.json. Ajoutez --ignore-scripts si votre arbre contient des postinstall tiers non audités.
Activer `npm audit` en mode bloquant
Ajoutez npm audit --audit-level=high après npm ci et avant le build. En GitHub Actions, l'étape échoue si un résultat de sévérité élevée est détecté. Différenciez les dépendances de développement avec --omit=dev.
Vérifier les hashes avec `npm audit signatures`
Depuis npm 8.8, npm audit signatures vérifie que chaque package installé possède une signature valide enregistrée dans le registry. Exécutez cette commande après npm ci. Elle ne détecte pas les cas AsyncAPI (signature valide mais pipeline compromis), mais constitue un premier filet.
Intégrer un scanner SCA (Trivy ou OWASP Dependency-Check)
Ajoutez un job SCA indépendant dans votre workflow CI. Trivy analyse le package-lock.json directement (trivy fs --scanners vuln .) sans nécessiter d'installation des dépendances. Configurez-le pour échouer sur les CVE de score CVSS supérieur à 7.
Consommer et émettre des attestations SLSA
Pour vos propres packages publiés, activez la provenance SLSA dans votre workflow de publication (GitHub Actions slsa-framework/slsa-github-generator). Pour les dépendances tierces, vérifiez les attestations des packages critiques via l'API Sigstore.
Épingler les actions CI et images sur leur digest sha256
Dans vos fichiers .github/workflows/*.yml ou .gitlab-ci.yml, remplacez les tags flottants par des digests sha256. Un tag flottant peut pointer vers une image différente le lendemain d'une compromission du registry.
Ne jamais patcher une dépendance directement en production en modifiant node_modules à la main : le lockfile divergerait, et le prochain déploiement depuis CI réintroduirait le package d'origine. Toute correction passe par le lockfile versionné, rejoué par la CI.
Intégration dans votre workflow Git hébergé
Ces contrôles sont des étapes de pipeline, pas des habitudes manuelles : ils appartiennent à votre ci.yml (GitHub Actions) ou à votre .gitlab-ci.yml, déclenchés à chaque push et sur chaque pull request. Sur un dépôt auto-hébergé (Gitea, GitLab CE), les mêmes recettes s'appliquent. Protégez votre branche principale avec une règle de merge conditionnel à la CI verte, et bloquez les merges si l'un de ces jobs SCA échoue.
