# 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.

```mermaid
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.

```bash
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 :

```bash
npm audit
```

```mermaid
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.

```bash
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`
.

```bash
npm audit fix --force
```

```mermaid
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.

```bash
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.