Le SCA expliqué simplement

Internet est désormais partout dans nos vies. Les applications aussi : pour commander à manger, déclarer ses impôts, parler à sa famille.
Certaines ne sont pas très bien sécurisées… et un beau matin, on reçoit un mail qui nous annonce que nos informations ont fuité.

Le SCA (Software Composition Analysis, ou analyse de composition logicielle) inventorie les composants réutilisés par un logiciel et recherche leurs failles connues. Cet article explique comment ces composants arrivent dans une application, puis comment vérifier et traiter une alerte.

Un logiciel, c'est une suite d'instructions qu'un ordinateur exécute pour rendre un service : afficher une page, enregistrer une commande, envoyer un message. Une partie de ces instructions, le code, est écrite par l'équipe qui fabrique le logiciel.

Mais en informatique, les ingénieurs sont ingénieux (ou fainéants, au choix) : le but est de ne pas réinventer la roue.

Et ça tombe bien, parce que les bibliothèquesbibliothèques : des morceaux de logiciel écrits par d'autres, que l'on réutilise au lieu de les réécrire (on dit aussi « librairies »), des morceaux de code que d'autres développeurs ont déjà écrits et qu'on peut intégrer chez nous, répondent parfaitement à ce besoin.

Seulement… quand on importe une bibliothèque, on importe aussi ses faillesfailles : une erreur dans un logiciel qu'un attaquant peut utiliser pour lui faire faire ce qu'il ne devrait pas.

Le SCA aide à repérer ces failles dans ce qu'on importe. Il sert aussi à suivre les licences, mais ici, on parle des failles.

Astuce : les mots soulignés en pointillé ont une définition. Passez la souris dessus, ou touchez-les sur un téléphone.

La partie émergée de l'iceberg

Quand on pense à une application, on pense au code que l'équipe a écrit : les écrans, les boutons, les règles du métier. C'est la partie émergée de l'iceberg.

Sous la ligne de flottaison, il y a tout ce qu'on a importé. Et c'est le gros morceau.

Chaque année, l'éditeur Black Duck passe au crible le code de centaines d'applications commerciales (965 dans son rapport 2025). Résultat : 97 % d'entre elles contiennent du code librecode libre : du code publié librement, que tout le monde peut lire, utiliser et modifier (on dit aussi open source), et en moyenne, 70 % de leur code est du code libre venu de l'extérieur.

Les applications analysées embarquent en moyenne 911 composants libres. L'édition 2026 confirme : 98 %, et 1 180 composants en moyenne.

Autrement dit, surveiller le code maison ne couvre qu'une partie de l'iceberg.
Et comme l'a appris le Titanic, ce n'est pas la partie visible qui coule le bateau.

Le gâteau et la liste des ingrédients

Imaginez une pâtisserie qui fabrique cinquante gâteaux différents. Un jour, le fournisseur de farine annonce qu'un lot est contaminé. Deux façons de réagir :

Une application, c'est pareil.
La farine, c'est une bibliothèque.

La liste des ingrédients s'appelle un SBOM (les spécialistes parlent aussi de nomenclature logicielle : SBOMSBOM : Software Bill of Materials : la liste de courses du développeur, avec chaque brique et sa version, de l'anglais Software Bill of Materials). Elle note aussi les versions, l'équivalent des numéros de lot.

C'est en quelque sorte la liste de courses du développeur : tout ce qu'il a mis dans son panier, avec la marque et le lot. Sans elle, chaque alerte vire à la chasse au trésor.

Des poupées russes dans le gâteau

Revenons en cuisine. Pour un gâteau, la pâtisserie ne fait pas tout elle-même : elle achète une pâte à tartiner, des biscuits, un glaçage.

Le biscuit, lui, contient des pépites de chocolat. Les pépites contiennent un émulsifiant, la lécithine de soja (E322).

Et ainsi de suite.

C'est une matriochka : on ouvre une poupée, il y en a une plus petite dedans, puis une autre, puis une autre. Un logiciel est construit de la même façon :

