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

Les outils SCA fonctionnent en analysant le code source du logiciel, en le collectant dans une base de données, en le comparant à des bases de données de vulnérabilités connues, en vérifiant les mises à jour ou les problèmes de licence, puis en produisant un rapport. 

Bien que l'analyse de la composition des logiciels puisse porter sur tous les types d'éléments logiciels, y compris les composants propriétaires et les images de conteneurs, elle est le plus souvent utilisée pour analyser les bibliothèques open source. Les composants open source sont inclus dans une certaine mesure dans presque toutes les bases de code modernes, et comme les vulnérabilités de leur code sont connues de tous, il est particulièrement important de maintenir les logiciels open source à jour et transparents.

Les outils SCA permettent de gérer les risques liés aux vulnérabilités de sécurité des composants logiciels d'origine inconnue, aux problèmes de compatibilité entre les différentes licences open-source et à la documentation ou à l'assistance incomplète ou insuffisante pour les bibliothèques open-source.  

L'analyse de la composition des logiciels fait partie du pipeline  DevOps cloud-native qui intègre le processus de développement de logiciels aux opérations informatiques. Les SCA soutiennent également la posture de sécurité d' une organisation dans le cadre du pipeline DevSecOps, qui intègre la sécurité au développement et aux opérations. Les outils SCA peuvent être déployés dans un environnement de développement intégré (IDE), qui fournit une analyse du code en temps réel pendant le processus de développement.

Le SCA diffère des autres formes d'analyse de vulnérabilité telles que les tests statiques de sécurité des applications (SAST), les tests dynamiques de sécurité des applications (DAST) et l'analyse des dépendances.

Les équipes informatiques utilisent souvent les outils SCA pour générer une nomenclature logicielle (SBOM). Le SBOM répertorie tous les composants, bibliothèques et modules d’un produit logiciel dans un format lisible par une machine pour la conformité et la sécurité de la chaîne d’approvisionnement. Les SBOM peuvent également documenter les politiques d’analyse SCA.

Selon les données d’enquête de l’International Data Corporation, 93 % des entreprises comptant au moins 100 employés utilisaient des logiciels open source en 2024, soulignant ainsi le besoin généralisé de solutions SCA.¹

SCA fonctionne en collectant le code source, en le comparant à des bases de données de vulnérabilités, en analysant la base de code pour détecter d’éventuels problèmes de conformité, en supprimant les faux positifs et en rédigeant un rapport pour les équipes de cybersécurité et de développement. 

Les outils SCA scannent et analysent activement le code pendant le développement dans le cadre de l'intégration continue et de la livraison continue (CI/CD) tout au long du cycle de développement, en se concentrant principalement sur les composants open-source et les dépendances tierces.

Pour ce faire, les outils SCA listent d’abord les éléments de base de tous les logiciels de l’environnement informatique, y compris leurs composants, frameworks, bibliothèques, images de conteneurs, modules et dépendances. Les deux principales formes de balayage SCA sont : 

• L’analyse statique, ou analyse de manifeste, lit les fichiers de configuration et de métadonnées pour trouver les éléments qui y sont explicitement décrits.

• Analyse dynamique, ou d’exécution, qui identifie les bibliothèques au fur et à mesure de leur exécution en temps réel en analysant le code binaire. 

Les deux types de scans ont des avantages et des inconvénients. Une analyse statique peut inclure des vulnérabilités provenant de composants tiers dans le code source qui ne sont pas réellement déployés dans l’environnement d’exécution, ce qui crée de faux positifs. Une analyse dynamique, en revanche, peut ne jamais être totalement complète, car tous les éléments du code ne sont pas exécutés dans l'environnement d'exécution. De nombreuses organisations utilisent une combinaison des deux.

Une fois qu’un outil SCA a terminé de collecter le code, il crée une nomenclature logicielle (SBOM) et compare les composants du SBOM à des bases de données décrivant les vulnérabilités courantes et les risques de sécurité des logiciels modernes.

Les équipes de sécurité comparent le SBOM à la fois à des bases de données propriétaires de vulnérabilités connues et à des bases publiques telles que la National Vulnerability Database (NVD) ou la liste des Common Vulnerabilities and Exposures (CVE). Une fois les vulnérabilités potentielles signalées, l’outil SCA attribue à chacune un score de menace (souvent à l’aide du Common Vulnerability Scoring System (CVSS)) qui permet à l’équipe de cybersécurité de prioriser la résolution.

Certains outils de sécurité automatisent la gestion des vulnérabilités en appliquant le correctif ou la mise à jour appropriée dans le cadre du pipeline CI/CD. Les équipes de sécurité surveillent généralement ce processus pour s'assurer que les changements appliqués n'affectent pas les dépendances ou les fonctionnalités existantes.

Les outils SCA vérifient également la conformité du SBOM avec les politiques et les lois de l'entreprise en matière de licences logicielles.

L'Open Source Initiative répertorie plus de 100 licences open source approuvées, dont certaines permettent de créer des produits propriétaires à partir d'un code open source. Cependant, toutes ne sont pas compatibles, ce qui signifie que les organisations sont responsables de la conformité de leurs produits.

Les solutions SCA peuvent vérifier que tous les logiciels open source portent l’attribution requise, ou que les éléments soumis au « copyleft » — qui interdit leur utilisation dans des logiciels propriétaires protégés par droit d’auteur — ne sont pas inclus dans le développement de ce logiciel. 

L'analyse de la composition des logiciels permet également de détecter les dépendances entre les composants d'un projet, une source importante de vulnérabilités potentielles.

