Au début de l’année, notre équipe a été chargée de renforcer nos outils de sécurité existants ainsi que nos pratiques de développement et de test logiciels afin de nous conformer aux normes PCI-DSS et SOC 2. L’un des principaux domaines à améliorer concernait l’analyse des vulnérabilités de nos microservices basés sur K8s et de quelques services monolithiques. Notre équipe DevOps a donc dû choisir parmi plusieurs outils commerciaux et solutions open source afin de mettre en place l’analyse des vulnérabilités de nos logiciels. Tous ces outils fonctionnent de manière très similaire : ils analysent les dépendances (bibliothèques du projet ou paquets du système d’exploitation) et les comparent à des bases de données de vulnérabilités (comme la NVD du NIST, entre autres).
Développer ou acheter ?
Il existe plusieurs outils open source permettant de créer votre propre solution d’analyse des vulnérabilités. Vous pouvez également opter pour un produit commercial offrant, en plus de l’analyse de base, des fonctionnalités supplémentaires qui peuvent vous faciliter la tâche. En voici quelques exemples :
- Des tableaux de bord clairs pour obtenir un aperçu rapide des vulnérabilités de vos projets
- Notifications (e-mail, Slack, etc.)
- Intégration avec les dépôts Git (GitHub, GitLab)
- Intégration avec d’autres services (registre Docker, Kubernetes)
- Intégration avec des outils de gestion de projet (par exemple, Jira)
- Création automatique de demandes de fusion pour corriger les dépendances vulnérables
- Prise en charge des équipes, des projets et du contrôle d’accès basé sur les rôles (RBAC)
La plupart des solutions commerciales complètent les bases de données publiques sur les vulnérabilités par leur propre base afin d’éliminer les faux positifs et les faux négatifs, et de vous fournir des résultats plus pertinents. Cela dit, tous ces outils commerciaux deviennent très coûteux à mesure que le nombre de développeurs augmente. Vous devez donc déterminer s’il est « préférable » pour vous d’acheter une solution ou de créer la vôtre à l’aide des outils open source existants.
Au départ, nous avons estimé qu’un outil commercial répondrait le mieux à nos besoins compte tenu de nos contraintes de temps. Cependant, après avoir consacré trois mois au déploiement et aux tests d’un produit commercial de référence, nous avons rencontré de nombreuses difficultés : prise en charge limitée de Golang, détection de dépendances incorrectes et arrêt non contrôlé, problèmes avec les conteneurs créés à partir de zéro par rapport à ceux reposant sur une image de base, etc. Nous avons donc décidé d’y renoncer et de développer notre propre outil à l’aide des technologies open source disponibles.
Dans cet article, je vais vous fournir une base solide pour démarrer si vous choisissez une solution open source. Vous trouverez également, à la fin de l’article, un lien vers notre dépôt open source pour vous lancer !
Que faut-il analyser ?
Il y a essentiellement deux éléments dont vous devez rechercher les vulnérabilités :
- Les dépendances du code de votre projet (yarn.lock, Gopkg.lock, etc.)
- Dépendances du système d’exploitation (paquets Debian, paquets Alpine, etc.) dans une image Docker
À l’avenir, il sera possible d’ajouter d’autres fonctionnalités, telles que la vérification des licences ou l’analyse statique du code, mais cela dépasse le cadre de cet article.
Quand effectuer une analyse ?
Tout d’abord, vous devez vous assurer qu’aucune nouvelle vulnérabilité n’est introduite par une modification de votre code ou de votre image Docker. Il est donc recommandé d’analyser chaque demande de fusion avant qu’elle ne soit fusionnée.
Mais vous devez également effectuer une analyse régulièrement, car de nouvelles vulnérabilités peuvent apparaître au fil du temps. De plus, leur niveau de gravité peut évoluer : une vulnérabilité de faible gravité que vous aviez initialement ignorée peut devenir critique si un nouveau vecteur d’attaque ou une nouvelle méthode d’exploitation est découvert. Alors que les outils commerciaux mémorisent la dernière analyse et vous avertissent lorsqu’une nouvelle vulnérabilité est détectée, notre solution open source se contente de relancer l’analyse sur la branche master du projet.
Choisir les outils
Il existe de nombreux outils open source, mais nous avons choisi Trivy, car il est simple à utiliser, activement développé et capable d’analyser plusieurs projets et types de systèmes d’exploitation.
Trivy est un outil simple et complet d’analyse des vulnérabilités pour les conteneurs et autres artefacts. Une vulnérabilité logicielle est un dysfonctionnement, un défaut ou une faiblesse présent dans un logiciel ou un système d’exploitation. Trivy détecte les vulnérabilités des paquets du système d’exploitation (Alpine, RHEL, CentOS, etc.) et des dépendances applicatives (Bundler, Composer, npm, yarn, etc.). Trivy est facile à utiliser : il suffit d’installer le fichier binaire pour pouvoir lancer une analyse ! Pour effectuer une analyse, il vous suffit d’indiquer une cible, telle que le nom de l’image du conteneur.
Il peut être facilement installé et exécuté localement sur l’image Docker générée ou à la racine du projet. Il prend également en charge plusieurs formats de sortie, notamment JSON et les tableaux :
Malheureusement, Trivy ne peut pas analyser certains projets (par exemple ceux en Go), nous avons donc dû nous appuyer sur OWASP Dependency-Check car une grande partie de notre code est écrite en Go.
Dependency-Check est un outil d’analyse de la composition logicielle (SCA) qui tente de détecter les vulnérabilités rendues publiques dans les dépendances d’un projet. Pour ce faire, il détermine s’il existe un identifiant CPE (Common Platform Enumeration) pour une dépendance donnée. Si un tel identifiant est trouvé, il génère un rapport contenant des liens vers les entrées CVE associées.
Il peut générer des pages HTML contenant un rapport, ainsi que des sorties aux formats JUnit et JSON (entre autres).
Rapports et tableaux de bord
Nous arrivons maintenant à des choses plus intéressantes 😊
Comme nous utilisons déjà Elasticsearch + Kibana + Fluentd au sein de nos équipes DevOps et SRE, il était tout naturel d’exploiter l’infrastructure existante pour analyser les résultats JSON de nos analyses de sécurité.
Il nous fallait simplement trouver un moyen d’envoyer les données depuis une infrastructure non fiable (les runners CI) vers notre instance Elasticsearch sécurisée. Pour cela, nous avons décidé d’intercaler une file d’attente de messages. Fluentd dispose du plugin in_sqs pour lire les messages provenant d’Amazon SQS, et celui-ci est également simple à utiliser. L’architecture finale se présente donc comme suit :
Une fois les données intégrées à Elasticsearch, il est facile de créer quelques tableaux de bord avec Kibana ou d’utiliser Discover pour rechercher les vulnérabilités avec tous les détails nécessaires.
Correction des vulnérabilités
Nous disposons maintenant d’analyses et d’un joli tableau de bord. Quelle est la prochaine étape ? Nous ne pouvons pas nous attendre à ce que les développeurs consultent régulièrement ces tableaux de bord. Nous avons donc décidé de faire échouer l’intégration continue lorsqu’un problème de gravité élevée ou critique est détecté et qu’un correctif est disponible. La responsabilité incombe ainsi aux développeurs et aux responsables de projet.
Naturellement, nous devions pouvoir ajouter certaines CVE à une liste blanche ou remplacer ce comportement par défaut pour chaque projet. Nous avons donc créé un dépôt contenant des profils d’analyse de sécurité, utilisés par notre outil d’analyse qui encapsule l’exécution de Trivy et gère son comportement ainsi que ses résultats.
Désormais, n’importe quel développeur peut soumettre une demande de fusion dans ce dépôt afin de demander une dérogation. Exemple de profil pour le projet kibana :
Améliorations futures
Cette mise en œuvre de l’analyse de sécurité constitue une base solide qui peut être étendue au-delà de nos cas d’usage initiaux. Par exemple :
- Ajouter des notifications Slack et utiliser des profils de sécurité pour définir le canal et les options propres à chaque projet
- Ajouter une intégration avec GitLab Issues, Jira ou tout autre système de gestion des tickets
- Créer un service simple ou un conteneur side-car pour analyser les images déployées sur le cluster Kubernetes
Forkez-le et utilisez-le
Vous trouverez le Dockerfile et les outils dans notre dépôt GitLab public : https://gitlab.com/volterra.io/security-scanning
Merci à Jakub Pavlík.
À propos des auteurs
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.