L’integration de la securite directement dans les pipelines CI/CD, approche connue sous le terme DevSecOps, est devenue une exigence incontournable en 2026 pour toute equipe de developpement soucieuse de livrer des logiciels fiables. Trivy (Aqua Security) et Snyk sont deux des outils les plus adoptes pour automatiser les scans de vulnerabilites dans les images Docker, les dependances applicatives et les fichiers d’infrastructure as code. Ce tutoriel explique comment integrer ces deux outils dans un pipeline GitHub Actions pour obtenir une couverture de securite complete a chaque pull request.
DevSecOps en 2026 : pourquoi automatiser les audits de securite
Le modele traditionnel ou la securite est verifiee en fin de cycle de developpement s’est revele insuffisant face a la cadence des deployements modernes. Des equipes qui deployent plusieurs fois par jour en production n’ont pas le temps d’attendre un audit manuel a chaque iteration. Le DevSecOps repond a ce defi en deplacant les controles de securite le plus tot possible dans le cycle, idealement des le commit avant meme l’integration dans la branche principale, ce que les praticiens appellent l’approche shift-left security.
Les couts de correction des vulnerabilites augmentent exponentiellement avec le temps. Une faille detectee lors du developpement coute en moyenne 10 fois moins a corriger que si elle est decouverte en phase de test, et 100 fois moins que si elle est exploitee en production. Cette realite economique, documentee par plusieurs etudes du Ponemon Institute et IBM Security, justifie pleinement l’investissement dans des outils d’analyse automatisee integres au pipeline. Trivy et Snyk permettent de capter des classes entieres de vulnerabilites avant qu’elles n’atteignent un environnement expose aux utilisateurs finaux.
En 2026, les exigences reglementaires renforcent encore cet imperatif. Le reglement europeen Cyber Resilience Act impose aux editeurs de logiciels commerciaux de demontrer la mise en place de processus de gestion des vulnerabilites tout au long du cycle de vie du produit. La directive NIS2 etend ces obligations a un spectre plus large d’organisations dans les secteurs critiques. Des outils comme Trivy et Snyk, en produisant des rapports de scan horodates et tracables, contribuent directement a la documentation de conformite exigee par ces referentiels reglementaires europeens.
Trivy : scanner de vulnerabilites polyvalent et open source
Trivy est un scanner de securite open source developpe par Aqua Security, disponible sous licence Apache 2.0. Sa grande force reside dans sa polyvalence : il analyse les images de conteneurs Docker/OCI, les dependances applicatives (npm, pip, maven, gem, cargo), les fichiers de configuration d’infrastructure as code (Terraform, CloudFormation, Kubernetes manifests, Helm charts) et les depots Git entiers a la recherche de secrets exposes. Un seul outil couvre ainsi un perimetre qui necessitait auparavant trois a quatre solutions specialisees distinctes dans les pipelines CI/CD les plus avances.
La base de donnees de vulnerabilites de Trivy aggregate les sources NVD (NIST), les advisories des distributions Linux (RedHat, Debian, Ubuntu, Alpine, Amazon Linux), les bases GitHub Advisory et les donnees Open Source Vulnerabilities (OSV). Cette base est mise a jour quotidiennement et peut etre mise en cache localement pour accelerer les scans repetitifs en CI/CD, eliminant la latence due au telechargement de la base a chaque execution. Trivy supporte egalement les SBOM au format CycloneDX ou SPDX, permettant de generer des inventaires de composants logiciels conformes aux exigences du CRA europeen.
L’un des avantages pratiques de Trivy est sa vitesse d’execution. Un scan complet d’une image Docker Node.js de taille moyenne s’effectue en 15 a 30 secondes apres initialisation du cache, ce qui le rend parfaitement adapte a une integration dans un pipeline sans allonger significativement le temps total de build. Sa sortie est disponible en plusieurs formats : tableau humain-lisible pour les logs CI, JSON pour le traitement programmatique, SARIF pour l’integration avec GitHub Security, et templates Go personnalises pour les rapports adaptes a des besoins specifiques d’equipe.
Snyk : securite des dependances avec remediation guidee
Snyk se distingue de Trivy par son positionnement freemium et par l’accent mis sur la remediation guidee. La ou Trivy signale qu’une dependance est vulnerables, Snyk indique precisement quelle version corrigee cibler, si un patch partiel existe, et propose parfois une pull request automatique de mise a jour via son integration GitHub et GitLab. Cette couche de guidance transforme un scan passif en un veritable accelerateur de remediation pour les developpeurs qui n’ont pas toujours le contexte securite pour interpreter correctement les resultats de scan bruts.
Le plan gratuit de Snyk autorise jusqu’a 200 tests ouverts par mois, suffisant pour un projet individuel ou une petite equipe. Les plans payants debloquent les tests illimites, les politiques de securite organisationnelles et les rapports de conformite avances. Snyk propose egalement une CLI utilisable en local et un plugin pour les IDE les plus populaires (VS Code, IntelliJ), permettant aux developpeurs de detecter les vulnerabilites avant meme de committer leur code, ce qui accelere encore davantage la resolution en eliminant les allers-retours entre developpement et revue de securite.
Snyk Code est le module d’analyse statique de Snyk, qui analyse le code source a la recherche de patterns de code vulnerables (injections SQL, XSS, deserialisations non securisees, gestion incorrecte des secrets). Contrairement aux scanners SAST traditionnels qui generent un volume eleve de faux positifs, Snyk Code utilise un modele de machine learning entraine sur des millions de lignes de code reel pour ameliorer la precision des resultats. Les alertes sont directement visibles dans l’interface GitHub via les Security alerts, sans necessiter de connexion supplementaire a un tableau de bord externe.
Configuration d’un pipeline GitHub Actions complet
L’integration de Trivy et Snyk dans GitHub Actions se fait via des actions officielles disponibles dans le GitHub Marketplace. Le pipeline illustre ci-dessous couvre une configuration typique pour un projet Node.js containerise : scan des dependances npm avec Snyk sur chaque pull request, build de l’image Docker, puis scan de l’image avec Trivy avant publication dans le registry. Cette double couverture garantit que ni les dependances applicatives ni les composants du systeme de base (libc, openssl, etc.) ne presentent de CVE critiques non traitees dans les artefacts livres en production.
La gestion des secrets dans le pipeline est un point critique : la cle API Snyk doit etre stockee comme secret GitHub (Settings, Secrets and variables, Actions) et jamais ecrite en dur dans le fichier de workflow. Pour Trivy, aucune cle API n’est necessaire sur le plan open source, ce qui simplifie la configuration. Si le pipeline doit publier les resultats vers un dashboard centralise (Snyk Dashboard, Aqua Platform, Defect Dojo), configurer les credentials correspondants comme secrets GitHub supplementaires en suivant le principe du moindre privilege pour chaque credential utilise.
Une decision architecturale importante concerne le comportement du pipeline en cas de vulnerabilites detectees : blocage du merge si des CVE critiques sont trouvees, ou simple rapport sans blocage. En production, l’approche recommandee est un blocage sur les CVE de score CVSS superieur ou egal a 9.0, un rapport informatif sur les CVE entre 7.0 et 8.9, avec une periode de grace de 30 jours pour les dependances transitives sans vecteur d’exploitation disponible. Cette graduation evite de bloquer completement le pipeline pour des vulnerabilites theoriques sans impact reel confirme.
# .github/workflows/security-scan.yml
name: Security Audit
on: [push, pull_request]
jobs:
snyk-deps:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high
trivy-image:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: docker build -t myapp:${{ github.sha }} .
- uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
format: sarif
output: trivy-results.sarif
severity: CRITICAL,HIGH
exit-code: 1
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: trivy-results.sarif
trivy-sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: trivy image --format cyclonedx --output sbom.json myapp:${{ github.sha }}
- uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.jsonGenerer et exploiter un SBOM avec Trivy
Le Software Bill of Materials est devenu un artefact de conformite exige par plusieurs reglementations et clients enterprise en 2026. Trivy permet de generer des SBOM au format CycloneDX (JSON/XML) ou SPDX en une seule commande. Ces SBOM listent exhaustivement tous les composants logiciels inclus dans une image ou un projet : bibliotheques open source, versions exactes, licences, hash des archives sources. Cela permet une analyse d’impact immediate lorsqu’une nouvelle CVE est publiee pour un composant donne, sans avoir a relancer un scan complet du pipeline de build.
L’integration du SBOM dans le pipeline CI/CD permet de le versionner et de le publier automatiquement comme artefact de build. Avec GitHub Actions, l’action attest-build-provenance permet d’attacher une attestation de provenance cryptographiquement signee a l’image Docker publiee, incluant le SBOM. Ces attestations peuvent ensuite etre verifiees par des outils comme cosign (Sigstore) pour garantir que l’image deployee en production correspond bien a ce qui a ete construit dans le pipeline CI/CD, une protection efficace contre les attaques de supply chain de plus en plus frequentes.
Pour les organisations soumises aux exigences du Cyber Resilience Act ou aux recommandations de la CISA en matiere de securite de la chaine d’approvisionnement logicielle, maintenir un SBOM a jour et horodate pour chaque version de production est devenu une obligation de fait. Trivy peut etre configure pour scanner automatiquement les SBOM existants contre les nouvelles CVE publiees chaque jour, une fonctionnalite de continuous vulnerability monitoring qui alerte l’equipe de securite sans necessiter un nouveau build complet, reduisant considerablement le delai de detection.
Gestion des faux positifs et des exceptions documentees
Tout outil d’analyse de securite genere un certain volume de faux positifs ou de vulnerabilites non exploitables dans le contexte specifique de l’application analysee. Trivy supporte les fichiers de configuration d’ignorance (.trivyignore) qui permettent de documenter les CVE acceptees avec une justification textuelle et une date d’expiration de l’exception. Cette approche est preferable a la simple suppression silencieuse : elle force une decision documentee et limite la duree de l’exception pour obliger une reevaluation periodique par l’equipe de securite.
Snyk propose un mecanisme similaire via les Snyk Ignore appliques depuis l’interface web ou la CLI. Chaque exception peut etre associee a un motif (CVE non applicable, patch en cours, risque accepte), a une date d’expiration et a l’identite de l’auteur. Ces exceptions sont horodatees et auditables, ce qui repond aux exigences de tracabilite des processus de gestion des risques de securite. Pour les organisations certifiees ISO 27001, ce niveau de documentation peut directement alimenter le registre des risques de securite de l’information tenu a jour par le RSSI.
La calibration des seuils de blocage est un exercice delicat qui doit tenir compte de la realite operationnelle de l’equipe. Un seuil trop bas risque de generer une fatigue d’alerte qui pousse les developpeurs a desactiver les controles ou a accumuler les exceptions sans analyse serieuse. Un seuil trop haut laisse passer trop de risques reels. L’approche par criticite combinee aux donnees d’exploitation active (presence dans le KEV CISA ou score EPSS eleve) est la plus efficace pour concentrer les efforts sur les vulnerabilites representant un risque reel et actionnable pour l’organisation.
Monitoring continu et integration SIEM
L’audit ponctuel au moment du commit ou du deployement ne suffit pas : de nouvelles CVE sont publiees chaque jour qui peuvent affecter des images deja en production. Plusieurs outils permettent de surveiller en continu les images deployees : Trivy Operator pour Kubernetes surveille les pods en cours d’execution et genere des rapports VulnerabilityReport en resources Kubernetes natives. Snyk Container Monitor et Aqua Platform couvrent les besoins des environnements enterprise avec des tableaux de bord centralises et des alertes configurables par severite et par equipe responsable.
L’integration des resultats de scan dans un SIEM (Splunk, Elastic SIEM, Microsoft Sentinel) permet de corroler les alertes de vulnerabilites avec d’autres evenements de securite. La combinaison d’une CVE critique non patchee dans un service expose et d’une tentative d’exploitation detectee dans les logs d’acces constitue un signal d’alerte haute priorite que seule une vision correlee permet d’identifier rapidement. Les formats SARIF et JSON produits par Trivy s’integrent nativement dans les pipelines d’ingestion de donnees des principaux SIEM du marche actuel.
Documenter les metriques de securite dans des tableaux de bord visibles par les equipes de developpement et de management est un levier d’amelioration continue souvent sous-estime. Des KPI comme le temps moyen de remediation pour les CVE critiques, le pourcentage de builds bloques par des vulnerabilites, ou l’evolution du nombre de dependances obsoletes sur 12 mois creent une pression positive vers l’amelioration continue de la posture de securite. Des outils comme Grafana connectes aux APIs de Snyk et Trivy permettent de construire ces tableaux de bord en quelques heures seulement.
Bonnes pratiques pour perenniser la demarche DevSecOps
La mise en place technique de Trivy et Snyk dans le pipeline n’est que la premiere etape d’une demarche DevSecOps durable. Pour que les controles restent effectifs dans le temps, il est indispensable de designer des Security Champions au sein des equipes de developpement : des developpeurs formes aux enjeux de securite qui font le lien entre les equipes securite et developpement, et qui peuvent repondre rapidement aux alertes sans mobiliser systematiquement des experts securite exterieurs, ce qui cree un goulot d’etranglement dans les organisations a cadence de deployement elevee.
La mise a jour reguliere des outils eux-memes est souvent negligee. Trivy et Snyk publient des mises a jour frequentes pour ameliorer la precision des detections et ajouter le support de nouveaux ecosystemes. Epingler des versions specifiques dans le pipeline CI/CD, bonne pratique pour la reproductibilite des builds, doit etre couple a un processus de mise a jour programme. Des outils comme Dependabot ou Renovate peuvent automatiser les pull requests de mise a jour des versions d’actions GitHub utilisees dans les workflows de securite.
Former l’ensemble des developpeurs a la lecture et a l’interpretation des rapports de scan est un investissement rentable sur le long terme. Un developpeur qui comprend la difference entre une CVE critique avec un exploit public disponible et une CVE haute sans vecteur d’acces reseau prend de meilleures decisions de priorisation. Des sessions de formation courtes integrees dans l’onboarding des nouveaux developpeurs, portant sur la lecture des scores CVSS et EPSS, contribuent a construire une culture de securite partagee plutot qu’un controle percu comme une contrainte imposee de l’exterieur.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.