La sécurité logicielle reste souvent reléguée au second plan dans les cycles de développement rapides. Cette négligence crée des risques évitables et augmente la charge corrective après le déploiement.
L’approche DevSecOps impose d’intégrer des scans automatiques et des politiques codées dès la build. Les étapes pratiques pour automatiser conformité et vulnérabilités suivent immédiatement.
A retenir :
- Automatisation des scans vulnérabilités dans chaque pipeline CI/CD
- Policy-as-code pour vérification continue des exigences réglementaires et internes
- Inventaire SBOM signé et vérifié dans Kubernetes avant déploiement
- Blocage des builds sur vulnérabilités critiques et secrets exposés
Scanner vulnérabilités dans CI/CD avec Trivy et GitLab
Après la définition des priorités, il faut rendre les scans reproductibles et traçables dans les pipelines. L’automatisation assure une détection précoce et réduit le coût des corrections ultérieures.
Selon Aqua Security, Trivy couvre images, IaC, SBOM, clusters Kubernetes et comptes cloud. On peut ainsi ajouter Trivy au build, générer un SBOM et signer l’image avec Cosign.
Outil
Type de scan
Intégration CI
Licence
Remarques
Trivy
Vulnérabilités, config, secrets, SBOM
GitLab, GitHub, Jenkins
Open source (Apache‑2.0)
Maintenu par Aqua Security
Snyk
SCA, IaC, vulnérabilités
GitHub, GitLab, CI
Freemium SaaS
Intégration forte PR et remediation
SonarQube
SAST, qualité du code
Jenkins, GitLab
Community / Commercial
Bonne couverture règles SAST
Checkmarx
SAST entreprise
Intégrations enterprise
Commercial
Solution SAST dédiée aux grandes organisations
Intégration Trivy dans GitLab CI pour images et SBOM
Pour rendre les scans reproductibles, Trivy s’exécute facilement dans GitLab CI. Les variables d’environnement et le cache améliorent les temps et la sécurité des connexions aux registres.
Selon GitLab, il est courant d’utiliser des artefacts et des rapports JSON pour le suivi des scans. Une bonne pratique consiste à télécharger la base de vulnérabilités auparavant pour garantir la cohérence des résultats.
Exemples de commandes :
- trivy image –scanners vuln,secret alpine:latest
- trivy fs –scanners vuln ./project
- trivy repo –scanners config,secret github.com/org/repo
- trivy sbom –output sbom.json image:tag
« J’ai intégré Trivy dans notre pipeline GitLab et réduit les vulnérabilités critiques avant déploiement »
Paul N.
L’intégration simple masque cependant un besoin plus large de règles et d’enforcement policy-as-code. Il est donc nécessaire de formaliser ces règles pour automatiser les décisions de blocage.
Policy-as-code et conformité automatisée avec Terraform Sentinel
Pour automatiser le blocage, il faut formaliser les règles sous forme de policy-as-code dans le pipeline. HashiCorp Sentinel et d’autres moteurs permettent l’évaluation des plans Terraform avant application.
Selon GitLab, appliquer des règles codées accélère les audits et normalise les pratiques entre équipes. La politique doit inclure des seuils clairs pour les vulnérabilités et des actions correctives automatisées.
Définir des gates de conformité avec HashiCorp Sentinel et Terraform
Pour formaliser l’enforcement, Sentinel évalue les plans Terraform et bloque les applies non conformes. On peut mapper des contrôles CIS Docker ou CIS Kubernetes en règles lisibles et testables.
Un bench compliance peut être exécuté sur images, clusters et comptes cloud pour valider la conformité. Selon Aqua Security, ces benchs aident à prioriser les remédiations et à documenter les écarts.
Règles opérationnelles CI/CD :
- Blocage sur vulnérabilités critiques
- Exigence SBOM signé avant déploiement
- Scan IaC obligatoire pour chaque merge request
- Archivage des rapports pour audit
Benchmark
Cible
Applicabilité
Type d’exigence
CIS Docker
Images et runtime Docker
Conteneurs et registres
Configuration et pratiques
CIS Kubernetes
Clusters Kubernetes
API server, RBAC, workloads
Configuration et accès
AWS CIS
Comptes cloud
IAM, logging, réseau
Audit et infra
PCI-DSS (extrait)
Environnements PCI
Applications et données
Contrôles techniques et processus
« Nous avons imposé SBOM signé et réduit incidents liés aux bibliothèques »
Amélie N.
Une gouvernance policy-as-code bien définie réduit les faux positifs et clarifie les responsabilités entre équipes. La suite consiste à compléter ces politiques par des tests dynamiques et par la surveillance runtime.
Scans dynamiques, DAST et monitoring continu dans CI/CD
La gouvernance codée sécurise les builds, mais l’application en exécution nécessite des tests dynamiques et du monitoring. DAST et solutions runtime complètent les scans statiques pour couvrir les failles liées à l’environnement d’exécution.
Selon OWASP, DAST révèle des vulnérabilités d’interface et des erreurs de configuration non visibles en SAST. Selon Palo Alto Prisma Cloud, le monitoring runtime et la détection d’anomalies apportent une couche défensive essentielle.
DAST et tests runtime avec OWASP ZAP et Prisma Cloud
Pour valider le comportement en production, DAST s’exécute après déploiement sur un environnement isolé. Il est utile d’orchestrer ces tests depuis le pipeline pour reproduire les mêmes conditions de test.
Les outils comme OWASP ZAP ou Palo Alto Prisma Cloud fournissent des règles et des alertes adaptatives. La priorisation des incidents permet d’éviter une saturation des équipes opérationnelles par des faux positifs.
Étapes de test runtime :
- Déployer environnement de test isolé
- Exécuter DAST après déploiement
- Corriger prioritairement vulnérabilités critiques
- Mettre en place alertes et dashboards
« L’équipe de production a constaté une baisse des déploiements défectueux après l’automatisation des scans »
Sébastien N.
Boucler avec monitoring et feedback vers les développeurs
L’enchaînement entre DAST, policy-as-code et monitoring crée un cercle vertueux de corrections rapides. Des intégrations avec Slack, tickets JIRA ou merge requests facilitent la rétroaction et la correction.
Selon Aqua Security, la signature Cosign des SBOM et des images renforce la chaîne de confiance. Un feed continu des rapports vers les développeurs améliore la résolution et diminue les risques en production.
Bonnes pratiques opérationnelles :
- Signer SBOM et images
- Automatiser reopen et suivi des PR
- Définir seuils bloquants
- Archiver rapports pour audits
« À mon avis, l’automatisation des scans doit être un standard pour toute chaîne CI/CD moderne »
Laura N.
Source : Aqua Security, « Trivy documentation », GitHub ; GitLab, « GitLab CI/CD Security », GitLab Docs ; OWASP, « ZAP Project », OWASP.
