Infrastructure d'analyse de sécurité pour vos images Docker et vos dépendances de code

Au début de cette année, notre équipe a été invitée à renforcer nos outils de sécurité existants et nos pratiques de développement et de test de logiciels pour la conformité aux normes PCI-DSS et SOC-2. L’un des domaines clés que nous avons dû améliorer était l’analyse des vulnérabilités pour nos microservices basés sur K8s et quelques services monolithiques. En conséquence, notre équipe DevOps a dû choisir entre quelques outils commerciaux et des solutions open source pour mettre en œuvre l’analyse des vulnérabilités de nos logiciels. Tous ces outils font des choses très similaires : ils analysent les dépendances (soit des bibliothèques de projets, soit des packages de système d’exploitation) et les comparent aux bases de données de vulnérabilité (comme NVD du NIST et d’autres).

Construire contre. Acheter?

Il existe quelques outils open source qui peuvent être utilisés pour créer votre propre solution d'analyse des vulnérabilités, ou vous pouvez utiliser un produit commercial qui ajoute des fonctionnalités supplémentaires à l'analyse de base qui peuvent vous faciliter la vie. Voici quelques exemples : 

• Tableaux de bord intéressants pour un aperçu rapide des vulnérabilités de vos projets 
• Notifications (e-mail, Slack, etc.) 
• Intégration avec les référentiels Git (GitHub, GitLab) 
• Intégration avec d'autres services (registre Docker, Kubernetes) 
• Intégration avec la gestion de projet (par exemple Jira) 
• Création automatique de demandes de fusion pour corriger les dépendances vulnérables 
• Support pour les équipes, les projets et RBAC

La plupart des solutions commerciales augmentent la base de données de vulnérabilités publiques avec leur propre base de données de vulnérabilités pour éliminer les faux positifs/négatifs et vous donner des résultats plus pertinents. Cela dit, tous ces outils commerciaux deviennent très chers à mesure que le nombre de développeurs augmente. Vous devez donc vous demander s’il est « préférable » pour vous d’acheter ou de créer votre propre solution en utilisant les outils open source existants.

Au départ, nous avons décidé qu’un outil commercial répondrait le mieux à nos besoins, compte tenu des contraintes de temps dont nous disposions. Cependant, après avoir passé 3 mois à déployer et tester un produit commercial leader du secteur, nous avons été confrontés à de nombreux défis : support limité pour golang, il choisirait des dépendances incorrectes et ne se terminerait pas correctement, problèmes avec les conteneurs construits à partir de zéro par rapport à ceux construits avec une image de base, etc. En conséquence, nous avons décidé d’abandonner et de passer à la création de notre propre outil en utilisant les technologies open source disponibles.

Dans cet article, je vais vous fournir une base solide pour commencer si vous choisissez de passer à l’open source. De plus, à la fin de l'article se trouve le lien vers notre dépôt open source pour vous aider à démarrer !

Que scanner ?

Il y a essentiellement deux choses que vous souhaitez analyser pour détecter les vulnérabilités : 

1. Les dépendances de code de votre projet (yarn.lock, Gopkg.lock, etc.)
2. Dépendances du système d'exploitation (packages Debian, packages Alpine, etc.) dans une image Docker

À l’avenir, il sera possible d’ajouter davantage de fonctionnalités telles que la vérification des licences ou l’analyse statique du code, mais cela sort du cadre de cet article.

Quand scanner ?

Tout d’abord, vous devez vous assurer qu’aucune nouvelle vulnérabilité n’est introduite par votre code ou par une modification de l’image Docker. C’est donc une bonne idée d’analyser chaque demande de fusion avant sa fusion.

Mais vous devez également effectuer des analyses périodiques , car de nouvelles vulnérabilités peuvent apparaître au fil du temps. De plus, les niveaux de gravité peuvent changer : un niveau de gravité faible que vous avez initialement ignoré peut devenir critique au fil du temps lorsqu'un nouveau vecteur d'attaque ou un nouveau exploit est découvert. Alors que les outils commerciaux mémorisent la dernière analyse et vous avertissent si une nouvelle vulnérabilité est détectée, dans notre solution open source, nous répétons simplement l'analyse sur la branche principale du projet.

Choisir les outils

