Comment automatiser l'audit des dependances npm et scanner les vulnerabilites CVE en 8 etapes (2026)

— Pourquoi npm audit ne suffit plus en 2026

npm audit consomme la GitHub Advisory Database et fait du bon travail sur les CVE bien connues du registre npm. Mais en avril 2026, deux faits changent la donne. D'abord, le NIST a annonce le 17 avril 2026 (voir notre analyse complete) que les CVE anterieures a mars 2026 ne seront plus systematiquement enrichies. Beaucoup d'outils npm reposent indirectement sur la NVD : leur couverture se degrade. Ensuite, les attaques de supply-chain npm explosent : event-stream, ua-parser-js, colors, left-pad, et plus recemment plusieurs incidents 2025-2026 ont montre que les paquets transitives doivent etre scannes avec autant de rigueur que les directs.

— Etape 1 : generer une SBOM CycloneDX a chaque build

Une Software Bill of Materials (SBOM) au format CycloneDX 1.5+ est le socle de toute strategie d'audit en 2026. Elle est exigee par le Cyber Resilience Act europeen (applicable 2027) et fortement recommandee par l'ANSSI. Generation automatique avec Syft :

syft packages dir:. -o cyclonedx-json > sbom.cdx.json

Versionner la SBOM dans le repository et la publier comme artefact de release. Pour un projet React/Next.js typique, la SBOM contient 800 a 2 500 paquets avec leurs versions exactes et hashes.

— Etape 2 : installer osv-scanner dans la CI

osv-scanner est l'outil gratuit de reference en 2026. Maintenu par Google, il consomme OSV.dev qui agrege GitHub Advisories, RustSec, PyPA Advisory Database, Go Vulnerability Database et plus. Installation dans GitHub Actions :

- uses: google/osv-scanner-action@v1
  with:
    scan-args: |-
      --recursive
      --format=sarif
      --output=osv-results.sarif
      ./

Le format SARIF permet l'integration native avec GitHub Code Scanning : les vulnerabilites apparaissent directement dans l'onglet Security du repository. Pour les environnements air-gapped, osv-scanner peut consommer un mirror local d'OSV.dev synchronise quotidiennement.

— Etape 3 : ajouter Trivy pour les images Docker et lockfiles

Trivy d'Aqua Security complete osv-scanner sur la couche conteneur. Il scanne les images Docker, les filesystems, les lockfiles npm/yarn/pnpm, et inclut un mode secret detection qui repere les cles AWS, GitHub tokens, et autres secrets accidentellement commits. Configuration dans la CI :

- uses: aquasecurity/trivy-action@master
  with:
    scan-type: 'fs'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'

— Etape 4 : configurer Renovate avec sources multiples

Renovate Bot doit etre configure avec plusieurs vulnerability data sources. Le fichier renovate.json typique en 2026 :

{
  "extends": ["config:recommended", ":rebaseStalePrs"],
  "vulnerabilityAlerts": { "enabled": true },
  "osvVulnerabilityAlerts": true,
  "schedule": ["before 7am every weekday"],
  "prHourlyLimit": 5
}

L'option osvVulnerabilityAlerts: true active la consommation d'OSV.dev en complement de GHSA. C'est ce qui compense la perte d'enrichissement NVD.

— Etape 5 : connecter EUVD pour la couverture europeenne

L'European Vulnerability Database (EUVD) de l'ENISA expose une API REST publique. Synchronisez un cache local quotidien (PostgreSQL ou SQLite) puis interrogez-le dans le pipeline de triage. Pour les entreprises NIS2-pertinentes, c'est imperatif a partir de Q3 2026 - les auditeurs vont demander la trace.

— Etape 6 : automatiser le triage avec une politique CVSS ponderee

Quand plusieurs sources donnent des scores CVSS divergents, choisissez par regle ecrite. Notre politique recommandee :

1. Si la CVE est dans la CISA KEV : SLA patch 7 jours, peu importe le CVSS.
2. Si CVSS NVD ou OSV >= 9.0 : SLA patch 14 jours.
3. Si CVSS >= 7.0 : SLA patch 30 jours.
4. Si CVSS >= 4.0 : SLA patch 90 jours.
5. Si EPSS > 50 % (probabilite d'exploitation 30 jours) : SLA patch 14 jours independamment du CVSS.

Implementez cette politique comme un script Python ou TypeScript qui consomme les sorties SARIF d'osv-scanner et Trivy, croise avec les listes KEV et EPSS, et emet une recommandation prioritaire par CVE. Les agences IA modernes peuvent meme utiliser un LLM pour le pre-triage des justifications business (voir notre guide Plug-Tech sur le choix LLM).

— Etape 7 : alerter le SOC et bloquer les releases bloquantes

Configurez la CI pour echouer le build si une CVE Critical (CVSS >= 9) est detectee dans une dependance directe ou si une CVE est presente dans la KEV. Pour les CVE High (CVSS 7-8.9), generez une alerte vers le SOC (Slack, Microsoft Teams, PagerDuty) sans bloquer le build. Cette logique evite les blocages excessifs tout en garantissant qu'aucune vulnerabilite critique n'atteint la production.

— Etape 8 : auditer trimestriellement et reviser les seuils

Tous les 90 jours, mesurez : (a) nombre de CVE detectees vs ratees (par echantillonnage manuel), (b) MTTR par categorie de severite, (c) nombre de faux positifs (CVE non applicables au contexte), (d) nouvelles sources a integrer. Ajustez la politique en consequence. Documentez chaque revision pour les auditeurs NIS2.

— FAQ