SCA (Software Composition Analysis)
La SCA inventorie les dépendances open source d'une application et les confronte aux vulnérabilités connues et aux risques de chaîne d'approvisionnement.
La Software Composition Analysis, ou SCA, s'intéresse à tout le code que vous n'avez pas écrit. Une application moderne est composée en grande majorité de dépendances open source, directes et transitives ; l'outil de SCA les inventorie, les confronte aux bases de vulnérabilités connues, et signale les composants à mettre à jour. Les plus complets vérifient aussi les licences et les signaux de compromission d'un paquet.
L'enjeu dépasse la simple CVE oubliée. Les attaquants ont compris qu'il est plus rentable de piéger une dépendance populaire que d'attaquer chaque application une à une : paquets malveillants publiés sous des noms proches de projets légitimes, comptes de mainteneurs compromis, code hostile glissé dans une mise à jour. La SCA est la première ligne de défense contre ces attaques supply chain, et la SBOM en est le prolongement documentaire.
Notre module de SCA AI-native va au-delà de l'inventaire : il évalue si votre code appelle réellement la fonction vulnérable, pour que vous corrigiez d'abord ce qui vous expose vraiment.
L'inventaire des composants devient une obligation
Le sujet sort du domaine de la bonne pratique. Le Cyber Resilience Act impose aux fabricants de produits numériques vendus dans l'Union de tenir une SBOM et de livrer sans vulnérabilité connue exploitable. La directive NIS2 range la sécurité de la chaîne d'approvisionnement parmi les mesures attendues à l'article 21.2. Aux États-Unis, l'executive order 14028 avait ouvert la voie dès 2021 en exigeant une SBOM des fournisseurs de l'État fédéral. Le point commun de ces textes : il faut pouvoir répondre sur pièce, et rapidement, à la question de savoir ce qu'il y a dans le logiciel.
Le piège de la vulnérabilité non atteignable
Une alerte SCA dit qu'une version vulnérable est présente, pas que la faille est exploitable chez vous. La bibliothèque peut être installée sans que votre code appelle jamais la fonction concernée, ou n'être chargée qu'en développement. Traiter les deux cas au même rythme épuise l'équipe et retarde ce qui compte vraiment. L'analyse d'atteignabilité, qui vérifie si le chemin d'appel existe réellement, change l'ordre de la file d'attente sans rien retirer de la liste. Car la mise à jour finit par arriver de toute façon : une dépendance non atteignable aujourd'hui le devient au prochain refactoring, et personne ne relira l'analyse ce jour-là.
Questions fréquentes
SCA et SAST, quelle différence ?
Le SAST analyse le code écrit par vos équipes, la SCA analyse le code que vous avez importé. Les deux sont complémentaires : dans une application moderne, la majorité des lignes livrées viennent des dépendances.
Faut-il mettre à jour toutes les dépendances vulnérables ?
À terme oui, mais pas dans le même temps. On traite d'abord ce qui est atteignable depuis une entrée exposée, puis ce qui figure au catalogue KEV des vulnérabilités exploitées, puis le reste au rythme des mises à jour de routine.
La SCA couvre-t-elle les images de conteneurs ?
Les outils sérieux le font : ils analysent les couches d'image et les paquets système en plus des dépendances applicatives. C'est indispensable, parce qu'une image de base obsolète embarque souvent plus de vulnérabilités connues que le code métier lui-même.