Définition
L’analyse de composition logicielle (SCA) est l’utilisation d’outils automatisés pour identifier les composants open source dans la base de code d’une application. Les outils SCA analysent les logiciels, déterminent les dépendances et autres contenus qu’ils contiennent, puis identifient les sources originales de ces composants. De cette manière, les outils SCA déterminent quelles parties d’une base de code ont été obtenues à partir de sources tierces.
Aperçu
Les vulnérabilités et les risques liés aux logiciels se présentent sous de nombreuses formes et peuvent apparaître à n’importe quel stade du SDLC. De mauvaises pratiques de codage pourraient introduire des risques dans le code source de l’application, tandis que des dépendances non sécurisées pourraient être intégrées dans des paquets de prédéploiement. En dehors des failles de sécurité potentielles, d’un point de vue commercial, le non-respect des exigences en matière de licences et de réglementation pourrait exposer l’organisation à des poursuites judiciaires ou nuire à la réputation de sa marque.
L’une des méthodes utilisées pour atténuer ces risques consiste à mettre en œuvre l’analyse SCA pour détecter les menaces potentielles, à chaque étape de l’analyse de composition logicielle (SDLC). Penchons-nous sur la signification et le fonctionnement du SCA, afin de mieux comprendre ses avantages et ses limites, et sur la manière dont les outils SCA devraient être déployés pour assurer une protection continue contre un nombre toujours croissant d’attaques et de vulnérabilités.
Les outils SCA peuvent détecter de nombreux types de vulnérabilités, et plus particulièrement les dépendances non sécurisées dans les bibliothèques open source :
- Bibliothèques vulnérables : il s’agit de bibliothèques qui contiennent des failles de sécurité connues pouvant être exploitées par des pirates.
- Bibliothèques non entretenues : Les bibliothèques qui ne sont plus entretenues activement par leurs développeurs peuvent perdre en sécurité avec le temps.
- Bibliothèques malveillantes : il s’agit de bibliothèques qui ont été intentionnellement créées ou modifiées pour inclure un code malveillant. Les attaquants peuvent distribuer ces bibliothèques par le biais de dépôts publics, dans l’espoir que les développeurs les intègrent à leur insu dans leurs applications, afin de voler des données sensibles, d’installer des portes dérobées ou de compromettre l’intégrité des applications.
En outre, les outils SCA peuvent déterminer si du code provenant d’une source tierce a été introduit dans une application. La détection de ce type de code est importante non seulement parce qu’il peut contenir des menaces potentielles, mais aussi en raison de violations de licence potentielles.
It is important to note, however, that a single SCA scan is not necessarily capable of detecting security issues across all vulnerability categories. The results for a given scan depend on whether you are scanning application source code, application binaries, application packages or configuration files.
Therefore it is recommended to scan your applications at every stage of development and production to ensure detecting all instances of a particular vulnerability. For example, because insecure dependencies could be defined in source code as well as in configuration data, it is necessary to scan both the source code and the release package to detect all potential dependency-related vulnerabilities.
Exemples de scans SCA
Pour illustrer la signification de l’analyse de composition logicielle dans la pratique, examinons deux exemples d’utilisation du SCA pour trouver des risques et des vulnérabilités concrets.
Module non sécurisé dans le code source
Dans cet exemple, nous examinons une application Python existante – une legacy application – qui dépend d’une version spécifique d’un module Python externe. À des fins d’illustration, le module défectueux a été nommé « Insecure » et la version 1.2.3 est importée dans l’application à l’aide du code source suivant :
import pkg_resources
pkg_resources.require("Insecure==1.2.3")
import insecure
Dans ce scénario, la version 1.2.3 du module Insecure est connue pour être vulnérable. En analysant le code source de votre application, un outil SCA pourrait déterminer que votre application importe un module non sécurisé. Vos développeurs peuvent alors mettre à jour l’application pour utiliser une version sécurisée du module.
Parallèlement, votre équipe DevSecOps peut être en mesure d’atténuer le problème en bloquant toutes les conditions permettant d’exploiter la vulnérabilité du module non sécurisé dans l’environnement d’exécution de l’application. Par exemple, si la vulnérabilité exige qu’un certain port soit ouvert pour être exploitée, l’équipe DevSecOps peut s’assurer que ce port est fermé.
Dépendance d’un paquet non sécurisé
Dans cet exemple, nous considérons un paquet Debian, un format de fichier utilisé pour installer des logiciels sur Ubuntu et certaines versions de Linux, qui inclut un fichier de configuration à l’emplacement :
packagename-1.0/debian/control
Le contenu du fichier comprend :
Source: packagename Section: unknown Priority: optional Maintainer: "Firstname Lastname" <email.address@example.org> Build-Depends: ssl-cert (= 1.0.39) Standard-Version: 4.5.1 Homepage: <insert the upstream URL, if relevant> Requires-Root: no
Entre autres choses, ce fichier définit la version 1.0.39 du paquet ssl-cert comme une dépendance, ce qui signifie que si vous installez l’application sur un serveur Linux, la version 1.0.39 du paquet ssl-cert sera également installée. Étant donné que la version 1.0.39 de ssl-cert contient une vulnérabilité connue, l’installation du paquet introduit une menace exploitable dans l’environnement de l’hôte.
Dans ce cas, le déploiement d’un outil SCA pouvant lire le fichier de contrôle de ce paquet permettrait de détecter la dépendance non sécurisée, puis de la signaler afin que les ingénieurs en sécurité puissent atténuer le risque.
Avantages de l’analyse SCA
Le SCA n’est pas le seul moyen de détecter les risques et les vulnérabilités dans le code source ou les fichiers binaires. Avant l’introduction de la technologie SCA, l’examen manuel de l’application à chaque étape du développement était la seule option, ce qui ralentissait la vitesse de développement et était moins précis en raison de l’erreur humaine. Aujourd’hui, le SCA est devenu un outil de sécurité essentiel dans l’arsenal DevSecOps, offrant toute une série d’avantages :
Flux automatisé
En tirant parti de l’automatisation, les outils SCA peuvent détecter les risques à l’aide de processus en arrière-plan transparents pour les développeurs, tandis que les équipes de sécurité peuvent consacrer leur temps précieux à l’amélioration de la chaîne d’approvisionnement logicielle.
Détection précoce
La possibilité d’automatiser la détection des vulnérabilités signifie que vous pouvez commencer l’analyse dès les premières étapes du SDLC, ce qui permet de détecter les problèmes de sécurité potentiels dès le début du processus de développement, où ils peuvent être traités de manière plus rapide et plus efficace.
Par exemple, si vous détectez une dépendance non sécurisée alors que vous en êtes encore à la phase de codage de l’application, il est relativement simple de mettre à jour le code source pour résoudre le problème. Si la même vulnérabilité n’était pas détectée jusqu’au déploiement de la version en production, il faudrait retourner à l’étape de codage, recompiler et tester le logiciel, ce qui ferait perdre un temps et des ressources précieux.
Visibilité des dépendances
Les dépendances sont une bonne chose. Elles permettent aux développeurs d’intégrer des fonctionnalités dans les applications sans avoir à écrire tout le code à partir de zéro, ce qui permet de gagner du temps et d’améliorer l’efficacité du développement.
En contrepartie, les applications qui s’appuient fortement sur des dépendances se retrouvent avec des dizaines de modules, de bibliothèques et de dépendances différents qui sont nécessaires pour faire fonctionner l’application. Pour compliquer les choses, ces mêmes dépendances peuvent être définies à plusieurs endroits, tels que le code source, les fichiers de configuration ou les instructions de déploiement, ce qui rend leur suivi extrêmement difficile.
Les outils SCA répondent à ce problème en fournissant une visibilité sur les dépendances définies dans les applications, sur les versions requises et sur le fait que ces versions sont connues pour être vulnérables ou sûres.
Conformité des licences
Les outils SCA ne se contentent pas de vérifier les problèmes de sécurité, ils peuvent également alerter les développeurs qui sont en train d’ajouter un paquet tiers particulier à une base de code, qu’il pourrait être en violation d’accords de licence.
Dans ce cas, l’outil SCA signale la licence open source, ce qui permet aux développeurs de voir s’ils peuvent incorporer le code de manière conforme, en évitant une responsabilité juridique potentielle et des poursuites judiciaires coûteuses.
Limites de l’analyse SCA
Le SCA est une technologie puissante qui devrait faire partie de tout arsenal DevSecOps, mais il est important de reconnaître que les solutions SCA ne permettent pas à elles seules de détecter tous les types de menaces et de vulnérabilités.
Applicabilité
Pour la plupart, les outils SCA ne peuvent détecter que les risques associés au code open source ou aux dépendances. Ils ne peuvent pas signaler les problèmes de sécurité causés par des dépendances propriétaires, parce que ces dépendances ne sont pas soumises à l’examen du public et que les problèmes de sécurité qu’elles posent ne sont donc généralement pas signalés dans les bases de données publiques.
En outre, si les outils SCA peuvent identifier certains types de risques que les développeurs peuvent introduire dans leur code en raison de mauvaises pratiques de codage, d’autres risques peuvent échapper à la détection. Il existe un nombre infini de façons d’écrire un code source, ce qui rend impossible la détection de tout écart potentiel par rapport aux pratiques de codage sécurisées.
Fichiers de configuration externes
Une autre limitation majeure des outils SCA est leur capacité à analyser uniquement les fichiers de configuration au sein d’une application, mais pas les données de configuration externes à l’application. Par exemple, si vous configurez des paramètres de gestion des identités et des accès (GIA, en anglais : Identity Access Management ou IAM) non sécurisés dans un environnement cloud où vous déployez une application, votre outil SCA ne détectera pas les paramètres non sécurisés dans cette configuration. Pour détecter ces types de vulnérabilités, des capacités d’analyse IaC, disponibles dans des solutions telles que JFrog Advanced Security, des plug-ins IDE ou des outils CSPM sont nécessaires.
Fatigue d’alerte
Comme de nombreux outils de sécurité, l’analyse SCA peut donner lieu à un grand nombre d’alertes, ce qui peut contribuer à une certaine lassitude si elles ne sont pas correctement gérées. Le problème est exacerbé dans les environnements d’entreprise en raison de la complexité des projets et du grand nombre de dépendances qui peuvent permettre de détecter une vulnérabilité potentielle dans de nombreux composants qui, en réalité, peuvent ne pas être exploitables. Cette situation peut rapidement devenir insurmontable pour les équipes DevSecOps qui doivent trouver un moyen de hiérarchiser les vulnérabilités potentielles et de répondre aux alertes qui représentent des menaces sérieuses tout en ignorant les autres.
Outre le nombre d’alertes, les outils SCA peuvent également signaler des vulnérabilités qui ne sont pas réellement exploitables dans le contexte de l’application. Cela peut être dû à des entrées génériques dans la base de données des vulnérabilités qui ne tiennent pas compte de l’utilisation d’un composant dans une application spécifique. Il est donc extrêmement important d’utiliser des scanners SCA qui minimisent le nombre de « faux positifs », car chaque occurrence oblige les développeurs à passer un temps précieux à enquêter et à rejeter les alertes, ce qui ralentit la vitesse de développement et réduit la productivité globale.
Comment tirer parti de l’analyse SCA
Étant donné que les résultats de l’analyse SCA dépendent des types de ressources analysées, le moyen le plus efficace de tirer parti de l’analyse SCA est de s’assurer qu’elle est déployée à plusieurs stades du cycle de développement de l’application.
Commencez par effectuer un scan SCA du code source au début du processus de développement. À partir de là, scannez les fichiers binaires créés au cours du processus de construction. La troisième phase devrait comprendre l’analyse des paquets et des conteneurs dans lesquels les fichiers binaires sont stockés en vue de leur distribution.
Plus vous intégrez l’analyse SCA de manière cohérente dans le cycle de vie du développement logiciel, plus vous avez de chances de détecter et de résoudre les problèmes de sécurité et de conformité aux licences, avant qu’ils ne provoquent de graves perturbations et des pertes financières.
Tendances en matière de sécurité SCA
L’évolution continue des opérations de développement de logiciels et l’utilisation croissante de composants open source ont un impact profond sur les dernières tendances en matière de sécurité SCA, notamment :
Fonctionnalités améliorées
- Intégration avec les plateformes DevOps – Cela permet d’automatiser l’analyse des composants open source dans le cadre du processus de développement, ce qui garantit que les vulnérabilités sont identifiées et traitées le plus tôt possible dans le SDLC.
- IA et apprentissage automatique – L’intégration de ces algorithmes dans les outils SCA est conçue pour améliorer la précision et fournir une analyse plus perspicace des vulnérabilités, y compris la hiérarchisation, l’impact potentiel et les réponses suggérées.
- Conformité et gouvernance améliorées – Avec l’émergence de normes industrielles et gouvernementales, les outils SCA se dotent de fonctionnalités de gestion des politiques et des licences plus sophistiquées afin de garantir la conformité avec les politiques internes et les réglementations externes.
- Extension des bases de données de vulnérabilités – La portée et le niveau de détail de ces bases de données, qui sont à la base de la détection des vulnérabilités par le SCA, s’étendent à un plus large éventail de sources, y compris des informations complètes sur le contexte, l’exploitabilité et les mesures correctives pour les CVE publiées.
- Prise en charge de langages et de cadres supplémentaires – Compte tenu du taux élevé d’adoption de nouveaux langages de programmation et cadres de développement, les outils SCA doivent étendre leur prise en charge de langages pour rester efficaces et fournir une solution complète aux équipes chargées de la sécurité.
- Reporting et visualisation – Ces fonctionnalités deviennent de plus en plus importantes. En effet, les organisations s’efforcent d’accroître l’efficacité des opérations de sécurité, y compris les tableaux de bord interactifs, les rapports en temps réel et l’intégration dans les principales plateformes DevOps.
Consolidation de solutions individuelles
Outre ces améliorations importantes, il est important de reconnaître la tendance générale à la consolidation des solutions individuelles. Plutôt que d’utiliser une multitude d’outils de sécurité différents provenant de plusieurs fournisseurs, qui peuvent également produire des résultats contradictoires, les entreprises se tournent vers des solutions globales de bout en bout.
La consolidation des outils de sécurité permet d’améliorer la sécurité et l’efficacité des opérations. Par exemple, une solution d’analyse complète pourrait inclure non seulement l’analyse SCA, mais aussi les solutions SAST et DAST.
La solution de Jfrog en matière de SCA
L’approche de JFrog en matière d’analyse de composition logicielle (SCA) repose sur la capacité de sa plateforme à fournir une traçabilité et une provenance complètes de la chaîne d’approvisionnement logicielle. JFrog Artifactory, le dépôt central de tous les artefacts logiciels, capture des métadonnées étendues et détaillées pour chaque composant de la plateforme, ce qui permet une traçabilité totale. Cela permet aux organisations d’identifier toutes les dépendances transitives dans les composants tiers et d’exporter les données requises dans une nomenclature logicielle (SBOM) conforme automatiquement ou à la demande.
L’offre de sécurité de JFrog est intégrée à Artifactory de façon native, ce qui permet une analyse et une remédiation rapides et efficaces dans le contexte de l’inventaire logiciel actuel. L’analyse contextuelle de JFrog permet de gagner du temps et de prioriser les vulnérabilités les plus critiques à corriger en fonction de leur applicabilité dans l’environnement, et pas seulement de leur score CVSS.
JFrog Advanced Security étend les capacités du SCA de JFrog avec des recherches approfondies sur la sécurité menées par l’équipe de recherche en matière de sécurité de JFrog qui fournit des informations détaillées sur les problèmes de sécurité, leur impact sur le logiciel et des conseils sur la manière d’y remédier. La plateforme JFrog aide les équipes DevSecOps à améliorer leurs performances grâce à des conseils de remédiation contextuels et hiérarchisés qui identifient ce qui est le plus important pour assurer la protection de leur chaîne d’approvisionnement logicielle.
L’approche SCA de JFrog est basée sur la capacité de sa plateforme à fournir une traçabilité complète, une analyse de la provenance et des capacités de priorisation pour gagner du temps dans la correction des vulnérabilités. Continuez à explorer d’autres sujets liés au SCA ici ou si vous souhaitez voir la plateforme en action, planifiez une démonstration ou commencez un essai gratuit à votre convenance.