• La touche maison : notre code.
• Les préparations qu'on a choisies : les bibliothèques que l'équipe a ajoutées elle-même, qu'on appelle les dépendances directesdépendances directes : les bibliothèques que l'équipe a choisies et déclarées elle-même.
• Tout ce qu'elles ont apporté avec elles, poupée après poupée : les dépendances transitivesdépendances transitives : les bibliothèques qui arrivent avec celles que l'équipe a choisies.

La plus petite poupée, celle tout au fond, personne ne l'a vraiment choisie.
Elle est venue avec le reste. D'après le rapport 2025, près de deux composants sur trois (64 %) arrivent ainsi, sans que l'équipe les ait demandés.

Et les attaquants l'ont très bien compris.

Quand l'attaque passe par la porte de service

Ces dernières années, plusieurs attaques marquantes sont entrées là où personne ne regardait, au fond de la matriochka. Il y a deux familles : la faille involontaire, une erreur dans une brique honnête, et la brique piégée exprès.

1. 2021
   Log4Shell : la faille dans le carnet de bord.

   Log4j est une brique qui tient le journaljournal : le carnet où un programme note tout ce qui se passe : qui s'est connecté, quelle erreur est survenue d'une application. En décembre 2021, on découvre que sur une application vulnérable, un simple texte piégé, tapé dans un formulaire ou dans le chat d'un jeu, pouvait suffire à lui faire exécuter le programme d'un attaquant.

   Note de gravité : 10 sur 10. Même Minecraft était concerné.

   Et beaucoup d'équipes touchées n'avaient jamais choisi Log4j : il était arrivé, au fond de l'étiquette, avec une autre brique.

2. 2024
   xz : la poupée qu'on n'avait jamais ouverte.

   xz est un petit outil de compression présent dans de nombreuses versions de LinuxLinux : un système d'exploitation libre, présent sur la plupart des serveurs.

   Son mainteneurmainteneur : la personne qui entretient un projet open source : elle relit les propositions, décide de ce qui entre dans le code et publie les nouvelles versions, celui qui accepte les modifications et publie les versions, était un seul bénévole débordé, Lasse Collin.

   Un contributeur, Jia Tan, gagne sa confiance avec des corrections sérieuses, pendant que des comptes inconnus le pressent de passer la main. Jia Tan devient mainteneur à son tour, puis glisse en 2024 une porte dérobéeporte dérobée : un accès secret caché dans un logiciel, qui laisse entrer celui qui l'a posé dans deux versions, cachée hors du code que les autres relisaient.

   Qui se cachait derrière le pseudonyme Jia Tan ? On ne le sait toujours pas.

   Et xz sert à beaucoup d'outils standards de Linux, dont certains qui administrent les serveurs à distance : le piéger, c'était viser d'un coup une grande partie d'Internet. Un ingénieur, Andres Freund, intrigué par des connexions anormalement lentes (environ une demi-seconde de trop), tire le fil et révèle la porte dérobée le 29 mars 2024, avant qu'elle n'atteigne les versions stables des grandes distributions.

   Une demi-seconde de lenteur : c'est à ça qu'a tenu la découverte.

3. 2025
   chalk et debug : deux heures, deux milliards.

   Le 8 septembre 2025, le responsable de plusieurs briques JavaScriptJavaScript : le langage des pages web, aussi très utilisé côté serveur très populaires reçoit un faux mail lui demandant de réinitialiser sa double authentificationdouble authentification : une seconde vérification en plus du mot de passe, par exemple un code reçu sur le téléphone. Il tombe dans le piège.

   Les attaquants publient aussitôt des versions piégées de 18 bibliothèques, dont chalk (qui met de la couleur dans les messages) et debug, des bibliothèques téléchargées d'habitude plus de 2 milliards de fois par semaine à elles toutes. Le code ajouté tentait de détourner des paiements en cryptomonnaie dans le navigateur des visiteurs.

   La supercherie est repérée et les versions piégées retirées en environ deux heures. Mais chalk arrive très souvent indirectement, en passager clandestin, dans les bagages de centaines d'autres outils.

   Et si une version piégée a tourné chez vous, cherchez aussi ce qu'elle a pu faire.

