Menu
Mais Encore

Security musings

🔥 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, de VOTRE environnement de build et d’execution et de VOTRE code.”
– PandaHack (2021)

LinkedIn Reddit