Bonjour à tous, j’espère que la rentré 2022 ce passe bien de votre côté ! Dans cet article, je vais vous montrer la puissance d’un outils nommé « Trivy » qui permet d’analyser tout un tas de chose. Celui-ci s’avère prometteur et est développé par l’éditeur aquasecurity. (Ce qui est une bonne chose pour le maintien de cet outil dans le temps)
Trivy est un outil de sécurité polymorphe (s’adaptant à plusieurs types d’environnements). Il embarque avec lui différents scanners qui recherchent des problèmes de sécurité (détection de défauts de configuration, scans diverses afin de détecter si l’entité est vulnérable à des CVE, etc.)
Avant-propos – Hardening système de votre hôte docker
Si-vous n’avez pas déjà lu mon précédent article consacré au durcissement d’un hôté docker, je vous conseille d’y jeter un oeil !
I. Analyse de la sécurité d’une image docker « on the fly »
Si-vous souhaitez analiser la sécurité d’une image (image local, ou depuis docker hub), rien de plus simple :
docker run --rm aquasec/trivy image archidote/mywebapp --no-progress --severity HIGHarchidote/mywebappVieille image que je n’ai jamais maintenue. Elle va me servir d’exemple dans cet article.--severity HIGHPermet de trier les tests et d’obtenir uniquement les potentielles failles de sécurité publique (CVE) avec score CVSSv3 > à 7 < 8,9. L’exploitabilité d’une vulnérabilité devient intéressant en règle générale dès lors que vous vous avez une ou plusieurs vulnérabilités « majeur » qui affectent l’environnement.--no-progressvous permettra d’éviter de polluer votre terminal (cela permettra d’éviter d’avoir un rendu beaucoup moins verbeu)
II. Hardening d’image docker – Intégration de Trivy dans un dockerfile – Démarche DevSecOps
Vous pouvez également intégrer Trivy dans le cadre du processus de construction d’une image. Cela vous permettra de gagner du temps surtout pour le déploiement de(s) image(s) par la suite.
Afin d’être on ne peut plus clair, je vais prendre deux images. L’une est up to date et l’autre non.
A. Avec une image non mise à jour
touch Dockerfile.oldDans le Dockefile ci-dessous, je vais intégrer l’installation et l’exécution de Trivy.
FROM archidote/vmsafeguard
ENV DEBIAN_FRONTEND="noninteractive"
RUN apt update
RUN apt install curl -y
RUN curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/install.sh | sh -s -- -b /usr/local/bin
RUN trivy filesystem --severity HIGH --exit-code 1 --no-progress /À partir de la 5e ligne Trivy va s’auto installer dans l’image lors de la construction de celle-ci un code erreur 0 ou 1 en fonction sera renvoyé en fonction de si oui ou non l’image à réussi à passer les tests de sécurité.
Dans mon cas, je souhaite simplement savoir si mon image est vulnérable oui ou non à des failles de sécurité publique disposant d’un score CVSSv3 « high » (7 > && < 8.9)
docker build -t ubuntu_old -f Dockerfile.old .
L’ analyse de cette image va détecter que celle-ci est vulnérable à plusieurs vulnérabilités « High ». Trivy va donc volontairement « crasher » (à la fin de son exécution) en nous renvoyant volontairement le code erreur 1. Grâce à cela, vous pourrez intégrer plus facilement Trivy (error(s) catching) lors de la création de vos pipelines Gitlab CI/CD – Github Actions.
Ce processus qui s’automatise (bien évidemment) vous évitera de publier une nouvelle image docker sur votre registre privé (ou sur le registre officiel docker hub) avec des défauts de configuration / vulnérabilités. en effet, la pipeline « crashera » juste avant la phase de « push » sur Dockerhub.
B. Avec une image à jour
Ici, je reprends le même procédé que ci-dessus. J’ai simplement changé le type d’image de « base », en utilisant une image officiel ubuntu (la dernière en date par défaut). Cette fois-ci, vous devriez passer tous les tests avec brio. (Sauf si entre-temps une vulnérabilité avec un score CVSS élevé a été mis au jour sans que celle-ci (l’image) ne soit encore patché ^^ –> l’exception qui confirme la règle)
touch Dockerfile.uptodateFROM ubuntu
ENV DEBIAN_FRONTEND="noninteractive"
RUN apt update
RUN apt install curl -y
RUN curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/install.sh | sh -s -- -b /usr/local/bin
RUN trivy filesystem --severity HIGH --exit-code 1 --no-progress /
docker build -t ubuntu_up_2_date -f Dockerfile.uptodate .
Le build de l’image s’est réalisé dans accros, Trivy n’a pas détecté de problèmes de sécurité/vulnérabilités.
III. Vérifier la sécurité d’un référentiel Git « on the fly »
Avant de git clone bêtement un repo git quelconque, il est de rigueur (normallement) de réaliser un simple « balayage » du code afin de détecter d’éventuelles problèmes de configuration/développement. Trivy nous permets de réaliser cette analyse de sécurité de manière automatique :
docker run --rm aquasec/trivy repo https://github.com/juice-shop/juice-shop --no-progress
IV. Conclusion
Trivy est un outil facile d’utilisation, adapté pour l’automatisation et mature vu qu’il est capable de scanner plusieurs sortes d’environnement. Attention tout de même, rien ne vaut l’oeil « Humain ». Il est important de garder en tête que ces outils sont là pour nous faciliter la tâche, mais que nous devons tout de même regarder de temps à autre sur ce qu’ils font afin d’analyser si les résultats produits sont logiques. L’oeil humain est capable de détecter des problèmes de configuration en rapport avec la logique {technique, métier} non prévisible algorithmiquement et complexe qu’une « moulinette de sécurité » comme Trivy ne détectera pas.
Je vous laisse le soin de tester les autres fonctionnalités de cet outil qu’est Trivy en fonction de vos contextes techniques !
++
