Les outils d'analyse de composition logicielle offrent une visibilité précieuse sur les vulnérabilités connues des dépendances open source. Leur efficacité dépend entièrement du périmètre de leur configuration : les dépôts qu'ils analysent, les écosystèmes de langages qu'ils couvrent, les sources de données de vulnérabilités qu'ils interrogent et la fréquence de leurs analyses. Un outil d'SCA configuré avec un périmètre étroit produit des constats de vulnérabilités pour les dépendances qu'il voit, mais n'apporte aucune assurance sur les dépendances hors de sa couverture configurée. Annoncer « zéro vulnérabilité critique trouvée » à partir d'une configuration d'SCA au périmètre étroit est exact pour le périmètre couvert et trompeur quant au tableau d'ensemble des risques liés aux dépendances.
La lacune de couverture des dépôts est la défaillance de périmètre de l'SCA la plus courante. Le code source d'une entreprise s'étend généralement sur plusieurs dépôts : un monodépôt ou un ensemble de dépôts propres à chaque microservice, des dépôts de bibliothèques partagées, des dépôts d'outils internes et des dépôts de code d'infrastructure. Une configuration d'SCA qui couvre le dépôt applicatif principal peut manquer le dépôt de bibliothèques partagées dont les composants sont inclus dans plusieurs services, les dépôts de microservices qui ont leurs propres arbres de dépendances et les dépôts d'outils internes qui ont accès aux systèmes de production. Le profil de vulnérabilité du dépôt principal n'est qu'une partie de l'exposition totale de l'organisation à ses dépendances.
La lacune de couverture des écosystèmes est la deuxième défaillance de périmètre courante. Les outils d'SCA doivent être configurés pour chaque écosystème de langage qu'ils couvrent : paquets Python (PyPI), paquets JavaScript (npm), paquets Java (Maven), modules Go, gems Ruby, etc. Un outil configuré pour analyser les dépendances Python n'analyse pas automatiquement les dépendances Go ou Java du même code source. Une organisation dont les services sont écrits dans plusieurs langages doit configurer une couverture propre à chaque écosystème, ou utiliser un outil qui gère automatiquement l'analyse multi-écosystèmes.
Pourquoi c’est important
Les lacunes de l'SCA sont importantes pour la TPRM, car le rapport « zéro vulnérabilité critique » d'un outil d'SCA ne couvre que ce que l'outil a été configuré pour analyser. Une entreprise qui accepte un rapport d'SCA comme preuve d'une gestion complète des vulnérabilités des dépendances, sans comprendre le périmètre de configuration de l'outil, peut déployer des logiciels présentant une exposition importante à des dépendances non analysées. S'interroger sur le périmètre de l'SCA, et pas seulement sur la mise en place d'un outil d'SCA, est la question qui révèle la lacune.
- Existence de l'SCA confirmée sans évaluation du périmètre
- Couverture des dépôts : tous les dépôts ne sont pas dans le périmètre de l'SCA
- Couverture des écosystèmes de langages : tous les langages ne sont pas configurés
- Vulnérabilités hors CVE non couvertes par les configurations d'SCA limitées aux CVE
- Fréquence des analyses SCA : les constats d'analyses peu fréquentes peuvent ne pas refléter l'état actuel
À quoi ressemblent les bonnes pratiques
Les programmes d'SCA matures mettent en œuvre une couverture complète des dépôts, une analyse multi-écosystèmes, des sources complémentaires de vulnérabilités hors CVE et une analyse continue dont les constats sont intégrés au flux de développement plutôt que livrés dans des rapports périodiques.
- Couverture complète des dépôts : tous les dépôts de production dans le périmètre de l'SCA
- Analyse multi-écosystèmes : tous les écosystèmes de langages couverts
- Sources de vulnérabilités hors CVE : détection de paquets malveillants au-delà des bases de données CVE
- Analyse continue : à chaque commit, sur chaque branche, et pas seulement des rapports périodiques
- Documentation du périmètre de l'SCA : ce qui est couvert et ce qui ne l'est pas, explicitement documenté
Outils
SCA complète : Snyk pour l'analyse continue multilangage ; GitHub Dependabot pour la couverture complète des dépôts
Snyk assure une analyse continue et multilangage des dépendances avec une intégration complète aux dépôts, couvrant Python, JavaScript, Java, Go, Ruby et d'autres écosystèmes dans une configuration unique. GitHub Dependabot assure une couverture automatique de l'ensemble du dépôt pour les écosystèmes pris en charge. Pour les praticiens de la TPRM, demander si les fournisseurs utilisent des outils d'SCA multilangages couvrant l'ensemble des dépôts constitue une question précise d'évaluation du périmètre.
Enjeux de gouvernance
Le défi de gouvernance du périmètre de l'SCA est la charge de maintenance de la configuration. À mesure que le code source grandit, de nouveaux dépôts sont créés, de nouveaux écosystèmes de langages sont adoptés et de nouveaux types de dépendances apparaissent. Le périmètre de l'SCA doit être activement maintenu pour couvrir ces ajouts : une configuration complète il y a six mois peut présenter des lacunes aujourd'hui. La solution de gouvernance est un examen du périmètre de l'SCA dans le cadre de la revue annuelle du programme de gestion des dépendances.
- Documenter explicitement le périmètre de l'SCA : ce qui est couvert et ce qui ne l'est pas
- Examiner chaque année l'exhaustivité du périmètre, à mesure que de nouveaux dépôts et écosystèmes sont ajoutés
- Mettre en place des outils multilangages plutôt que des configurations limitées à un seul écosystème
- Compléter par une détection hors CVE : analyse des paquets malveillants et de la légitimité
- Interroger sur le périmètre de l'SCA lors de l'évaluation de la sécurité logicielle des fournisseurs, et pas seulement sur l'existence d'un outil
Si vous êtes une petite équipe
Posez à vos éditeurs de logiciels les plus critiques une question qui révèle le périmètre de leur SCA : votre outil d'SCA analyse-t-il tous les dépôts de production dans tous les écosystèmes de langages utilisés pour développer votre logiciel, et pouvez-vous communiquer la documentation du périmètre de l'SCA qui décrit ce qui est couvert et ce qui ne l'est pas ? La documentation révélera les lacunes. Si le fournisseur ne peut pas fournir de documentation du périmètre, c'est que le périmètre n'a pas été formellement défini, ce qui signifie que des lacunes existent sans être suivies.
- Demander aux fournisseurs la documentation du périmètre de leur SCA : quels dépôts et écosystèmes sont couverts
- Repérer les lacunes de couverture des dépôts et des écosystèmes
- Interroger sur la détection des vulnérabilités hors CVE au-delà de l'SCA
- Exiger une couverture complète des dépôts et des écosystèmes de la part des éditeurs de logiciels critiques
Ce qu’il faut exiger
Demandez directement :
« Pouvez-vous fournir la documentation du périmètre configuré de votre outil d'SCA, en précisant quels dépôts sont analysés, quels écosystèmes de langages sont couverts et si vos analyses vont au-delà des bases de données CVE pour inclure la détection de paquets malveillants ? »
Preuves attendues
- Documentation du périmètre de l'SCA : dépôts et écosystèmes couverts
- Confirmation de la couverture des écosystèmes de tous les langages
- Capacité de détection des vulnérabilités hors CVE
- Fréquence des analyses et intégration au flux de développement
Il faut demander la documentation du périmètre à un fournisseur qui confirme avoir mis en place un outil d'SCA. L'existence de l'outil confirme la capacité. La documentation du périmètre révèle ce que la capacité couvre et ce qu'elle laisse de côté.
Comment le prouver
- Examen de la documentation du périmètre de l'SCA
- Vérification de la couverture multi-écosystèmes
- Évaluation de l'exhaustivité de la couverture des dépôts
- Capacité de détection hors CVE
À retenir
Outil d'SCA : en place. Constats : 23 vulnérabilités critiques, toutes corrigées. Rapport : risque de vulnérabilité de la chaîne d'approvisionnement maîtrisé. Non couverts : 7 dépôts, les services Go et Java, les problèmes de sécurité hors CVE. L'outil fonctionnait correctement pour le périmètre configuré. Le périmètre configuré était la lacune. L'existence d'un outil d'SCA est un point de départ. La documentation du périmètre de l'SCA révèle si la couverture de l'outil correspond à la complexité du code source. Zéro constat sur un périmètre étroit, ce n'est pas « risque de vulnérabilité de la chaîne d'approvisionnement maîtrisé », c'est « nous n'avons aucun constat dans les dépôts et les langages que nous avons configuré l'outil pour analyser ».