Analyse statique Terraform
| Fiche express | |
|---|---|
| Type | Analyse statique de code IaC (avant apply)
|
| Lint bonnes pratiques | tflint |
| Scanners sécurité/conformité | checkov, tfsec |
| Positionnement pipeline | Après plan, avant apply — étape de type gate
|
| Voir aussi | Terraform — Concepts fondamentaux · Integration continue |
L'analyse statique du code Terraform/OpenTofu consiste à examiner les fichiers .tf sans les exécuter (donc sans toucher à l'infrastructure réelle ni au state), pour détecter en amont des erreurs de style, des mauvaises pratiques ou des failles de sécurité/conformité. Trois outils reviennent systématiquement dans ce rôle : tflint (lint orienté bonnes pratiques et erreurs de provider), checkov et tfsec (scanners orientés sécurité et conformité). Cette page les présente ensemble, en comparatif, plutôt qu'en fiches séparées : ils sont complémentaires et souvent combinés dans une même pipeline.
Pourquoi analyser avant d'appliquer
terraform plan valide la syntaxe et calcule un diff, mais ne juge à aucun moment de la qualité ou de la sécurité du code : un plan peut être parfaitement valide et pourtant provisionner un bucket de stockage public, un groupe de sécurité ouvert à 0.0.0.0/0, ou un disque non chiffré. Les outils d'analyse statique comblent ce vide en appliquant un jeu de règles au code source avant qu'il ne soit exécuté, typiquement dans une CI (intégration continue), en bloquant la fusion d'une merge request ou l'exécution d'un apply si des règles bloquantes sont violées.
<mermaid> flowchart LR
C[Code HCL
*.tf] --> L[tflint
lint bonnes pratiques] C --> CK[checkov
sécurité / conformité] C --> TS[tfsec
sécurité] L --> G{Gate CI} CK --> G TS --> G G -->|OK| P[terraform plan] P --> A[terraform apply] G -->|violations bloquantes| X[Échec pipeline]
</mermaid>
tflint
tflint se concentre sur le lint au sens classique : erreurs qui échapperaient à terraform validate (qui ne vérifie que la syntaxe et la cohérence interne du HCL), mais que plan/apply ne révéleraient qu'à l'exécution, voire jamais. Exemples typiques : type d'instance invalide pour un provider donné, variable déclarée mais jamais utilisée, référence à un attribut qui n'existe pas sur une ressource, incohérence de nommage.
Fonctionne par plugins spécifiques à chaque provider (AWS, Azure, GCP...), ce qui lui permet de connaître le schéma exact des ressources et d'y détecter des valeurs invalides.
tflint --init # installe les plugins déclarés dans .tflint.hcl
tflint # analyse le répertoire courant
# .tflint.hcl
plugin "aws" {
enabled = true
version = "0.30.0"
source = "github.com/terraform-linters/tflint-ruleset-aws"
}
rule "terraform_unused_declarations" {
enabled = true
}
checkov
checkov (Bridgecrew/Palo Alto Networks) est un scanner de sécurité et de conformité multi-format : Terraform, mais aussi CloudFormation, Kubernetes manifests, Dockerfile, ARM templates. Il embarque plusieurs centaines de règles prédéfinies (chiffrement au repos manquant, ressource exposée publiquement, IAM trop permissif...) mappées, pour beaucoup, à des référentiels de conformité reconnus (CIS Benchmarks, PCI-DSS, SOC2 — couverture exacte à vérifier selon la version).
checkov -d . # scanne le répertoire courant
checkov -d . --framework terraform # limite le scan aux fichiers Terraform
checkov -d . --skip-check CKV_AWS_20 # ignore une règle précise
Checkov peut aussi analyser le plan JSON (terraform show -json plan.out) plutôt que le code source brut, ce qui permet de détecter des problèmes qui ne deviennent visibles qu'une fois les variables résolues et les modules développés.
tfsec
tfsec est également un scanner de sécurité dédié à Terraform, historiquement plus ciblé et plus rapide que checkov sur ce seul périmètre. Racheté par Aqua Security, son moteur de règles a depuis été fusionné dans Trivy (le scanner généraliste d'Aqua couvrant conteneurs, IaC et vulnérabilités) — tfsec en tant que projet autonome est en fin de vie / mode maintenance réduite (statut précis à vérifier au moment de l'usage : privilégier trivy config pour un usage nouveau).
tfsec .
# ou, avec Trivy (successeur) :
trivy config .
Comparatif
| tflint | checkov | tfsec (→ Trivy) | |
|---|---|---|---|
| Objectif principal | Lint / bonnes pratiques / erreurs provider | Sécurité + conformité multi-format | Sécurité IaC (Terraform, puis multi-format via Trivy) |
| Portée | Terraform (via plugins par provider) | Terraform, Kubernetes, CloudFormation, Dockerfile... | Terraform historiquement ; élargi via Trivy |
| Connaissance du schéma provider | Oui (règles par plugin provider) | Partielle (règles génériques + spécifiques) | Partielle |
| Référentiels de conformité | Non | CIS, PCI-DSS... (mapping intégré) | Limité en tant que tel ; Trivy en hérite |
| Statut du projet | Actif | Actif | Fusionné dans Trivy, usage historique |
Ces outils ne sont pas mutuellement exclusifs : il est courant de faire tourner tflint pour les erreurs de configuration et les bonnes pratiques provider, et checkov (ou Trivy) pour la couverture sécurité/conformité, dans la même pipeline.
Intégration en pipeline CI
Placement typique dans un pipeline d'intégration continue gérant du Terraform :
terraform fmt -check— formatage.terraform validate— validité syntaxique/interne.- tflint — bonnes pratiques et erreurs spécifiques au provider.
- checkov / tfsec (Trivy) — sécurité et conformité.
terraform plan— diff, éventuellement soumis à revue humaine (merge request).terraform apply— seulement après validation de toutes les étapes précédentes, généralement sur la branche principale ou via approbation manuelle.
Les violations bloquantes (sévérité haute : secrets en clair, exposition publique) font échouer le pipeline ; les violations mineures peuvent être remontées en avertissement sans bloquer, selon la politique de l'équipe. Les deux catégories d'outils (lint et sécurité) sont volontairement gardées distinctes dans le pipeline : un échec tflint signale un problème de qualité/maintenabilité, un échec checkov/tfsec signale un risque de sécurité — traiter les deux avec la même sévérité peut noyer les alertes réellement critiques.