First commit
This commit is contained in:
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
@@ -0,0 +1 @@
|
|||||||
|
/.idea
|
||||||
128
README.md
Normal file
128
README.md
Normal file
@@ -0,0 +1,128 @@
|
|||||||
|
# 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.
|
||||||
21
package-lock.json
generated
Normal file
21
package-lock.json
generated
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
{
|
||||||
|
"name": "npm-audit",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"lockfileVersion": 3,
|
||||||
|
"requires": true,
|
||||||
|
"packages": {
|
||||||
|
"": {
|
||||||
|
"name": "npm-audit",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"dependencies": {
|
||||||
|
"lodash": "4.17.11"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"node_modules/lodash": {
|
||||||
|
"version": "4.17.11",
|
||||||
|
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.11.tgz",
|
||||||
|
"integrity": "sha512-cQKh8igo5QUhZ7lg38DYWAxMvjSAKG0A8wGSVimP07SIUEK2UO+arSRKbRZWtelMtN5V0Hkwh5ryOto/SshYIg==",
|
||||||
|
"license": "MIT"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
13
package.json
Normal file
13
package.json
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
{
|
||||||
|
"name": "npm-audit",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "Démonstration OWASP 2025 RC1 A03 - npm audit",
|
||||||
|
"main": "index.js",
|
||||||
|
"dependencies": {
|
||||||
|
"lodash": "4.17.11"
|
||||||
|
},
|
||||||
|
"scripts": {
|
||||||
|
"test": "echo \"Error: no test specified\" && exit 1"
|
||||||
|
},
|
||||||
|
"private": true
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user