Enseigner la sécurité de la chaîne logicielle (supply chain) dans un cursus
Pourquoi la supply chain est-elle devenue incontournable en formation ?
Pendant des années, l'enseignement de la sécurité logicielle s'est concentré sur ce que l'étudiant écrit : les injections SQL, les XSS, les erreurs d'authentification. C'est nécessaire, mais insuffisant. Aujourd'hui, la menace la plus difficile à maîtriser se trouve dans ce que l'étudiant importe.
Une application moderne intègre des centaines, parfois des milliers, de bibliothèques tierces. Chacune est un vecteur d'attaque potentiel. L'incident SolarWinds en 2020 a démontré qu'un code malveillant inséré dans une mise à jour légitime pouvait compromettre des milliers d'organisations en quelques semaines. La backdoor dans XZ Utils découverte en 2024 a montré qu'un attaquant patient pouvait s'introduire dans un projet open source en deux ans de contribution légitime avant d'insérer sa charge.
Ces incidents ne sont plus des cas d'école réservés aux analystes de threat intelligence. Ils ont des implications directes sur le métier de développeur sécurisé, et par conséquent sur ce qu'on enseigne en école d'ingénieurs, en master informatique ou en bootcamp.
Ce que dit la réglementation
Le Cyber Resilience Act européen, applicable progressivement à partir de 2027, impose aux fabricants de produits numériques de documenter leurs composants logiciels (via un SBOM — Software Bill of Materials) et de gérer activement les vulnérabilités dans leurs dépendances. La directive NIS2 exige quant à elle des entités essentielles une gestion formalisée des risques de la chaîne d'approvisionnement.
Ces obligations réglementaires transforment la connaissance de la supply chain attack d'une curiosité académique en une compétence professionnelle attendue.
Les concepts clés à maîtriser
Les vecteurs d'attaque de la chaîne logicielle
Avant de concevoir des TP, les étudiants doivent comprendre les mécanismes d'attaque. Trois vecteurs principaux :
1. La dépendance compromise
Un attaquant introduit du code malveillant dans une bibliothèque légitime, soit en compromettant le compte du mainteneur (cas event-stream en 2018 pour npm), soit en publiant un paquet au nom similaire (typosquatting). L'étudiant qui fait npm install ou pip install sans vérification intègre le code malveillant.
2. Le dépôt compromis
L'attaquant compromet le système de build ou le dépôt de code source d'un éditeur. SolarWinds est l'exemple canonique : les serveurs de build d'Orion ont été compromis, et chaque client qui installait la mise à jour signée et légitime importait la backdoor SUNBURST.
3. La dépendance transitive vulnérable
La bibliothèque A que j'installe dépend de la bibliothèque B, elle-même dépendant de la bibliothèque C. Si C contient une vulnérabilité critique, je suis exposé sans l'avoir intentionnellement importée. Les arbres de dépendances de projets réels comptent couramment plusieurs centaines de nœuds.
Le SBOM : outil central de la supply chain
Un SBOM (Software Bill of Materials) est un inventaire structuré de tous les composants d'un logiciel : bibliothèques, versions, licences, sources. Les formats standard sont SPDX (ISO/IEC 5962) et CycloneDX.
Enseigner le SBOM, c'est enseigner deux choses distinctes :
- La génération : utiliser des outils pour produire automatiquement l'inventaire à partir d'un dépôt
- L'exploitation : interroger le SBOM pour identifier les vulnérabilités connues, vérifier les licences, détecter les composants obsolètes
Les CVE et CVSS appliqués aux dépendances
Un audit de dépendances retourne des listes de CVE avec leurs scores CVSS. L'étudiant doit apprendre à trier et prioriser : un score CVSS 9.8 dans une bibliothèque de test (non déployée en production) ne mérite pas la même attention qu'un score 7.5 dans une librairie de traitement de requêtes HTTP exposée au public.
Structurer un module supply chain
Positionnement dans le cursus
Ce module s'enseigne après les fondamentaux du secure coding et idéalement en parallèle ou en suite directe d'un module DevSecOps. L'étudiant doit déjà comprendre ce qu'est un pipeline CI/CD et un gestionnaire de paquets.
Objectifs pédagogiques type
À la fin du module, l'étudiant doit être capable de :
- Expliquer les trois principaux vecteurs d'attaque de la supply chain logicielle
- Générer un SBOM pour un projet réel avec au moins deux formats (SPDX ou CycloneDX)
- Réaliser un audit de dépendances avec un outil dédié et interpréter les résultats
- Intégrer une étape d'audit dans un pipeline CI/CD simple
- Appliquer un processus de mise à jour sécurisée pour les dépendances critiques
Volume horaire recommandé
| Séquence | Contenu | Durée |
|---|---|---|
| Cours introductif | Vecteurs d'attaque, incidents réels, cadre réglementaire | 2h |
| TD | Analyse d'un graphe de dépendances réel, identification CVE | 2h |
| TP 1 | Audit OWASP Dependency-Check sur projet Java ou Node.js | 3h |
| TP 2 | Génération SBOM avec Syft, exploitation avec Grype | 3h |
| TP 3 | Intégration dans un pipeline CI/CD (GitHub Actions ou GitLab CI) | 3h |
| Évaluation | Rapport d'audit + soutenance courte | 1h |
Total : environ 14 heures — intégrable dans un module de 2 ECTS ou en extension d'un module DevSecOps existant.
Prérequis étudiants
- Maîtrise d'un gestionnaire de paquets (npm, pip, Maven, Go modules)
- Notion de pipeline CI/CD
- Compréhension de base de la notation CVE/CVSS
- Environnement de virtualisation disponible (Docker ou VM)
TP pratiques : audit de dépendances, SBOM, CI/CD sécurisé
TP 1 — Audit de dépendances avec OWASP Dependency-Check
Objectif : identifier les vulnérabilités connues dans les dépendances d'un projet.
Déroulé :
- Cloner un projet d'exemple intentionnellement vieilli (plusieurs bibliothèques avec CVE connues)
- Lancer OWASP Dependency-Check en ligne de commande ou via plugin Maven
- Analyser le rapport HTML généré : trier les CVE par score CVSS, identifier les faux positifs
- Pour chaque vulnérabilité critique : identifier la version fixée, tester la mise à jour, vérifier l'absence de régression
Point pédagogique clé : apprendre à distinguer une CVE exploitable dans ce contexte précis d'une CVE théoriquement présente mais non exposée (composant unused, endpoint non exposé). C'est un exercice de priorisation, pas de panique.
TP 2 — Génération et exploitation d'un SBOM
Objectif : produire un SBOM et l'utiliser pour détecter des vulnérabilités.
Déroulé :
- Utiliser Syft pour générer un SBOM au format CycloneDX sur un projet Python ou une image Docker
- Inspecter le SBOM brut (JSON) : comprendre la structure (components, licenses, vulnerabilities)
- Passer le SBOM à Grype pour croiser avec les bases de vulnérabilités (NVD, GitHub Advisory)
- Comparer avec un scan direct de l'image via Trivy : identifier les différences de couverture
Variante avancée : modifier intentionnellement le SBOM pour masquer une dépendance vulnérable, puis démontrer comment un outil de vérification d'intégrité détecte la falsification.
TP 3 — Intégration dans un pipeline CI/CD
Objectif : empêcher le déploiement d'un artefact contenant des vulnérabilités critiques.
Déroulé :
- Créer un pipeline GitHub Actions ou GitLab CI simple avec une étape de build
- Ajouter une étape
trivy fs --exit-code 1 --severity CRITICAL .pour bloquer le pipeline en cas de CVE critique - Tester avec un projet vulnérable : observer le blocage
- Appliquer les correctifs (mise à jour de la dépendance), observer le pipeline passer
- Discussion : seuils de blocage CRITICAL vs HIGH, gestion des exceptions et des faux positifs
Ce TP introduit naturellement la notion de security gate dans le cycle de développement, fondamentale pour tout futur ingénieur travaillant en environnement DevSecOps.
Intégration dans le cursus existant
Option 1 : extension du module DevSecOps
C'est le chemin le plus naturel. Le module DevSecOps couvre déjà les secrets management, le SAST, le DAST. La supply chain en est le complément : on sécurise non seulement ce qu'on écrit (SAST) et ce qu'on teste dynamiquement (DAST), mais aussi ce qu'on importe.
Avantage : les étudiants comprennent immédiatement la logique d'ensemble — sécurité à chaque étape du cycle de développement.
Option 2 : module transversal GRC / conformité
Pour des masters axés sur la gouvernance ou la conformité, l'approche réglementaire (CRA, NIS2, gestion des fournisseurs) peut justifier un module dédié où la technique est secondaire par rapport au processus organisationnel : comment évaluer ses fournisseurs logiciels, que mettre dans les clauses contractuelles, comment documenter la conformité ?
Option 3 : cas intégré dans un projet fil rouge
Pour les cursus qui pratiquent la pédagogie par projet, intégrer une livraison supply chain dans le cahier des charges du projet : le groupe doit remettre un SBOM, un rapport d'audit de dépendances et un pipeline avec security gate pour valider son projet.
Les outils pour les TP
Le tableau suivant synthétise les outils open source recommandés :
| Outil | Fonction | Langages/Environnements | Licence |
|---|---|---|---|
| OWASP Dependency-Check | Audit CVE des dépendances | Java, .NET, Node.js, Python | Apache 2.0 |
| Trivy | Scan CVE + SBOM + config | Conteneurs, FS, IaC | Apache 2.0 |
| Syft | Génération SBOM | Conteneurs, FS | Apache 2.0 |
| Grype | Scan CVE sur SBOM | Tout (via SBOM CycloneDX/SPDX) | Apache 2.0 |
| npm audit | Audit NPM natif | Node.js | MIT |
| pip-audit | Audit PyPI natif | Python | Apache 2.0 |
Recommandation pratique : utiliser Trivy comme outil principal pour les TP sur conteneurs (il combine génération SBOM + scan CVE en une commande) et OWASP Dependency-Check pour les projets Java ou Node.js en TP guidé, car son rapport HTML est plus lisible pour des débutants.
Évaluer les compétences supply chain : formats et critères
Pourquoi l'évaluation classique ne suffit pas
Un QCM sur les vecteurs d'attaque supply chain évalue la mémorisation, pas la compétence opérationnelle. Un étudiant peut réciter la définition d'un SBOM sans jamais en avoir généré un. L'évaluation de ce module doit donc être pratique par défaut.
Formats d'évaluation recommandés
Le rapport d'audit est le format le plus adapté. L'étudiant reçoit un dépôt de code ou une image conteneur, réalise un audit complet (audit de dépendances + génération SBOM + scan de vulnérabilités), puis rédige un rapport structuré comprenant : liste des vulnérabilités critiques, justification de priorisation, recommandations de remédiation avec les commandes exactes.
L'intégration CI/CD notée est idéale pour les cursus DevSecOps. L'étudiant livre un pipeline fonctionnel avec une étape de security gate configurée, accompagné d'une justification des seuils choisis (pourquoi bloquer sur CRITICAL et non HIGH ? Comment gérer les exceptions ?).
La soutenance de 15 minutes permet d'évaluer la capacité à communiquer les résultats à un décideur non technique — compétence essentielle pour un futur développeur sécurisé ou ingénieur sécurité.
Grille critériée minimale
| Critère | Niveau 1 (insuffisant) | Niveau 2 (attendu) | Niveau 3 (excellent) |
|---|---|---|---|
| Exhaustivité de l'audit | Outil lancé, résultats copiés | Toutes les CVE listées avec CVSS | Priorisation justifiée, faux positifs identifiés |
| Qualité du SBOM | Non produit ou incomplet | SBOM généré, format valide | SBOM intégré au pipeline, automatisé |
| Remédiation | Aucune recommandation concrète | Versions corrigées identifiées | Correctifs testés, régression vérifiée |
| Communication | Rapport inaccessible | Rapport structuré et lisible | Résumé exécutif pour décideur non technique |
La veille comme compétence transversale
La supply chain évolue rapidement : de nouvelles vulnérabilités critiques (CVE) dans des bibliothèques populaires paraissent chaque semaine. Intégrez dans votre module un exercice de veille ponctuel : donner aux étudiants une liste de dépendances courantes et leur demander de vérifier leur état de sécurité actuel via les bases NVD, GitHub Advisory ou OSV.dev. Cette habitude de vérification régulière est une compétence de terrain autant qu'une compétence académique.
Ce qu'il faut retenir
- La sécurité de la supply chain logicielle est devenue une compétence professionnelle incontournable, portée par les incidents réels (SolarWinds, XZ Utils) et le cadre réglementaire européen (CRA, NIS2).
- Ce module s'enseigne après les fondamentaux du secure coding et en lien direct avec le DevSecOps : il complète, sans remplacer, les enseignements existants.
- Les trois capacités à développer sont : générer un SBOM, réaliser un audit de dépendances avec priorisation, et intégrer un security gate dans un pipeline CI/CD.
- Les outils open source disponibles (Trivy, Syft, OWASP Dependency-Check) sont matures, documentés et adaptés à un usage pédagogique sans coût de licence.
Vous souhaitez intégrer un module supply chain dans votre cursus ou trouver un formateur maîtrisant les pratiques DevSecOps actuelles ? Cyber Teachers met en relation les établissements avec des intervenants qui pratiquent ces sujets en conditions réelles.