Il existe de nombreux outils open source disponibles, mais notre choix s'est porté sur Trivy car il est simple à utiliser, en cours de développement et peut analyser plusieurs projets et types de systèmes d'exploitation.

Trivy est un scanner de vulnérabilité simple et complet pour les conteneurs et autres artefacts. Une vulnérabilité logicielle est un problème, une faille ou une faiblesse présente dans le logiciel ou dans un système d’exploitation. Trivy détecte les vulnérabilités des packages OS (Alpine, RHEL, CentOS, etc.) et des dépendances applicatives (Bundler, Composer, npm, yarn, etc.). Trivy est facile à utiliser : il suffit d’installer le binaire et vous êtes prêt à scanner ! Pour effectuer la numérisation, il vous suffit de spécifier une cible telle qu'un nom d'image du conteneur.

Il peut être facilement installé et exécuté localement sur l’image Docker construite ou sur la racine du projet. Il prend également en charge plusieurs sorties, notamment JSON et la sortie de tableau :

Malheureusement, il existe des projets que Trivy ne peut pas analyser (par exemple Golang), nous avons donc dû nous fier à OWASP Dependency-Check car une grande partie de notre code est en golang.

Dependency-Check est un outil d'analyse de composition logicielle (SCA) qui tente de détecter les vulnérabilités divulguées publiquement contenues dans les dépendances d'un projet. Pour ce faire, il détermine s’il existe un identifiant d’énumération de plateforme commune (CPE) pour une dépendance donnée. S'il est trouvé, il générera un rapport lié aux entrées CVE associées.

Il peut générer des pages HTML avec rapport, sortie JUnit et JSON (et quelques autres).

Rapports et tableaux de bord

Maintenant, nous nous rapprochons de choses plus intéressantes 😊

Comme nous utilisons déjà Elasticsearch + Kibana + Fluentd dans nos équipes DevOps et SRE, il était naturel d'utiliser l'infrastructure existante pour analyser la sortie JSON de nos analyses de sécurité.

Nous devions simplement trouver un moyen d’envoyer des données d’une infrastructure non fiable (exécuteurs CI) vers notre Elasticsearch sécurisé. À cette fin, nous avons décidé d’avoir une file d’attente de messages au milieu. Fluentd dispose d'un plugin in_sqs pour lire les messages d'Amazon SQS et il est également simple à utiliser, donc l'architecture finale ressemble à ceci :

Une fois que les données atteignent Elasticsearch, il est simple de créer quelques tableaux de bord avec Kibana ou d'utiliser Discover pour interroger les vulnérabilités avec tous les détails nécessaires.

Gérer les vulnérabilités

Alors maintenant que nous avons des scans et un joli tableau de bord, quelle est la prochaine étape ? Nous ne pouvons pas nous attendre à ce que les développeurs consultent ces tableaux de bord régulièrement. Au lieu de cela, nous avons décidé d'échouer le CI lorsqu'un problème de gravité élevée ou supérieure est détecté et qu'un correctif est disponible, de cette façon la responsabilité est transférée aux développeurs et aux propriétaires de projets.

Naturellement, nous avions besoin d’avoir une option pour mettre sur liste blanche certains CVE ou pour remplacer ce comportement par défaut pour chaque projet. Nous avons donc créé un référentiel avec des profils d’analyse de sécurité qui sont consommés par notre outil d’analyse qui encapsule l’exécution de Trivy et gère son comportement et sa sortie.

Désormais, tout développeur peut soumettre une demande de fusion contre ce référentiel et demander une exception. Exemple de profil pour le projet Kibana :

Améliorations futures

Cette implémentation de l’analyse de sécurité est une base solide qui peut être étendue au-delà de nos cas d’utilisation initiaux. Par exemple: 

• Ajoutez des notifications Slack, utilisez des profils de sécurité pour spécifier le canal et les options par projet 
• Ajoutez une intégration avec Gitlab Issues, Jira ou tout autre système de billetterie
• Créez un service simple ou un side-car pour exécuter l'analyse des images déployées sur le cluster Kubernetes

Fourchez-le et utilisez-le

Vous pouvez trouver Dockerfile et les outils dans notre dépôt Gitlab public : https://gitlab.com/volterra.io/security-scanning

Merci à Jakub Pavlík .