Dépendances vulnérables et SBOM

Prérequis : npm et dépendances, versions et audit.

Pourquoi

90 % du code qui tourne n'est pas le tien (node_modules !). Chaque dépendance = code exécuté avec tes privilèges. Les CVE n'attendent pas ta relecture : elles s'exploitent via tes updates (ou tes non-updates).

Concepts

• Audit : npm audit / OSV / Dependabot : CVE connues dans ton arbre (directes + transitives !). En CI : échec au-delà d'un seuil (haute/critique), pas juste un rapport ignoré.
• SBOM (Software Bill Of Materials) : l'inventaire exact de ce qui tourne (versions + licences). Exigé par de plus en plus de clients/réglementations ; indispensable pour répondre « sommes-nous affectés par CVE-X ? » en minutes.
• Pinning + lock : versions exactes + lock commité (reproductible, cf. DevOps 5.2). ^ permissifs + install sans lock = loterie hebdomadaire.
• Mise à jour : mineures/patchs en continu (automatiser : Renovate/Dependabot + CI verte), majeures planifiées. La dette de versions se paie avec intérêts (saut de 3 majeures = enfer).

Exemple : la politique minimale

- npm audit en CI : échec si critique (tolérance 0), délai 30 j si haute
- Renovate : PRs auto (patch/mineur groupés, hebdo), revue humaine
- SBOM généré à chaque release (cyclonedx), archivé

Cas réel

Log4Shell (déc. 2021) : sans SBOM, 3 semaines pour savoir quels services étaient exposés (dépendance transitive de transitive). Avec : requête unique, patch ciblé en 1 jour. L'inventaire, c'est la vitesse de réponse.

Pièges

• npm install package sans vérifier (étoiles, maintenance, typosquatting : electorn vs electron !) : chaque ajout est une décision de confiance.
• Audit en warning ignoré : s'il n'échoue jamais, il ne sert jamais. Seuil + échec.
• Pinner puis oublier : épinglé ≠ à jour. Le pinning fige, la MAJ suit (automatiser !).

À retenir

Auditer en CI avec seuil, SBOM par release, lock + pinning, MAJ continues automatisées.