Trivy

Trivy scanne images Docker, dépendances et IaC pour les CVE. Branché en CI : nous arrêtons une release pourrie avant qu’elle parte en prod.

Open source Aqua, multi-cibles (fs, image, repo), intégration CI simple. La cybersécurité commence dans le pipeline.

Trivy est un scanner de vulnérabilités : dépendances applicatives, images de conteneurs, configurations. Nous le branchons dans la CI (GitHub Actions / Bitbucket) pour que « merge » ne veuille pas dire « CVE connue en prod ». Complément de CrowdSec (runtime) et de la veille TMA.

Trivy, dans le socle Innovation Digitale, ce n’est pas une case à cocher sur une slide commerciale. C’est une brique que nous assumons en production : nous savons l’installer, la documenter, la tester, et la transmettre à une autre équipe. Le positionnement « vulnérabilités avant la prod » résume le job ; le reste de cette fiche explique comment nous l’utilisons sur des projets réels — apps métier, APIs, modernisation, automatisation, TMA.

Beaucoup d’agences empilent les logos. Nous documentons le pourquoi et le comment. Trivy fait partie du socle parce qu’il tient dans le temps : documentation solide, communauté active, écosystème de talents, et une trajectoire qui ne force pas à tout jeter tous les dix-huit mois. C’est exactement le critère que nous appliquons quand un client demande un système qui doit encore tourner dans cinq ans.

Open source Aqua, multi-cibles (fs, image, repo), intégration CI simple. La cybersécurité commence dans le pipeline.

Le critère n°1, c’est la stabilité opérationnelle. Trivy s’inscrit dans un écosystème où le scan de vulnérabilités, la supply chain et le pipeline sont des sujets documentés, pas des bricolages. Quand un incident arrive à 2h du matin, nous voulons des patterns connus, des alertes actionnables, une communauté qui a déjà croisé le même cas — pas un outil abandonné six mois après le lancement.

Le critère n°2, c’est la documentation et la transmissibilité. Un logiciel qui vous appartient, c’est aussi un logiciel qu’une autre équipe peut reprendre. Trivy se recrute, s’audit, se forme. Nous pouvons écrire une doc courte, des critères Gherkin, une CI qui reste verte : le savoir ne reste pas dans la tête d’un seul prestataire.

Le critère n°3, c’est l’alignement avec la souveraineté numérique. Open source ou API maîtrisée, hébergement UE/FR possible selon le projet (Scaleway, OVHcloud), code remis au client : Trivy n’impose pas une cage propriétaire. Nous encapsulons derrière des ports hexagonaux quand c’est pertinent, pour pouvoir changer de brique sans réécrire le métier.

Sur un Brief ou un audit, nous partons du problème métier — pas de la techno. Ensuite seulement, Trivy entre en scène si c’est le bon outil. Exemple typique : une application métier Symfony + React, une API documentée, une base PostgreSQL, une CI, des tests qui protègent le domaine — et un run (TMA) qui voit les pannes et les risques avant le client. Trivy trouve sa place dans ce puzzle sans forcer le reste.

Concrètement, nous posons des frontières : domaine métier au centre, adapters pour l’UI, la BDD, les SaaS externes. Trivy vit surtout en périphérie (observabilité, sécurité, hébergement) — mais c’est là que le réel se joue après la mise en production. Dans tous les cas, nous documentons le « pourquoi ce choix » dans le dépôt : un futur mainteneur ne doit pas devoir deviner.

La qualité & méthode n’est pas un chapitre à part. Dès que Trivy touche du code ou de l’infra, nous le branchons dans le pipeline ou le runbook. Vert / silencieux = on peut dormir. Rouge / alerte = nous agissons avant la casse. C’est banal à écrire, radical à tenir — et c’est ce qui sépare un POC fragile d’un actif logiciel.

Pour les startups (POC / Build / scale) comme pour les PME/ETI, le même standard s’applique. Nous ne « faisons pas du Trivy pour faire du Trivy ». Nous l’utilisons pour un run propre : moins d’angles morts, des alertes utiles, plus de capacité à évoluer sans tout casser.

Trivy est un excellent choix quand le besoin touche le scan de vulnérabilités, la supply chain et le pipeline, et que l’horizon du projet dépasse le trimestre. Si vous devez recruter, auditer, ou transmettre le SI, une brique mainstream et documentée comme Trivy réduit le risque opérationnel.

Nous passons notre tour quand un autre outil du socle couvre mieux le cas, ou quand l’existant client impose une contrainte claire (stack imposée, hébergeur, compétences internes). Exemple : sur une vitrine Eleventy sans conteneur, Dependabot / Renovate peut suffire ; Trivy brille dès qu’il y a images Docker ou deps lourdes. L’honnêteté du discours fait partie de la méthode.

Nous évitons aussi les empilements « parce que c’est moderne ». Ajouter Trivy doit résoudre un goulot : CVE connues, images obsolètes, dette de dépendances. Si le seul argument est le buzzword, ce n’est pas un argument.

Innovation Digitale choisit des technologies avec une trajectoire longue : versions majeures gérables, guides officiels à jour, issues et discussions publiques. Trivy coche ces cases. Ce n’est pas une garantie absolue — rien ne l’est — mais c’est un filtre qui élimine les paris jetables.

La communauté active, ça veut dire des réponses, des packages, des retours d’expérience. Ça veut aussi dire qu’un prestataire suivant pourra reprendre le flambeau. Pour un dirigeant, c’est aussi important que la feature list : la dépendance à une seule personne ou à un éditeur opaque, nous la refusons autant que possible.

Côté souveraineté made in France / Europe : selon le rôle de Trivy, nous privilégions les options UE (Scaleway, OVHcloud, self-host) quand le sujet data ou politique l’exige. Le site vitrine iD peut tourner sur Netlify ; vos apps métier, elles, choisissent l’hébergeur adapté.

En résumé : Trivy dans le socle iD, c’est une garantie de continuité : méthode avant magie. Une brique que nous expliquons, que nous testons, que nous documentons — et que vous possédez avec le reste du code.

Si vous hésitez entre plusieurs options (BDD, front, cloud, monitoring, sécu), le Brief 45 min sert exactement à ça : clarifier le problème, le risque, le périmètre, puis proposer un audit si le sujet tient la route. La stack suit le besoin — pas l’inverse.

Pour aller plus loin : consultez la documentation et le dépôt officiels ci-dessous, parcourez les autres fiches du socle, et regardez les réalisations (problématique → solution → résultat) pour voir Trivy (ou ses cousins) en situation réelle.