Les outils SCA peuvent détecter à la fois des dépendances directes — où les composants logiciels sont utilisés directement les uns par les autres au niveau du code — et les dépendances transitives. Une dépendance transitive se produit lorsqu’un logiciel devient indirectement dépendant d’un composant logiciel dont dépend l’une de ses dépendances directes. Par exemple : le composant A dépend du composant B, qui dépend du composant C. Dans ce scénario, le composant A dépend transitivement du composant C.

Les outils SCA doivent déterminer quelles dépendances introduisent des vulnérabilités et lesquelles n'en introduisent pas, afin de réduire le nombre de fausses alertes. Pour ce faire, ils évaluent la chaîne d'approvisionnement logicielle et déterminent si une vulnérabilité du code est « accessible », c'est-à-dire si elle sera appelée dans un environnement d'exécution compte tenu de la configuration actuelle du réseau. 

Les résultats de l'analyse de la composition des logiciels sont ensuite compilés dans un rapport et souvent présentés dans un tableau de bord propriétaire, des données brutes telles qu'un fichier JSON, un nouveau SBOM ou une combinaison des trois.

Ces dernières années, les développeurs ont fait des progrès en matière de réduction des faux positifs dans ces rapports.

• L'analyse des méthodes vulnérables retrace les chemins d'appel des composants logiciels pour s'assurer que les vulnérabilités détectées sont accessibles.

• Le Machine learning et l’intelligence artificielle ont contribué à l’identification des faux positifs. Avec une formation adéquate, les modèles peuvent déterminer avec précision si une vulnérabilité est accessible ou non. Le traitement automatique du langage naturel est également utilisé pour analyser les messages de validation de contrôle de version provenant de référentiels tels que GitHub, afin de détecter d’éventuels problèmes non identifiables dans le code. 

Certains outils SCA incluent des fonctionnalités de surveillance continue et de résolution automatique, qui intègrent davantage la pratique dans le workflow de développement DevSecOps. La correction automatique se fait généralement en lançant des pull requests qui demandent aux développeurs de résoudre les problèmes de licence ou d'appliquer de nouveaux correctifs de sécurité.

Les avantages de la SCA incluent une confiance accrue dans la conformité et la posture de cybersécurité de l’entreprise, ainsi qu’une automatisation accrue des workflows IT.

En veillant à ce que tous les composants open source de l'écosystème informatique soient utilisés conformément à leurs exigences de licences et de conformité, la SCA peut aider les entreprises à réduire les risques juridiques.

L'identification des vulnérabilités du réseau créées par l'imprévisibilité des composants logiciels open source est un élément crucial de la gestion des risques informatiques. En rendant la chaîne d'approvisionnement des logiciels libres plus transparente, les organisations peuvent profiter des avantages de la personnalisation et de la réduction des coûts tout en étant sûres d'avoir réduit les risques de sécurité qui en découlent.

En automatisant une grande partie du suivi des vulnérabilités, des dépendances et de la conformité, les solutions SCA permettent aux équipes informatiques de se consacrer à d'autres tâches. Cette automatisation poussée permet également de renforcer les pratiques DevOps d'une organisation.

Parmi les défis posés par l'analyse de la composition des logiciels, on peut citer le manque d'exhaustivité dans le suivi des vulnérabilités, la limitation des faux positifs et la gestion de la portée de l'analyse.

L'analyse de la composition des logiciels est différente de DAST et SAST, deux méthodes de test supplémentaires utilisées pour identifier les vulnérabilités de sécurité dans les applications modernes. 

Alors que SCA fournit aux équipes informatiques une carte complète des composants logiciels, dépendances et vulnérabilités, DAST et SAST se concentrent sur et révèlent les défauts individuels de ces composants ainsi que des applications logicielles plus larges qu’ils constituent.

La différence entre le DAST et le SAST est similaire à celle entre le scan statique et le scan dynamique en SCA. Les tests de sécurité dynamique des applications (DAST) évaluent les applications dans leurs environnements de production, en imitant les utilisateurs malveillants et les cyberattaques pour aider à identifier les problèmes de sécurité. Les tests statiques de sécurité des applications (SAST) plongent dans le code source d'une application, à la recherche de vulnérabilités dans le code tel qu'il est écrit.  

Alors que le SCA se concentre sur l'énumération et l'analyse des composants d'un logiciel donné, DAST et SAST sont spécifiquement axés sur le test de ce logiciel pour détecter les vulnérabilités en matière de sécurité, que ce soit au niveau de l'exécution dans le premier cas ou du code source dans le second. Les deux sont souvent utilisées conjointement avec la SCA, mais peuvent également être pratiquées indépendamment. 

SCA diffère du mappage des dépendances, le processus d’identification, de compréhension et de visualisation des relations entre les applications, les systèmes et les processus au sein des opérations informatiques d’une organisation.

Les outils SCA offrent un aperçu des dépendances des composants et identifient les vulnérabilités potentielles qui pourraient en découler, mais la cartographie des dépendances désigne une catégorie plus large de pratiques d’observabilité qui identifient les dépendances à travers l’ensemble de l’environnement informatique.

La cartographie des dépendances peut se concentrer sur les dépendances au sein et entre les applications, mais elle peut aussi aller plus loin, en cherchant des dépendances dans l’infrastructure réseau ou dans des systèmes réels entiers, comme un réseau électrique intelligent. La cartographie des dépendances est souvent un composant des pratiques SCA, mais peut être exécutée seule, indépendamment des solutions SCA.