Démonstration : audit de sécurité des dépendances (npm audit)

Cette démonstration illustre une faille de type OWASP A03:2025 - Software Supply Chain Failures.

Contexte

Vous venez de récupérer le code source d'un projet existant (simulé par les fichiers fournis). Ce projet utilise une librairie tierce (lodash) dans une version spécifique définie dans le fichier package.json.

Votre objectif est d'analyser la chaîne logistique logicielle (Software Supply Chain) de ce projet pour vérifier si les dépendances utilisées sont sécurisées, sans avoir à lire leur code source.

graph TD
    subgraph "Votre Projet"
        A[Code Source] --> B(package.json)
    end
    subgraph "Chaîne Logistique Externe"
        B -- "dépend de" --> C{"lodash: 4.17.11"}
        C -- "téléchargé depuis" --> D[(Registre NPM)]
        D -- "code fourni par" --> E[Auteurs de Lodash]
        E -- "code contient" --> F(("Faille Prototype Pollution"))
    end
    A -.-> F

Prérequis

• Node.js installé
• Un terminal ouvert dans le dossier contenant le fichier package.json fourni.

---

Déroulé de la démonstration

Étape 1 : installation des dépendances

Comme pour tout projet Node.js fraîchement récupéré, commencez par installer les paquets listés dans le manifeste.

npm install

Observation : à la fin de l'installation, observez attentivement la sortie du terminal. Vous devriez voir un message du type : found X vulnerabilities (X high, X critical)

C'est le premier signal d'alarme : la "Supply Chain" contient des composants risqués.

Étape 2 : l'audit de sécurité (SCA) des dépendances

Le message précédent est un avertissement sommaire. Pour obtenir le détail des vulnérabilités (CVE), exécutez l'outil d'analyse de composition logicielle (SCA) natif :

npm audit

graph TD
    A["Commande npm audit"] --> B{Analyse du package-lock.json}
    B -- "compare les versions installées" --> C[(Base de données des vulnérabilités NPM/GitHub)]
    C -- "trouve 'lodash 4.17.11'" --> D[Rapport de Faille]
    D -- "détails" --> E["Gravité: High<br>Package: lodash<br>Faille: Prototype Pollution<br>Patch: >=4.17.21"]
    E --> F[Affichage dans le terminal]

Après analyse, repérez les informations clés :

• Severity (Gravité) : High ou Critical.
• Package : lodash (la librairie coupable).
• Vulnerability : "Prototype Pollution" (le type de faille).
• Patched in : La version minimale requise pour être en sécurité (ex: >=4.17.21).

Étape 3 : tentative de remédiation

Essayons d'utiliser l'outil de correction automatique de npm.

npm audit fix

Observation : relancez un npm audit après cette commande. Vous remarquerez que la faille est toujours présente !

Pourquoi ?

• npm audit fix respecte les règles de versionnage sémantique (SemVer) définies dans votre package.json.
• Notre package.json contient "lodash": "4.17.11". C'est une version stricte (pinning).
• npm audit fix ne peut pas mettre à jour vers la 4.17.21 (requise par le patch) car cela viole la règle "exactement 4.17.11" que nous avons définie.

Note : Si le package.json avait utilisé "lodash": "^4.17.11" (un "caret"), npm audit fix aurait fonctionné du premier coup, car le ^ autorise les mises à jour mineures et de patch (comme la 4.17.21).

Étape 4 : remédiation forcée

Pour corriger la faille malgré notre contrainte de version stricte, nous devons forcer npm à ignorer la règle du package.json et à mettre à jour le package-lock.json .

npm audit fix --force

graph TD
    A{Scénario de remédiation}
    A -- "npm audit fix" --> B(Analyse package.json)
    B -- "version '4.17.11' est stricte" --> C["Échec: ne peut pas mettre à jour en respectant la contrainte"]

    A -- "npm audit fix --force" --> D(Analyse package.json)
    D -- "option '--force' ignore la contrainte" --> E["Succès: mise à jour forcée vers '4.17.21'"]
    E --> F(Fichier package-lock.json mis à jour)

Actions effectuées par npm audit fix --force :

1. Téléchargement de la version corrigée (ex: 4.17.21).
2. Mise à jour forcée du fichier package-lock.json pour utiliser cette nouvelle version.
3. Suppression de la version vulnérable (4.17.11) des node_modules.

Étape 5 : vérification finale (sanity check)

Assurez-vous que la faille a bien été colmatée en relançant l'audit.

npm audit

Résultat attendu : found 0 vulnerabilities

---

Conclusion

• A03:2025 Supply Chain Failures : la sécurité de votre application ne dépend pas seulement de votre code, mais aussi de celui des autres (vos dépendances).
• SCA (Software Composition Analysis) : l'utilisation d'outils comme npm audit (ou Snyk, OWASP Dependency Check) est indispensable pour détecter les composants obsolètes ou vulnérables.
• Automatisation : dans un environnement professionnel (DevSecOps), cette commande d'audit devrait être intégrée dans la CI/CD et bloquer automatiquement le déploiement si une faille critique est détectée.