4. 2026
   OpenAI : une image, trois poupées.

   Le 25 juillet 2026, des chercheurs de la société Hacktron envoient une image spécialement piégée sur le forum d'OpenAI. Le forum utilise le logiciel Discourse, qui confie les images au format HEIC à ImageMagick, qui les confie lui-même à une petite bibliothèque, libheif.

   C'est cette dernière, trois étages plus bas, qui contenait la faille. Combinée à un réglage de connexion défectueux, elle leur a permis, selon Hacktron, de démontrer un accès sensible, sans lire le code interne.

   Heureusement, c'étaient des chercheurs : ils l'ont signalé via le programme de récompenseprogramme de récompense : une entreprise paie les chercheurs qui lui signalent une faille (bug bounty en anglais) d'OpenAI, qui a confirmé sa correction environ 14 heures plus tard.

Le point commun :à chaque fois, beaucoup de victimes n'avaient jamais choisi la brique fautive.
Elle était entrée par la bande, comme au billard.

Et il y a pire que la brique honnête piégée de l'intérieur : la brique malveillante dès le départ. Des attaquants publient des briques au nom presque identique à une brique célèbre, en comptant sur une faute de frappe, ou au nom qu'un assistant d'IA invente parfois (une étude sur 16 modèles en a relevé plus de 200 000).

Un outil qui compare aux failles connues ne les repère pas toujours : vérifier ce qu'on installe reste indispensable.

Bon, concrètement, un SCA fait quoi ?

Imaginez un service de rappel de produits, mais pour les briques logicielles. Il fait quatre choses :

• Il dresse l'inventaire.Il déballe chaque carton qu'il sait lire, jusqu'au fond, et note chaque brique avec son numéro de version.
• Il compare aux failles connues.La plupart des failles connues reçoivent un numéro, une CVECVE : Common Vulnerabilities and Exposures : un numéro unique, comme CVE-2021-44228, qui désigne une faille connue, et les briques piégées sont signalées dans des bases de vulnérabilitésbases de vulnérabilités : des catalogues publics de failles connues, comme la NVD ou OSV : pour chaque faille, les versions touchées et la façon de corriger. L'outil cherche vos briques dedans.
• Il trie.Trois cents alertes, ça ne se traite pas en même temps. Il aide à choisir par où commencer.
• Il surveille.Une brique saine aujourd'hui peut être épinglée demain. Le contrôle se refait donc en continu, pas une fois par an.

Et ce qu'il ne sait pas faire : deviner une attaque que personne n'a encore découverte. Un outil qui se contente des failles déjà publiées ne voit une brique piégée qu'une fois qu'elle y est référencée : pour chalk, des outils spécialisés l'ont repérée en quelques minutes, les bases publiques un peu plus tard.

Un SCA raccourcit le temps entre l'alerte et la réaction, il ne lit pas l'avenir.

Corriger, c'est mettre à jour… puis mettre en service

La réparation, c'est presque toujours une nouvelle version de la brique, publiée par ses auteurs. Elle se fait en quatre temps :

1. Jour 0

   La faille est annoncée, le plus souvent avec une version corrigée.

2. Étape 1

   L'équipe met à jour la brique dans son projet, ou celle qui l'apporte.

3. Étape 2

   On vérifie que tout marche encore (une mise à jour peut casser autre chose, sinon ce serait trop facile).

4. Étape 3

   On met la nouvelle version en service. Tant que ce n'est pas fait, le site que voient vos visiteurs tourne toujours avec l'ancienne brique.

À retenir :« corrigé dans le projet » ne veut pas dire « corrigé chez les utilisateurs ». Quand on vous dit que c'est réparé, demandez la date de mise en servicemise en service : le moment où la nouvelle version tourne sur les serveurs que voient vos visiteurs.

Toutes les alertes ne se valent pas

Retour en cuisine, une dernière fois. Un soda qui contient de la vitamine C (E300) et du benzoate (E211) peut former du benzène, surtout s'il chauffe au soleil ; avoir les deux dans la bouteille ne suffit pas.

Les failles, c'est pareil : la liste dit ce qui est présent, pas ce qui réagit chez vous.

