Composants vulnérables et gestion des dépendances

Une application moderne est rarement écrite de zéro. Elle ressemble à une maison construite avec des éléments du commerce : fenêtres, portes, tuyaux, que l’on assemble. Chacun a été fabriqué par quelqu’un d’autre. Si un fabricant découvre qu’un modèle de serrure est défectueux et publie un rappel, il faut penser à remplacer la serrure de votre porte. En développement, ces éléments se nomment composants ou dépendances (bibliothèques, cadres de développement, modules, images de conteneurs). Cette leçon porte sur le risque de les laisser vieillir.

Pourquoi les composants sont un risque majeur

Quand une faille est découverte dans un composant très répandu, elle concerne toutes les applications qui l’utilisent, et son existence devient publique. Les attaquants n’ont plus besoin de chercher : ils scrutent Internet à la recherche des applications qui n’ont pas appliqué le correctif. Plusieurs grandes compromissions de ces dernières années ont suivi ce schéma : une faille connue, un correctif disponible, mais non appliqué à temps.

Il y a aussi une dimension de chaîne d’approvisionnement : un composant peut lui-même dépendre d’autres composants (dépendances transitives), que l’équipe n’a pas choisis directement et ne connaît parfois pas.

Comment les failles sont référencées

Les failles connues sont répertoriées de façon publique :

Vous retrouverez ces identifiants et ces notions de score de gravité au chapitre suivant. Pour l’instant, retenez qu’une version précise d’un composant peut être rapprochée d’une liste de CVE connues.

Inventorier : la première étape

On ne peut pas mettre à jour ce qu’on ne connaît pas. Le point de départ est un inventaire des composants utilisés, parfois appelé nomenclature logicielle (SBOM). Pour une application web, on regarde :

• les bibliothèques côté serveur, listées dans le fichier de dépendances du projet (par exemple un fichier qui énumère les paquets et leurs versions) ;
• les bibliothèques côté client (scripts du navigateur) ;
• le cadre de développement et le serveur web ;
• les systèmes et images de conteneurs sur lesquels l’application tourne ;
• les extensions et modules pour les systèmes de gestion de contenu.

Repérer les versions depuis l’extérieur

En test d’intrusion de type « boîte noire », on n’a pas le fichier de dépendances. Il faut déduire les composants à partir de signaux observables :

• les en-têtes de réponse qui annoncent serveur et langage (leçon précédente) ;
• les noms de fichiers de scripts chargés par les pages (certaines bibliothèques portent leur version dans le nom) ;
• les commentaires en tête de fichiers de bibliothèques ;
• les pages d’erreur par défaut d’un cadre de développement ;
• les chemins caractéristiques d’un produit connu.

Ces observations donnent une hypothèse : « l’application semble utiliser telle bibliothèque, dans une version antérieure à telle autre ». L’étape suivante est de consulter les bases publiques pour savoir si cette version est concernée par des failles connues. Un point d’honnêteté professionnelle : une version ancienne n’est pas automatiquement exploitable. Il faut vérifier si la fonction vulnérable est utilisée par l’application et si les conditions sont réunies. Un constat qui dit « version affectée par telle CVE » sans nuance, sans avoir vérifié, est un faux positif potentiel.

Les outils d’analyse de composition

Des outils d’analyse de composition logicielle (SCA) comparent automatiquement la liste des dépendances d’un projet à des bases de vulnérabilités. Beaucoup sont gratuits ou open source, et certains sont intégrés aux plateformes de développement. Ils produisent une liste de composants affectés, avec les versions corrigées. Utilisez-les sur votre propre code ou sur le code fourni par un client dans le périmètre. Ils sont très utiles, mais exigent le même esprit critique que les scanners : trier, vérifier, contextualiser.

Défendre : une hygiène des dépendances

• Tenir un inventaire à jour des composants et de leurs versions.
• Mettre à jour régulièrement, avec une procédure d’urgence pour les failles critiques.
• Automatiser la surveillance : alertes sur les nouvelles vulnérabilités des dépendances utilisées, analyse dans la chaîne d’intégration continue.
• Limiter les dépendances : chaque composant ajouté élargit la surface d’attaque ; supprimer ce qui ne sert plus.
• Choisir des composants maintenus : projet actif, communauté réactive, politique de publication de correctifs.
• Verrouiller les versions pour obtenir des constructions reproductibles et vérifier l’intégrité des paquets téléchargés.
• Isoler : exécuter l’application avec des privilèges limités pour réduire l’impact d’une faille dans un composant.
• Prévoir une fin de vie : planifier le remplacement des composants qui ne reçoivent plus de correctifs.

Les recommandations de l’ANSSI sur la maîtrise des mises à jour (cyber.gouv.fr) et les ressources de l’OWASP sur les dépendances (owasp.org) donnent un cadre éprouvé.

À vous de jouer

Exercice sur du code qui vous appartient ou sur l’application d’entraînement.

1. Si vous avez l’accès au code de votre application d’entraînement (Juice Shop, par exemple, est open source), repérez son fichier de liste de dépendances et choisissez trois composants. Notez leur nom et leur version.
2. Pour l’un d’eux, consultez la base publique des vulnérabilités (nvd.nist.gov) : existe-t-il des failles connues pour cette version ? Notez l’identifiant CVE, le résumé et la version corrigée.
3. Décrivez ce que vous feriez pour vérifier si la faille est réellement exploitable dans l’application.
4. Rédigez le constat et la recommandation de mise à jour.

Dans la leçon suivante, nous examinons une fonction qui introduit des fichiers extérieurs sur le serveur : l’envoi de fichiers.