🔥 OWASP Top 10 2025 : La Chaîne d’Approvisionnement Prend le Podium ! 🥉

Catégories

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

L’OWASP Top 10 2025 RC1 est sorti le 6 novembre ! 🎉
La grande star de cette édition ? A03: Software Supply Chain Failures 📦 qui grimpe de A06 en 2021 jusqu’au podium.
Les attaquants adorent empoisonner nos dépendances, alors autant comprendre ce qui a changé !

🎯 OWASP Top10 - Introduction

Le 6 novembre 2025, l’OWASP a publié la Release Candidate 1 du Top 10 2025 📝.
Cette édition est basée sur l’analyse de :

  • 2,8 millions d’applications testées 🔬
  • 589 CWEs (Common Weakness Enumerations) cartographiées
  • 175 000 enregistrements CVE analysés
  • 12 organisations contributrices (dont Veracode, Snyk, HackerOne…)

💡 Fun fact : L’OWASP Top 10 n’est PAS un simple classement de fréquence. C’est une approche “data-informed, not data-driven” qui mélange données terrain ET préoccupations de la communauté. Comme un bon vin ! 🍷

📊 Tableau Comparatif 2021 vs 2025

Voici ce qui a bougé entre les deux éditions :

Position 2025 Catégorie 2025 Position 2021 Catégorie 2021 Évolution
A01 🔐 Broken Access Control (inclue le A10-2021 - Server-Side Request Forgery (SSRF) A01 🔐 Broken Access Control + Server-Side Request Forgery (SSRF) ➡️ Stable #1
A02 ⚙️ Security Misconfiguration A05 ⚙️ Security Misconfiguration ⬆️ +3
A03 📦 Software Supply Chain Failures A06 🧩 Vulnerable & Outdated Components ⬆️ +3 🔥
A04 🔑 Cryptographic Failures A02 🔑 Cryptographic Failures ⬇️ -2
A05 💉 Injection A03 💉 Injection ⬇️ -2
A06 🎨 Insecure Design A04 🎨 Insecure Design ⬇️ -2
A07 👤 Authentication Failures A07 🆔 Identification & Authentication Failures ➡️ Stable (renommé)
A08 ✅ Software & Data Integrity Failures A08 ✅ Software & Data Integrity Failures ➡️ Stable
A09 📝 Logging & Alerting Failures A09 📋 Security Logging & Monitoring Failures ➡️ Stable (renommé)
A10 ⚠️ Mishandling of Exceptional Conditions — — 🆕 Nouveau

🎪 Les Changements Clés

📌 Ce qu’il faut retenir :

  • A03 (Supply Chain) : Expansion majeure de A06:2021 → Reconnaissance de la menace croissante (j’en parle depuis longtemps, la supply chain, n’est pas juste les dépendances obsolètes !, mais toute la chaîne de livraison)
  • A02 (Misconfiguration) : Monte de #5 à #2 → DevOps rapide = erreurs de config fréquentes
  • A10 (Exceptional Conditions) : Nouveau venu → Gestion d’erreurs = vecteur d’attaque oublié
  • A01 (Access Control) : Toujours #1 → Classic jamais has-been (3,73% de prévalence)

🔥 Focus : A03 - Software Supply Chain Failures

🎭 De “Composants Vulnérables” à “Échec de la Chaîne d’Approvisionnement”

En 2021, A06 parlait de “Vulnerable and Outdated Components” 🧩.
En 2025, A03 élargit le scope à toute la chaîne d’approvisionnement logicielle 📦.

Pourquoi ce changement ?

  • SolarWinds (2020) : Compromission build → 18 000 clients infectés 😱
  • Log4Shell (2021) : Vulnérabilité critique dans une dépendance ultra-populaire
  • XZ Utils (2024) : Backdoor cachée dans une bibliothèque de compression Linux
  • Shai-Hulud Worm (Septembre 2025) : Ver auto-réplicant sur npm infectant 187+ packages

💡 Ce qui a changé :

L’OWASP reconnaît désormais que le problème ne se limite PAS à :

  • ✅ Garder vos dépendances à jour
  • ✅ Scanner les CVE connues

Mais inclut AUSSI :

  • 🔍 La provenance du code (d’où vient-il ?)
  • 🛡️ L’intégrité des artefacts (a-t-il été modifié ?)
  • 🔐 La sécurité des pipelines CI/CD (qui peut toucher au build ?)
  • 🕵️ Les dépendances transitives (qu’est-ce qui se cache dans la dep de ma dep ?)

💣 Exemples Récents d’Attaques SCA avérées

🪱 Septembre 2025 : Shai-Hulud Worm sur npm (Source: KrebsOnSecurity)

Le ver qui rêvait de devenir viral 🐛

  • Vecteur : Ver auto-réplicant JavaScript via npm
  • Cibles : 187+ packages infectés (dont 25 packages CrowdStrike temporairement)
  • Mécanisme :
    1. 🔑 Vole les tokens npm dans l’environnement du développeur
    2. 📦 Modifie automatiquement les 20 packages les plus populaires accessibles
    3. 🔄 Se copie dans les nouvelles versions publiées
    4. 🚀 Publie les credentials volés dans des repos GitHub publics nommés “Shai-Hulud”
  • Particularité : Utilise l’outil open-source TruffleHog pour chercher les secrets 🕵️
  • Impact : Propagation exponentielle, difficile à contenir une fois lancé

🎬 Fun fact : Le nom “Shai-Hulud” vient des vers de sable géants de Dune de Frank Herbert.
Les attaquants sont aussi fans de SF ! 🪐

🎨 2024 : XZ Utils Backdoor (Source: Multiple CVE databases)

L’attaque la plus sophistiquée jamais vue 🏆

  • CVE : CVE-2024-3094 (CVSS 10.0 - CRITIQUE)
  • Vecteur : Compromission long terme d’un mainteneur de bibliothèque Linux
  • Technique : Backdoor cachée dans les fichiers de test (!!) activable via SSH
  • Détection : Par accident, grâce à un développeur Microsoft qui a remarqué un délai SSH bizarre
  • Impact potentiel : Presque tous les systèmes Linux dans le monde 🌍

⏰ Timeline de patience de l’attaquant :

  • 2022 : Premier contact avec le mainteneur légitime
  • 2023 : Contributions bénignes pour gagner la confiance
  • Février 2024 : Injection de la backdoor dans les versions 5.6.0 et 5.6.1
  • Mars 2024 : Découverte fortuite avant distribution massive

Morale : Les attaquants jouent le long terme. Nous aussi. ♟️

🛡️ Comment se Protéger des Attaques Supply Chain ?

📋 1. SBOM (Software Bill of Materials)

Générez un inventaire complet de vos dépendances :

# npm
npm sbom --output=sbom.json

# Python
pip-audit --format json --output sbom.json

# .NET
dotnet list package --include-transitive --format json

Pourquoi ? Vous ne pouvez pas protéger ce que vous ne connaissez pas ! 🕵️

🔐 2. SLSA Framework (Supply-chain Levels for Software Artifacts)

Implémentez des niveaux de confiance dans vos pipelines :

Niveau SLSA Protection Exemple
SLSA 1 📝 Documentation de provenance README avec process de build
SLSA 2 🔒 Builds signés Signature GPG des artefacts
SLSA 3 🏗️ Build isolés et auditables CI/CD hermétique, logs immuables
SLSA 4 ✅ Révision humaine obligatoire 2-person rule pour les merges

👉 Visez au minimum SLSA 2 pour vos projets critiques 🎯

🔍 3. Outils de Vérification Continue

🛠️ Ma Toolbox Anti-Supply-Chain :

  • OWASP Dependency-Track 📊
    Monitoring continu des SBOM avec alertes CVE en temps réel

  • Snyk 🔍
    Scan de vulnérabilités dans dépendances + suggestions de fix

  • Scorecard (OSSF) 📈
    Évaluation de la santé sécurité des dépendances open-source

🚦 4. Stratégies Défensives

A. Vérification à l’Installation

B. Isolation des Environnements de Build

C. Surveillance des Dépendances Transitives

📚 Ressources et Références

🔗 Documentation Officielle

🛠️ Outils et Frameworks

📰 Articles de Références

🎬 Conclusion : La Supply Chain, Nouveau Champ de Bataille ?

L’ascension de A03: Software Supply Chain Failures au podium du Top 10 n’est PAS un accident. 🎯

Les chiffres parlent d’eux-mêmes :

  • 📈 +742% d’attaques supply chain entre 2019 et 2024 (Sonatype)
  • 🎯 3 packages npm malveillants publiés par jour en moyenne (Socket.dev)
  • ⏱️ Temps médian avant détection : 83 jours (Veracode)

💡 La Morale de l’Histoire :

Nos applications modernes sont comme des Kinder Surprises 🥚 :

  • Vous voyez le chocolat (votre code)
  • Vous espérez le jouet (les features)
  • Mais vous ignorez ce qui se cache à l’intérieur de chaque composant…

Et parfois, le “jouet” c’est un ver auto-réplicant qui vole vos tokens 🪱

Action Items pour 2025 :

  1. ✅ Générez vos SBOM et gardez-les à jour
  2. 🔐 Visez SLSA Level 2+ pour vos builds critiques
  3. 🔍 Auditez vos pipelines CI/CD comme vous auditez votre code
  4. 📊 Monitorer en continu avec des outils type Dependency-Track
  5. 🎓 Formez vos équipes aux risques supply chain

“Dans le monde moderne, la sécurité de votre application dépend autant de la qualité de VOS dépendances que de VOTRE code.”
– PandaHack (2021)

LinkedIn Reddit