Meilleures pratiques pour le scan de vulnérabilités de paquets
L’analyse des vulnérabilités en matière de sécurité des paquets est une étape fondamentale pour la sécurisation de la quasi-totalité du pipeline de livraison de logiciels modernes. Grâce aux outils SCA, il est possible d’identifier automatiquement les vulnérabilités connues dans les paquets utilisés pour déployer les applications, les scanners de paquets réduisent considérablement le risque de mettre en production des logiciels non sécurisés.
Pour sécuriser les paquets, il ne suffit pas de mettre en place un scanner de paquets automatisé et de supposer qu’il détectera toutes les vulnérabilités potentielles. Comme l’explique cet article, les équipes de développement doivent prendre des mesures supplémentaires pour tirer le meilleur parti de l’analyse des vulnérabilités des paquets.
Qu’est-ce que le scan de vulnérabilités de paquets ?
Le scan de vulnérabilité des paquets est le processus d’analyse automatique des paquets de logiciels à la recherche de vulnérabilités connues.
Les scanners de vulnérabilité peuvent inspecter virtuellement n’importe quel type de paquet. Ils peuvent être utilisés pour analyser les images des conteneurs Docker, par exemple, ou les paquets Debian ou RPM que les développeurs créent pour déployer des logiciels sur les systèmes Linux.
En règle générale, les scanners de paquets vérifient si le contenu d’un logiciel correspond à des éléments connus pour être vulnérables. Ils s’appuient sur des bases de données qui recensent les failles de sécurité dans les applications et les bibliothèques. Par exemple, un scanner de vulnérabilité peut déterminer qu’un paquet comprend une version particulière d’une bibliothèque logicielle qui contient un bogue de sécurité connu. Le scanner marquerait le problème et avertirait les développeurs afin qu’ils mettent à jour la bibliothèque vers une version plus récente et plus sûre.
Les limites des scanners de vulnérabilité des paquets
Bien que les scanners de vulnérabilité soient un outil important pour trouver de nombreux types de risques de sécurité dans les logiciels, il est important de se rappeler qu’ils ne vérifient que les vulnérabilités qui ont déjà été identifiées dans les bases de données de vulnérabilités.
Ils ne peuvent généralement pas détecter les bogues de sécurité, tels que les vulnérabilités de débordement de tampon, qui existent dans le code que les développeurs écrivent en interne. Cette tâche incombe aux outils de test statique de la sécurité des applications. Ils ne surveillent pas non plus le comportement des applications pour détecter les signes d’une violation de la sécurité, tâche qui incombe aux outils SIEM (gestion des événements et des informations de sécurité) et à d’autres outils de surveillance de la sécurité.
Une autre limite est l’interprétation du grand nombre d’alertes que les scanners de vulnérabilités peuvent générer. Lorsque vous analyserez vos paquets, vous recevrez généralement une longue liste de vulnérabilités, et le scanner n’évalue pas nécessairement la gravité de chaque vulnérabilité qu’il identifie. C’est pourquoi il peut être difficile de savoir quelles vulnérabilités sont suffisamment graves pour justifier la non-utilisation d’une image, et quelles vulnérabilités présentent des risques insignifiants. Pour obtenir ces informations, il est souvent nécessaire de procéder à une analyse manuelle de chaque vulnérabilité et de son impact potentiel sur l’environnement.
Regarder le webinaire à la demande : Identifier et éviter les paquets malveillants
VERS LE WEBINAIRE À LA DEMANDE
Tirer le meilleur parti des scanners de vulnérabilité pour vos paquets
Le simple fait de déployer un scanner automatique de vulnérabilité des paquets dans le cadre de votre pipeline d’intégration et de livraison continues (CI/CD) est la première étape pour rester à l’avant-garde des problèmes de sécurité. Toutefois, vos équipes doivent prendre des mesures supplémentaires pour maximiser leurs chances de trouver toutes les vulnérabilités potentielles présentes dans les paquets.
Les paquets doivent être aussi petits que possible
Plus vous avez de code et de dépendances dans chaque paquet, plus il peut être difficile pour les scanners de vulnérabilité de décomposer toutes les couches et de détecter les vulnérabilités. Il est également plus difficile de résoudre un problème de sécurité et de reconstruire le paquet si celui-ci contient de nombreux éléments.
Une bonne pratique consiste à s’assurer que chaque paquet que vous créez ne contient que le code et les ressources nécessaires pour fournir la fonctionnalité souhaitée. Résistez à la tentation de regrouper plusieurs composants d’une application en un seul paquet.
Par exemple, au lieu de créer une image Docker contenant plusieurs microservices, générez des images différentes pour chaque microservice. Ou bien, plutôt que d’empaqueter le front-end et la logique de l’application dans le même paquet Debian, séparez-les dans des paquets différents.
Procédez à des scans dès le début du cycle de développement
Au lieu d’attendre le déploiement pour analyser les paquets, essayez d’effectuer des analyses dès que les paquets sont créés.
Le fait d’effectuer des scans le plus tôt possible présente deux avantages. D’une part, il est plus facile de traiter les vulnérabilités à un stade précoce du pipeline CI/CD, car vous avez moins investi. D’autre part, si vous attendez d’avoir effectué d’autres types de tests sur vos paquets pour procéder à des scans, vous devrez répéter ces tests si vous détectez une vulnérabilité et reconstruire le paquet.
En outre, les scans précoces minimisent également le risque de mettre en production une application non sécurisée. Vous ne souhaitez pas placer des images de conteneur dans un registre à partir duquel les utilisateurs pourraient les télécharger et les installer avant que vous ne les ayez analysées.
L’analyse précoce ne remplace pas l’analyse juste avant le déploiement, qui est également importante pour s’assurer que vous évaluez les risques du logiciel que vous mettez en production. Mais une analyse effectuée plus tôt dans le cycle de développement vous aidera à éliminer les vulnérabilités potentielles avant qu’elles n’apparaissent dans le pipeline.
Évaluer les niveaux de priorité
Comme nous l’avons vu plus haut, une longue liste de vulnérabilités dans un paquet n’est pas très utile si votre équipe a du mal à déterminer quelles vulnérabilités sont suffisamment graves pour rendre le paquet inutilisable. Évitez ce problème en investissant dans un scanner qui permet d’évaluer efficacement les risques liés aux vulnérabilités et d’établir des priorités sur la base d’une analyse de l’impact réel de chaque vulnérabilité sur la sécurité. De cette manière, vous pouvez facilement déterminer quelles sont les vulnérabilités les plus importantes et quelles sont celles que vous pouvez ignorer.
Scannez les paquets même si vous avez confiance en la source
Parfois, les paquets que vous déployez proviennent de sources tierces plutôt que de sources internes. Dans ce cas, il est essentiel de scanner ces paquets, quelle que soit la confiance que vous avez dans la source.
Investir dans une base de données complète sur les vulnérabilités
Les scanners de vulnérabilité des paquets (outils SCA) à code open source ne sont efficaces que dans la mesure où vous leur fournissez des données sur les vulnérabilités. Si votre base de données de vulnérabilités n’inclut pas un problème de sécurité connu, votre scanner ne peut pas le détecter. C’est pourquoi il est judicieux d’investir dans une solution d’analyse des vulnérabilités proposée par un fournisseur de plateforme de sécurité DevOps qui exploite une base de données complète sur les vulnérabilités en s’appuyant sur de multiples sources d’informations sur les menaces, y compris l’expertise publique, propriétaire et interne en matière de recherche sur la sécurité.
L’équipe de recherche en sécurité de JFrog construit et maintient la base de données de vulnérabilité JFrog Xray avec des données sur les paquets open source, y compris les types de licence et les vulnérabilités connues (CVE). Les analystes de sécurité de JFrog ajoutent également des données contextuelles et relatives aux CVE avancées avec des instructions alternatives de remédiation lorsque cela est possible.
