Qu'est-ce que l'analyse de la composition logicielle (SCA) ?

Comment fonctionne le SCA

1. Identifier les composants. L'outil lit ce vers quoi on le dirige : manifestes et lockfiles d'un dépôt, paquets installés, ou contenu d'une image de conteneur ou d'un binaire. Le résultat est un inventaire de composants et de versions, souvent exporté sous forme de SBOM.
2. Les confronter aux risques connus. Chaque composant est recherché dans des bases de données de vulnérabilités telles que la GitHub Advisory Database, OSV et la NVD, et sa licence déclarée est comparée à votre politique.
3. Prioriser. Les résultats sont classés par sévérité, et certains outils ajoutent l'analyse d'atteignabilité pour vérifier si votre code peut effectivement appeler la fonction vulnérable.
4. Corriger. De nombreux outils suggèrent une version corrigée ou ouvrent une pull request, comme le font Dependabot et Renovate. Pour une dépendance transitive vulnérable, la correction se situe généralement dans le paquet qui l'entraîne, ce que montre un graphe de dépendances.

Ce que le SCA détecte

• Les vulnérabilités connues des versions que vous utilisez, avec les avis de sécurité qui les décrivent.
• Le risque lié aux licences, comme une licence copyleft dans un produit propriétaire.
• Les paquets obsolètes et non maintenus qui ne recevront pas de correctifs de sécurité.
• Les paquets malveillants, dans les outils qui analysent aussi le comportement des paquets au lieu de se contenter de rapprocher les avis de sécurité.

SCA vs SAST

Le SCA et les tests statiques de sécurité applicative (SAST) sont souvent vendus ensemble, mais ils examinent un code différent et répondent à des questions différentes.

	SCA	SAST
Ce qu'il analyse	Les composants open source et tiers dont vous dépendez	Le code écrit par votre équipe
Ce qu'il détecte	Vulnérabilités connues, problèmes de licence, paquets obsolètes	Failles de votre code, comme les injections ou le traitement non sécurisé des entrées
Ce qu'il lit	Manifestes, lockfiles, paquets installés, images ou binaires	Code source
Ce qui fait apparaître un nouveau résultat	Un changement de dépendance, ou un nouvel avis de sécurité sur une version que vous livrez déjà	Un changement dans votre code
Sortie habituelle	Composants vulnérables avec leurs versions corrigées, et une SBOM	Emplacements de la faille dans le code et correction suggérée

Il vous faut les deux. Une base de code sans résultat SAST peut tout de même livrer une dépendance vulnérable, et un arbre de dépendances sain ne dit rien de votre propre code. Voir SAST vs SCA pour la comparaison complète. Une différence compte pour la façon de les exécuter : un résultat SAST apparaît lorsque votre code change, alors qu'un résultat SCA peut apparaître sur une release livrée il y a des mois, le jour où un nouvel avis de sécurité est publié.

Où s'arrête le SCA

Tout résultat SCA dépend de la première étape : l'identification des composants. Un composant que l'outil n'a jamais identifié ne peut être ni rapproché, ni priorisé, ni corrigé, et il n'apparaît pas non plus comme une lacune. Les angles morts courants :

• Ce que les fichiers ne disent pas. La plupart des outils SCA lisent les manifestes et les lockfiles. Un lockfile manquant ou périmé, les paquets restaurés depuis les caches CI, les outils de build, les téléchargements et les scripts d'installation n'atteignent jamais l'inventaire. Voir pourquoi un lockfile n'est pas un enregistrement de ce qui a été livré.
• Les outils se contredisent. Deux scanners dirigés vers le même commit renvoient des listes de composants différentes, car chacun a ses propres règles sur ce qu'il faut lire et sur la façon de le nommer. Voir ce qui échappe aux générateurs de SBOM open source.
• Les binaires. Un logiciel distribué sous forme de binaire précompilé ne déclare que peu de choses, voire rien, qu'un lecteur de manifestes puisse voir.
• Uniquement les vulnérabilités connues. Le rapprochement trouve ce qui a été publié. Un nouveau paquet malveillant ou une faille non divulguée n'a pas encore d'avis de sécurité.
• Un instantané. Un scan dans une pull request décrit ce moment-là. Les nouveaux avis de sécurité sur des versions déjà en production exigent quelque chose qui continue de vérifier ce qui a été livré.

Ce n'est pas le défaut d'un produit en particulier. C'est ainsi que fonctionne le scan, commercial ou open source. CRACI a trouvé des paquets vulnérables que Snyk et Aikido n'avaient pas signalés, parce que ces composants n'avaient jamais figuré dans ce qu'ils avaient scanné.

Enregistrez le build, gardez votre SCA

CRACI comble la lacune d'identification du côté du build. C'est un runner GitHub Actions qui enregistre chaque paquet récupéré par chaque job, à tous les niveaux de l'arbre, y compris les paquets restaurés depuis les caches CI, dans une SBOM qui indique sa propre complétude. Il continue de réévaluer les SBOM de ce qui a été livré à mesure que de nouvelles vulnérabilités sont publiées, et l'historique des builds montre quels builds passés contenaient un paquet vulnérable.

CRACI ne fait ni SAST ni analyse d'atteignabilité, et c'est un choix de conception. Les équipes l'exécutent à côté d'un outil SCA ou SAST qui couvre les pull requests et leur propre code. Voir le comparatif des outils SCA, la place de CRACI à côté de vos outils SCA, ou réservez une démo pour comparer une SBOM enregistrée avec votre scan actuel.

Analyse de la composition logicielle : questions fréquentes

Qu'est-ce que le SCA en cybersécurité ?

L'analyse de la composition logicielle (SCA) est la pratique qui consiste à trouver les composants open source et tiers de votre logiciel et à y rechercher les vulnérabilités connues, les problèmes de licence et les versions obsolètes. Elle couvre le code dont vous dépendez, par opposition au code que vous écrivez.

Quelle est la différence entre le SCA et le SAST ?

Le SAST analyse le code écrit par votre équipe pour y trouver des failles telles que des bugs d'injection. Le SCA analyse les composants dont vous dépendez pour y trouver des vulnérabilités connues et des problèmes de licence. Ils répondent à des questions différentes : la plupart des programmes de sécurité exécutent donc les deux.

Que signifie « scan SCA » ?

Un scan SCA lit les manifestes, les lockfiles, les paquets installés ou l'image de conteneur d'un projet, détermine quels composants il contient et les confronte aux données de vulnérabilité et de licence. Il en ressort une liste de résultats, souvent accompagnée d'une SBOM des composants identifiés.

Une SBOM est-elle la même chose que le SCA ?

Non. Une SBOM est un inventaire : la liste des composants d'une release. Le SCA est l'analyse : identifier les composants et y rechercher les risques. De nombreux outils SCA produisent une SBOM en cours de route, et une SBOM peut alimenter la surveillance des vulnérabilités après la release.

Quelles sont les limites du SCA ?

Il n'analyse que les composants qu'il peut identifier, généralement à partir des manifestes et des lockfiles. Les paquets restaurés depuis les caches CI, les outils de build, les téléchargements et les binaires sans métadonnées de paquet peuvent lui échapper. Il trouve les vulnérabilités connues, pas les inconnues, et un scan est un instantané, sauf si l'outil continue de revérifier ce qui a été livré.

Quels sont les meilleurs outils SCA ?

Cela dépend de vos besoins au-delà des bases : analyse d'atteignabilité, détection des paquets malveillants, politique de licences ou workflow des développeurs. Consultez notre comparatif de 13 outils SCA pour voir ce que chacun couvre et où il s'arrête.