Log4Shell, par exemple, ne se déclenchait que si l'application notait dans son journal un texte venu de l'extérieur. Une équipe qui avait vérifié que rien de tel n'arrivait jusqu'à Log4j avait la brique, mais pas le mélange dangereux.

Elle devait mettre à jour quand même, mais avec moins d'urgence.

C'est là qu'est le vrai travail. L'inventaire, un outil le fait vite.
Savoir lesquelles de ces alertes réagissent vraiment chez vous, c'est une autre paire de manches. Quatre questions aident à trier :

Et quand l'outil se trompe

Comme tout outil de détection, un SCA peut se tromper dans les deux sens :

Mais « on ne s'en sert pas » reste une analyse, pas une certitude : on l'écrit, on la date, et on met à jour quand même dès que possible. Une équipe noyée sous les alertes finit par ne plus les lire, et c'est là que la vraie passe entre les mailles.

D'où viennent ces alertes qui ne vous concernent pas ? Mauvaise brique, bonne brique sans danger chez vous, ou doute à lever. Le plus souvent, de là :

• Le bon nom, mais une version inconnue.L'outil trouve la brique, mais pas sa version exacte, par exemple parce que le projet n'a pas de fichier de verrouillagefichier de verrouillage : un fichier qui fige la version exacte de chaque brique installée ou ne déclare qu'une plage comme « 2.x ». Dans le doute, il alerte.
• Un homonyme.Deux briques portent le même nom, et l'outil confond la vôtre avec celle qui a la faille.
• Déjà corrigé en douce.Certaines distributions Linux corrigent une faille en gardant le numéro de version d'origine (seul un suffixe du paquet change) : sur le papier, la version a l'air vulnérable, en vrai elle ne l'est plus.
• La partie fautive ne sert pas.La brique est bien là, mais aucun appel à la fonction concernée n'a été trouvé dans le périmètre vérifié.

Ce que le SCA ne couvre pas à lui seul

Le SCA regarde les briques qu'on réutilise, c'est-à-dire la partie immergée de l'iceberg. Pour le reste, il faut d'autres outils :

À vous de jouer : chef en crise

Vous avez maintenant toutes les cartes en main : on passe en cuisine. Vous tenez la pâtisserie pendant cinq jours, et chaque matin un avis de rappel tombe.

Votre liste de courses (le SBOM) vous montre ce qui correspond. À vous de décider quoi faire : chaque choix protège vos clients… ou remplit la poubelle.

Morale de l'histoire : trouver l'ingrédient, la liste le fait toute seule.
Décider quoi en faire, c'est là que se joue tout le reste.

Petit quiz

Les questions qu'on se pose

Pour conclure

Une application est faite en grande partie de briques écrites par d'autres, et leurs failles deviennent les vôtres. Un SCA tient la liste de ces briques et vous prévient quand l'une d'elles est signalée ; le vrai travail commence ensuite : vérifier si la faille vous touche, mettre à jour, puis mettre en service. Gardez en tête les trois questions du début : la liste complète, le délai de réaction, et la preuve que la faille vous concerne ou non.

Les mots de cet article · 8 mots

SCA

Software Composition Analysis : l'analyse des briques réutilisées par une application, pour y repérer les failles connues.

Bibliothèque

Un morceau de logiciel écrit par d'autres, que l'on réutilise.

Dépendance directe

Une brique choisie et déclarée par l'équipe.

SBOM

La liste des ingrédients d'un logiciel, de l'anglais Software Bill of Materials.

CVE

Le numéro unique attribué à une faille connue, comme CVE-2021-44228.

Dépendance

Une brique dont votre application a besoin.

Transitive

Synonyme de « indirecte », la dépendance d'une dépendance.

Fichier de verrouillage (lockfile)

Un document qui fige les versions exactes utilisées, pour que tout le monde installe la même chose.

Pour aller plus loin : pour voir ce que donne chaque niveau d'analyse sur une même application, et quelles sont les limites de ces analyses, lisez l'article approfondi.

Lire ensuite : SCA : de l'inventaire à la priorité