Outils de sécurité open source
Trivy : le scanner de vulnérabilités tout-en-un pour les images et le code
Trivy est le scanner open source d'Aquasecurity qui vérifie presque tout dans une pile moderne : images de conteneurs et systèmes de fichiers, modèles IaC, dépôts git, manifestes Kubernetes, secrets et conformité des licences, avec des données CVE mises à jour en permanence. En pratique, sa puissance réside dans le fait qu'il constitue le scanner sur lequel un pipeline CI peut réellement se connecter, avec des codes de sortie qui échouent à la construction.
Points clés
- La surface est délibérément large : CVE des packages de système d'exploitation et dépendances d'applications (npm, pip, modules Go, JAR Java), erreurs de configuration IaC (Dockerfile/Terraform/K8s), secrets intégrés (clés API, clés privées) et conformité des licences ; un outil regroupe quatre catégories d’analyse en un seul appel CLI.
- Le gate CI est le gain opérationnel : --exit-code 1 --severity CRITICAL,HIGH transforme le scan en un build gate ; ignorer les CVE filtrés via .trivyignore avec les commentaires d'expiration définit l'habitude de révision de 90 jours qui maintient la porte honnête plutôt que contournée de façon permanente.
- Les modes d'analyse couvrent le domaine : analyse d'images (registre ou démon local), analyse du système de fichiers sur les arborescences sources, analyse des dépôts sur l'historique git, analyse du cluster Kubernetes (via la sous-commande k8s) et génération SBOM (CycloneDX/SPDX) pour les audits ; les mêmes conventions CLI partout signifient une faible surcharge de formation.
- La gestion de la gravité nécessite du contexte : la base de données fait autorité sur les CVE mais est aveugle à votre exposition (est-elle accessible ?), donc la discipline de tri (l'application utilise-t-elle réellement ce chemin de bibliothèque ? le service est-il accessible sur Internet ?) appartient au processus, pas à l'outil ; les portes de gravité uniquement sans boucle de triage produisent des scanners ignorés.
- Modèles de déploiement opérationnel : analyse dans le pipeline (fusions de portes), balayages de registre planifiés (capture des CVE publiés après la construction) et vérifications de l'heure d'admission sur les clusters (contrôleurs d'admission Kubernetes appelant Trivy) ; la combinaison capture la fenêtre de publication CVE après déploiement que l'analyse en un seul passage manque.
- Positionnement au sein de notre ensemble d'outils de sécurité : Trivy (vulnérabilité/prévention) complète Falco (exécution/détection) et Wazuh (couches endpoint/SIEM) ; c'est le premier scanner que nous déployons sur un projet moderne, car l'honnêteté CLI et l'ergonomie CI battent les outils commerciaux plus lourds pour les premiers 80 %.
Note de terrain
Le CVE qui a prouvé l'habitude du CI-gate : un avis critique publié neuf jours après la création d'une image propre. La nouvelle analyse programmée du registre l'a détecté, la reconstruction a pris quelques minutes. Un outil avec des codes de sortie et un rythme de re-scan vaut dix outils avec des tableaux de bord que personne n'ouvre.
Questions fréquentes
Trivy vs OpenVAS (Greenbone) : pourquoi exécutons-nous les deux ?
Trivy analyse les artefacts (images, code source, dépendances, IaC) et est en forme de CI ; OpenVAS analyse les services réseau en direct sur les hôtes avec des sondes authentifiées ; ils répondent à des questions différentes et se complètent plutôt qu’ils ne rivalisent.
À quelle fréquence la base de données CVE est-elle mise à jour ?
Les bases de données de Trivy se synchronisent en continu à partir de plusieurs sources en amont (NVD, GHSA, Red Hat, AWS, Debian, etc.) ; les mises à jour sont automatiques avec une actualisation programmée du cache et le mode hors ligne applique des extractions de base de données personnalisées pour les domaines isolés.
Qu'est-ce que le modèle .trivyignore ?
Un fichier d'identifiants CVE (éventuellement avec des commentaires d'expiration) que Trivy ignore ; la discipline consiste en des entrées datées d'expiration avec justification et un examen trimestriel, traitées explicitement comme un risque accepté plutôt que silencieusement permanent.
L'analyse au moment de la construction couvre-t-elle le risque de manière adéquate ?
Il couvre ce qui a été expédié ; Les CVE sont publiés en continu, alors associez la porte du pipeline à de nouvelles analyses programmées des images en cours d'exécution et à des contrôles de temps d'admission dans les clusters, car le delta entre le jour de construction et la semaine de déploiement est l'endroit où se situe l'exposition manquée.
Comment Kinetikatech vous aide avec outils de sécurité open source
C'est notre quotidien : Les professionnels de la boîte à outils de test restent chargés : les scanners, les renifleurs, les crackers et les proxys Web expliquent la manière dont ils sont utilisés lors d'engagements réels : commandes, indicateurs, sorties et où chacun se situe dans une méthodologie. Notre service Tests d'intrusion et Sécurité des serveurs Linux le couvre de bout en bout : évaluation, mise en œuvre, supervision 24/7 et intervention d'urgence en 30 minutes.