Auditer son IaC et son cloud : Trivy, KICS et Prowler¶

Sécuriser son infrastructure, ça se joue à deux moments bien distincts :

1. Avant le déploiement, sur ton code d'Infrastructure as Code (Terraform, manifests Kubernetes, Helm, CloudFormation...). C'est le shift-left : on détecte le bucket public ou le security group ouvert à 0.0.0.0/0 dans la merge request, avant qu'il n'existe. C'est le terrain de Trivy et KICS.
2. Après le déploiement, sur ce qui tourne réellement dans ton compte cloud. C'est la Cloud Security Posture Management (CSPM) : on vérifie la configuration effective, y compris tout ce qui a été modifié à la main dans la console. C'est le terrain de Prowler.

Les deux approches ne se remplacent pas : un scanner d'IaC ne voit pas ce qui a été créé hors Terraform, et un outil de CSPM découvre le problème une fois qu'il est en production. Je te propose de voir les trois outils, puis comment les combiner dans ta CI.

flowchart LR
    A[Code IaC<br/>Terraform, K8s, Helm] -->|merge request| B[Trivy / KICS<br/>scan statique]
    B -->|OK| C[terraform apply]
    C --> D[Compte cloud<br/>AWS, Azure, GCP]
    D -->|scan planifié| E[Prowler<br/>posture cloud]
    E -->|findings| A

Trivy : le scanner IaC polyvalent¶

Trivy est un outil open source développé par Aqua Security, conçu pour analyser les vulnérabilités et les mauvaises configurations dans divers artefacts, y compris les configurations d'Infrastructure as Code.

tfsec a été intégré à Trivy : son dépôt ne reçoit plus de nouvelles fonctionnalités et Aqua Security recommande de migrer vers trivy config, qui reprend ses règles pour Terraform.

Fonctionnalités principales¶

• Détection automatique des types de configuration : Trivy identifie automatiquement les types de fichiers IaC présents dans un répertoire (Terraform, CloudFormation, Kubernetes, Helm, Dockerfile...) et applique les règles pertinentes.
• Large couverture de règles : grâce à l'intégration de tfsec, Trivy dispose d'une vaste bibliothèque de règles de sécurité pour Terraform.
• Un seul outil pour plusieurs usages : le même binaire scanne aussi tes images de conteneurs, tes dépendances et les secrets oubliés dans le code. Si tu l'utilises déjà en CI pour tes images, trivy config ne te coûte rien de plus.

Utilisation en local¶

Pour analyser un répertoire contenant des fichiers Terraform :

trivy config <chemin/vers/le/répertoire>

Trivy fournit un rapport des mauvaises configurations détectées, avec leur gravité et des recommandations pour les corriger. Quelques options qui servent tous les jours :

• --severity HIGH,CRITICAL pour ne garder que l'essentiel ;
• --exit-code 1 pour faire échouer la commande (et donc le job de CI) quand un problème est trouvé ;
• -f sarif pour produire un rapport SARIF, lisible par la plupart des outils de revue de code.

Exemple de déclaration d'un CDN qui n'utilise pas de Web Application Firewall (WAF) :

Scanner le plan plutôt que le code¶

Sur du Terraform qui utilise beaucoup de variables et de modules, le scan du code HCL ne connaît pas toujours les valeurs finales. Tu peux scanner le plan à la place, où tout est résolu :

terraform plan -out tfplan
terraform show -json tfplan > tfplan.json
trivy config tfplan.json

Ignorer un faux positif¶

Certaines règles ne s'appliquent pas à ton contexte. Exemple classique : la règle qui exige les logs d'accès sur chaque bucket S3 n'a pas de sens sur le bucket qui reçoit justement ces logs. Plutôt que de désactiver la règle partout, ignore-la sur la ressource concernée avec un commentaire placé juste avant, et documente pourquoi :

# Bucket de destination des logs d'accès : il ne peut pas se loguer lui-même
#trivy:ignore:AVD-AWS-0089
resource "aws_s3_bucket" "access_logs" {
  bucket = "mon-projet-access-logs"
}

L'identifiant de la règle (ici AVD-AWS-0089, l'activation des logs S3) est affiché dans le rapport de Trivy. Tu peux aussi utiliser sa forme longue, aws-s3-enable-logging.

Utilisation dans GitLab CI¶

1
2
3
4
5
6
7

trivy-terraform-iac:
    stage: sast
    image:
        name: aquasec/trivy:0.76.0
        entrypoint: [""]
    script:
        - trivy config --exit-code 1 --severity HIGH,CRITICAL .

KICS : l'alternative de Checkmarx¶

KICS (Keeping Infrastructure as Code Secure) est un outil open source développé par Checkmarx, conçu pour détecter les vulnérabilités de sécurité, les problèmes de conformité et les erreurs de configuration dans les fichiers d'Infrastructure as Code dès les premières étapes du cycle de développement. Contrairement à Trivy, il ne fait que de l'IaC, mais il le fait sur un large éventail de formats.

Utilisation en local¶

Une fois installé, KICS s'exécute en ligne de commande. Par exemple, pour analyser un dossier contenant du Terraform :

kics scan -p <ton_dossier_a_scanner>

KICS génère ensuite un rapport détaillant les vulnérabilités et les erreurs de configuration détectées, facilitant leur correction avant le déploiement.

Tu peux voir ici qu'un de mes buckets S3 est accessible en lecture publique sur Internet

Les options à connaître :

• --fail-on high,critical : seules ces gravités font sortir KICS en erreur (par défaut, toutes les gravités le font) ;
• --report-formats : choisis le ou les formats du rapport (json, sarif, html, glsast pour GitLab...) et -o pour le dossier de sortie ;
• --exclude-severities info,low : retire le bruit des rapports.

