Qu'est-ce que l'analyse de composition logicielle (SCA) et pourquoi est-elle essentielle ?
Réponse courte
La SCA inventorie les composants open-source et tiers qu'une application embarque — y compris les dépendances transitives — et signale ceux qui présentent des CVE connues ou des licences problématiques. Elle compte parce que la majeure partie du code moderne, ce sont des dépendances que vous n'avez pas écrites, et un seul paquet transitif vulnérable (comme Log4j) peut exposer toute l'application. Une bonne SCA priorise par accessibilité et exploitabilité, pas par simple décompte brut de CVE.
Les applications modernes sont majoritairement du code écrit par quelqu'un d'autre. L'analyse de composition logicielle (SCA) est la façon dont vous gardez la trace de ce code et du risque qu'il porte.
Ce que fait la SCA
Un outil de SCA analyse vos manifestes et fichiers de verrouillage (package-lock.json, pom.xml, go.sum, etc.) pour construire un inventaire de chaque composant open-source que vous distribuez. Il croise ensuite chaque composant et version avec des bases de données de vulnérabilités (la NVD, les GitHub Advisories, les flux éditeurs) pour signaler les CVE connues, et vérifie les licences déclarées afin que les composants à risque juridique (par exemple un copyleft fort dans un produit propriétaire) ressortent tôt.
Pourquoi c'est essentiel
La raison majeure tient aux dépendances transitives : les bibliothèques dont dépendent vos bibliothèques. Vous pouvez tirer 20 paquets directs et en hériter 800 transitifs. Vous ne les avez jamais choisis, vous les auditez rarement, et une faille au fond de cet arbre — Log4Shell étant l'exemple canonique — peut compromettre une application dont le code propre est irréprochable. La SCA est le seul moyen pratique de savoir ce qui se trouve réellement dans votre build.
Bien le faire
Les décomptes bruts de CVE submergent les équipes. Une SCA mature priorise par accessibilité (la fonction vulnérable est-elle réellement appelée ?), exploitabilité (existe-t-il un exploit connu, un chemin exposé à Internet ?) et gravité — pas seulement par le décompte. Elle s'exécute en CI pour qu'une CVE nouvellement divulguée dans une dépendance existante fasse échouer le build, et elle alimente le SBOM afin de répondre en quelques minutes à « sommes-nous affectés ? » lorsque la prochaine grande vulnérabilité tombe.
Ce que recherchent les recruteurs
Ils veulent que vous insistiez sur les dépendances transitives, que vous reliiez la SCA à la rapidité de la réponse à incident, et que vous montriez que vous trieriez par accessibilité plutôt que de noyer les développeurs sous le bruit.
Questions de suivi probables
- Pourquoi les dépendances transitives sont-elles la partie difficile ?
- Comment prioriseriez-vous des centaines de résultats SCA ?
- Quel est le lien entre la SCA et un SBOM ?