Pour un faux positif, KICS se pilote aussi par commentaire dans le code : # kics-scan ignore-line au-dessus de la ligne concernée, ou # kics-scan ignore-block pour tout un bloc.

Utilisation dans GitLab CI¶

KICS sait produire un rapport au format SAST de GitLab, que tu déclares comme rapport du job :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

kics-iac:
    stage: sast
    image:
        name: checkmarx/kics:v2.2.0 # épingle une version, jamais latest
        entrypoint: [""]
    script:
        - kics scan -p ${PWD} --fail-on high,critical --report-formats glsast -o ${PWD} --output-name kics-results
    artifacts:
        reports:
            sast: gl-sast-kics-results.json
        when: always

Trivy ou KICS ?¶

Mon conseil : si tu utilises déjà Trivy pour tes images, commence par trivy config, tu n'ajoutes aucun outil à maintenir. KICS est un bon second avis si tu veux croiser les résultats, ou si ton dépôt mélange beaucoup de formats d'IaC différents. Évite en revanche de faire tourner les deux en mode bloquant dès le départ : tu doubles les faux positifs à trier.

Prowler : auditer ce qui tourne vraiment¶

Prowler est un outil open source de sécurité cloud conçu pour évaluer les bonnes pratiques, effectuer des audits, répondre aux incidents et assurer une surveillance continue sur AWS, Azure, Google Cloud et Kubernetes. Là où Trivy et KICS lisent ton code, Prowler interroge les API de ton fournisseur cloud et compare la configuration réelle à des centaines de contrôles et de référentiels de conformité (CIS, PCI-DSS, ISO 27001...).

Exemple sur mon compte AWS qui fait tourner mon site web, sur l'ensemble des référentiels de conformité à vérifier

Ici on voit en détail l'utilisation du compte root, une mauvaise pratique à proscrire

Lancer un audit¶

Pour effectuer une évaluation sur AWS :

prowler aws

Pour Azure, une méthode d'authentification est obligatoire (--az-cli-auth, --sp-env-auth, --browser-auth ou --managed-identity-auth) :

prowler azure --az-cli-auth

Pour Google Cloud :

prowler gcp

Pour Kubernetes :

prowler kubernetes

Cibler l'audit¶

Un audit complet remonte beaucoup de résultats. Pour te concentrer sur l'essentiel :

# Lister les référentiels de conformité disponibles pour ton fournisseur
prowler aws --list-compliance

# Auditer selon un référentiel précis (identifiant issu de la liste précédente)
prowler aws --compliance <referentiel>

# Ne garder que les contrôles critiques et élevés, sur quelques services
prowler aws --severity critical high --services s3 iam

# Choisir les formats de sortie (par défaut : csv, json-ocsf et html)
prowler aws -M csv html

Des droits en lecture seule¶

Prowler n'a besoin que de lire ta configuration. Sur AWS, la documentation recommande les politiques managées SecurityAudit et ViewOnlyAccess, complétées par une petite politique additionnelle fournie dans le dépôt de Prowler pour quelques services. Ne le lance jamais avec un compte administrateur : un outil d'audit n'a aucune raison de pouvoir modifier ce qu'il audite.

Les interfaces web¶

Prowler propose deux interfaces graphiques :

• Dashboard local : après une analyse en CLI, lance prowler dashboard puis ouvre http://localhost:11666 pour explorer les résultats.
• Prowler App : application web complète (API, UI et base de données) déployée via Docker Compose, accessible sur http://localhost:3000, pour configurer et exécuter des analyses, visualiser les résultats et gérer tes findings.

Combiner les trois dans ta CI¶

Une organisation simple et efficace :

• Sur chaque merge request : trivy config (ou KICS) en mode bloquant sur les gravités HIGH et CRITICAL, sur le code et idéalement sur le plan Terraform. Le développeur corrige avant de fusionner.
• Sur un pipeline planifié (une fois par jour ou par semaine) : Prowler sur chaque compte cloud, avec un rôle en lecture seule. Prowler sort avec le code 3 quand des contrôles échouent : c'est pratique pour marquer le pipeline en échec et déclencher une notification. Si tu veux seulement produire le rapport, ajoute -z (--ignore-exit-code-3).

Pour l'authentification de Prowler depuis la CI, préfère un rôle assumé via OIDC (fédération d'identité entre ton outil de CI et ton fournisseur cloud) à des clés d'accès statiques stockées en variables : il n'y a alors aucun secret longue durée à faire fuiter.

Pièges courants¶

• Tout bloquer dès le premier jour : sur un code existant, le premier scan remonte souvent des dizaines de résultats. Commence en mode informatif, corrige les critiques, puis rends le job bloquant gravité par gravité.
• Ignorer sans justifier : chaque trivy:ignore ou kics-scan ignore-line doit être accompagné d'un commentaire expliquant pourquoi. Sinon, six mois plus tard, personne ne sait plus si l'exception est encore valable.
• Croire que le scan d'IaC suffit : une ressource créée à la main dans la console, ou modifiée hors Terraform, n'apparaît jamais dans le code. Seul un audit du compte réel comme Prowler la voit.
• Utiliser des images non épinglées : tes outils de sécurité font partie de ta supply chain. Épingle leurs versions, idéalement par digest, comme le rappelle l'incident Trivy de mars 2026.

Pour aller plus loin¶

• Trivy pour scanner tes images et dépendances en CI : Analyse SAST et sécurité en CI/CD
• Écrire tes propres règles en Rego, le langage des checks personnalisés de Trivy et des requêtes de KICS : Définir des policies avec OPA
• Un autre scanner IaC, aujourd'hui archivé : Terrascan
• Le cours sur le durcissement des services cloud et de l'IaC : les slides et le TP