Checkov vérifie votre code d'infrastructure

Un bucket S3 public, un Security Group SSH ouvert au monde, un conteneur Kubernetes qui tourne en root… Ces erreurs de configuration sont à l’origine de la majorité des incidents de sécurité cloud. Le problème ? Elles passent souvent inaperçues jusqu’au déploiement — voire jusqu’à l’incident.

Checkov détecte ces problèmes avant qu’ils n’atteignent la production. Ce scanner open source analyse vos fichiers Terraform, Kubernetes, Dockerfile, Ansible et bien d’autres, en les comparant à plus de 800 règles de sécurité.

Qu’est-ce que Checkov ?

Checkov est un analyseur de code statique (SAST) spécialisé dans l’Infrastructure as Code. Développé par Prisma Cloud (Palo Alto Networks) et disponible sous licence Apache 2.0, il analyse votre code avant le déploiement pour identifier les problèmes de sécurité potentiels.

Comment ça fonctionne ?

Checkov compare votre code à une base de +800 politiques de sécurité (appelées « checks »). Chaque check vérifie une bonne pratique spécifique :

Exemple de check	Ce qu’il vérifie
CKV_AWS_20	Bucket S3 non accessible publiquement
CKV_AWS_24	Security Group n’autorise pas SSH depuis 0.0.0.0/0
CKV_K8S_1	Conteneur Kubernetes ne partage pas le PID du host
CKV_DOCKER_3	Dockerfile définit un utilisateur non-root

Chaque check possède un identifiant unique, une description, un niveau de sévérité (LOW, MEDIUM, HIGH, CRITICAL) et un guide de remédiation.

Frameworks supportés

Checkov analyse de nombreux formats d’Infrastructure as Code :

Catégorie	Frameworks
Provisionnement cloud	Terraform, CloudFormation, Azure ARM, Bicep
Orchestration conteneurs	Kubernetes, Helm, Kustomize
Images conteneurs	Dockerfile, Docker Compose
Configuration	Ansible, Serverless Framework
Pipelines CI/CD	GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Argo
API	OpenAPI / Swagger

Fonctionnalités clés

Analyse contextuelle

Comprend les relations entre ressources grâce à une analyse en graphe

Détection de secrets

Identifie credentials, API keys et mots de passe dans le code

Politiques personnalisées

Créez vos propres règles en Python ou YAML

Exports multiples

JSON, SARIF, JUnit XML, CSV, CycloneDX (SBOM)

Checkov permet également de gérer les faux positifs via des suppressions inline ou CLI, et de créer des baselines pour ne signaler que les nouvelles violations (--create-baseline et --baseline).

Installation

L’installation de Checkov est simple et rapide. Il peut être installé directement depuis pip, le gestionnaire de paquets Python, avec la commande suivante :

pip install checkov
# ou avec pipx
pipx install checkov

Pour les utilisateurs de macOS, il est également possible de l’installer via Homebrew en utilisant la commande :

brew install checkov

Utilisation

L’utilisation de Checkov en ligne de commande est à la fois simple et flexible, permettant de vérifier rapidement vos fichiers d’Infrastructure as Code (IaC).

Analyses de base

Après l’installation, vous pouvez lancer des analyses sur différents types de fichiers et dossiers.

Pour analyser un répertoire Terraform :

checkov -d ./terraform/

Pour vérifier un fichier spécifique (Kubernetes, Dockerfile, etc.) :

checkov -f deployment.yaml

Pour scanner uniquement un framework spécifique :

# Uniquement les secrets
checkov -d . --framework secrets

# Uniquement Terraform
checkov -d . --framework terraform

Exclusion de fichiers et règles

Lors de l’utilisation en ligne de commande, vous pouvez exclure certains fichiers ou désactiver des politiques de sécurité spécifiques :

# Exclure un chemin
checkov -d ./projet --skip-path tests/

# Exclure une règle spécifique
checkov -d ./projet --skip-check CKV_AWS_20

# Exclure plusieurs règles
checkov -d ./projet --skip-check CKV_AWS_20,CKV_AWS_21

Comprendre les résultats : exemples par framework

Cette section présente des exemples concrets de scan avec Checkov. Pour chaque framework, nous analysons des fichiers contenant volontairement des failles de sécurité afin de comprendre comment Checkov les détecte et les signale.

Terraform (AWS, Azure, GCP)

Terraform est le framework IaC le plus courant. Checkov vérifie des centaines de règles spécifiques à chaque provider cloud (AWS, Azure, GCP, OCI).

Exemple de code vulnérable

Voici un extrait de code Terraform avec plusieurs problèmes de sécurité :

main.tf

# ❌ Bucket S3 avec accès public
resource "aws_s3_bucket" "bad_bucket" {
  bucket = "my-public-bucket"
  acl    = "public-read"  # Problème : bucket accessible publiquement
}

# ❌ Instance EC2 sans IMDSv2
resource "aws_instance" "bad_instance" {
  ami           = "ami-12345678"
  instance_type = "t3.micro"
  # Pas de metadata_options = IMDSv1 vulnérable aux attaques SSRF
}

# ❌ Security Group SSH ouvert au monde
resource "aws_security_group" "bad_sg" {
  name = "allow-all-ssh"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # Problème : SSH ouvert à Internet
  }
}

# ❌ RDS accessible publiquement avec mot de passe en clair
resource "aws_db_instance" "bad_rds" {
  identifier     = "mydb"
  engine         = "mysql"
  instance_class = "db.t3.micro"
  username       = "admin"
  password       = "SuperSecret123!"  # Problème : secret dans le code
  publicly_accessible = true           # Problème : BDD exposée à Internet
}

Résultat du scan

$ checkov -d terraform/ --compact

       _               _
   ___| |__   ___  ___| | _______   __
  / __| '_ \ / _ \/ __| |/ / _ \ \ / /
 | (__| | | |  __/ (__|   < (_) \ V /
  \___|_| |_|\___|\___|_|\_\___/ \_/

By Prisma Cloud | version: 3.2.495

terraform scan results:

Passed checks: 11, Failed checks: 37, Skipped checks: 0

Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
        FAILED for resource: aws_security_group.bad_sg
        File: /main.tf:35-59
        Guide: https://docs.prismacloud.io/en/.../networking-1-port-security

Check: CKV_AWS_17: "Ensure all data stored in RDS is not publicly accessible"
        FAILED for resource: aws_db_instance.bad_rds
        File: /main.tf:62-74
        Guide: https://docs.prismacloud.io/en/.../public-2

Check: CKV_AWS_79: "Ensure Instance Metadata Service Version 1 is not enabled"
        FAILED for resource: aws_instance.bad_instance
        File: /main.tf:14-32
        Guide: https://docs.prismacloud.io/en/.../bc-aws-general-31

Comprendre les résultats Terraform

Chaque ligne de résultat indique :

1. Check ID (ex: CKV_AWS_24) : identifiant unique de la règle
2. Description : ce que la règle vérifie en anglais
3. FAILED/PASSED : résultat du test
4. Resource : la ressource Terraform concernée (type.nom)
5. File : emplacement dans le code (fichier:lignes)
6. Guide : lien vers la documentation de remédiation

Checks AWS courants et leur signification :

Check	Description	Risque	Comment corriger
CKV_AWS_24	Security Group SSH ouvert (0.0.0.0/0)	Brute-force SSH, accès non autorisé	Restreindre aux IP connues
CKV_AWS_25	Security Group RDP ouvert (0.0.0.0/0)	Attaques RDP, ransomware	Utiliser un VPN ou bastion
CKV_AWS_17	RDS accessible publiquement	Exposition de la BDD	Mettre publicly_accessible = false
CKV_AWS_79	IMDSv1 activé sur EC2	Attaques SSRF (vol de credentials)	Forcer IMDSv2 dans metadata_options
CKV_AWS_8	Volume EBS non chiffré	Données lisibles si disque volé	Activer le chiffrement EBS
CKV_AWS_19	Bucket S3 non chiffré	Données non protégées au repos	Configurer SSE-S3 ou SSE-KMS

Kubernetes

Kubernetes présente des risques de sécurité spécifiques liés à l’isolation des conteneurs et à leurs privilèges. Checkov vérifie plus de 150 règles Kubernetes.

Exemple de Deployment vulnérable

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: insecure-app
  namespace: default  # ❌ Utiliser le namespace default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: insecure-app
  template:
    metadata:
      labels:
        app: insecure-app
    spec:
      hostNetwork: true    # ❌ Partage le réseau du host
      hostPID: true        # ❌ Voit les processus du host
      containers:
        - name: app
          image: nginx:latest  # ❌ Tag "latest" non reproductible
          securityContext:
            privileged: true   # ❌ Conteneur privilégié = root sur le host
          env:
            - name: DB_PASSWORD
              value: "secret123"  # ❌ Secret dans les variables d'env
          volumeMounts:
            - mountPath: /host
              name: host-volume
      volumes:
        - name: host-volume
          hostPath:
            path: /  # ❌ Monte la racine du host

Résultat du scan

$ checkov -f deployment.yaml --compact

kubernetes scan results:

Passed checks: 69, Failed checks: 21, Skipped checks: 0

Check: CKV_K8S_1: "Do not admit containers wishing to share the host process ID namespace"
        FAILED for resource: Deployment.default.insecure-app

Check: CKV_K8S_17: "Containers should not share the host network namespace"
        FAILED for resource: Deployment.default.insecure-app

Check: CKV_K8S_22: "Use read-only filesystem for containers where possible"
        FAILED for resource: Deployment.default.insecure-app

Check: CKV_K8S_28: "Minimize the admission of containers with the NET_RAW capability"
        FAILED for resource: Deployment.default.insecure-app

Comprendre les checks Kubernetes

Les checks Kubernetes suivent souvent les recommandations du CIS Kubernetes Benchmark et des Pod Security Standards (PSS).

Check	Description	Pourquoi c’est un problème	Correction
CKV_K8S_1	hostPID: true	Le conteneur voit tous les processus du nœud	Retirer hostPID
CKV_K8S_17	hostNetwork: true	Le conteneur partage l’IP du nœud	Retirer hostNetwork
CKV_K8S_22	Pas de readOnlyRootFilesystem	Un attaquant peut écrire des fichiers malveillants	Ajouter readOnlyRootFilesystem: true
CKV_K8S_28	Pas de drop: [NET_RAW]	Permet des attaques réseau (ARP spoofing)	Dropper la capability
CKV_K8S_14	Tag latest	Version non déterministe, difficile à auditer	Utiliser un tag versionné
CKV_K8S_35	Secret dans env.value	Secret visible dans les logs, describe, etc.	Utiliser un Secret Kubernetes

Dockerfile

Les Dockerfiles mal configurés peuvent créer des images vulnérables. Checkov vérifie les bonnes pratiques de sécurité pour la construction d’images.

Exemple de Dockerfile vulnérable

Dockerfile

# ❌ Tag "latest" : version non reproductible
FROM python:latest

# ❌ MAINTAINER déprécié (utiliser LABEL)
MAINTAINER dev@example.com

WORKDIR /app

# ❌ ADD peut extraire des archives et télécharger depuis Internet
# Préférer COPY pour les fichiers locaux
ADD https://example.com/config.tar.gz /app/
ADD . /app/

RUN pip install -r requirements.txt

# ❌ Expose le port SSH (risque d'accès distant non voulu)
EXPOSE 22 80

# ❌ Secret dans une variable d'environnement (visible dans l'image)
ENV API_KEY=sk-secret-12345

# ❌ Pas de USER : le conteneur s'exécute en root
# ❌ Pas de HEALTHCHECK : impossible de savoir si l'app fonctionne
CMD ["python", "app.py"]

Résultat du scan

$ checkov -f Dockerfile --compact

dockerfile scan results:

Passed checks: 47, Failed checks: 5, Skipped checks: 0

Check: CKV_DOCKER_7: "Ensure the base image uses a non latest version tag"
        FAILED for resource: Dockerfile.FROM
        File: /Dockerfile:4-4

Check: CKV_DOCKER_3: "Ensure that a user for the container has been created"
        FAILED for resource: Dockerfile.
        File: /Dockerfile:1-33

Check: CKV_DOCKER_2: "Ensure that HEALTHCHECK instructions have been added"
        FAILED for resource: Dockerfile.
        File: /Dockerfile:1-33

Check: CKV_DOCKER_1: "Ensure port 22 is not exposed"
        FAILED for resource: Dockerfile.EXPOSE
        File: /Dockerfile:29-29

Check: CKV_DOCKER_4: "Ensure that COPY is used instead of ADD"
        FAILED for resource: Dockerfile.ADD
        File: /Dockerfile:21-21

Comprendre les checks Dockerfile

Check	Description	Risque	Correction
CKV_DOCKER_7	Tag latest dans FROM	Image peut changer sans préavis	Utiliser un tag versionné (ex: python:3.11-slim)
CKV_DOCKER_3	Pas d’instruction USER	Conteneur s’exécute en root	Ajouter USER nonroot avant CMD
CKV_DOCKER_2	Pas de HEALTHCHECK	Kubernetes/Docker ne peut pas vérifier la santé	Ajouter HEALTHCHECK CMD curl -f http://localhost/
CKV_DOCKER_1	Port 22 exposé	SSH dans un conteneur = mauvaise pratique	Retirer l’exposition du port 22
CKV_DOCKER_4	ADD au lieu de COPY	ADD peut télécharger/extraire automatiquement	Utiliser COPY pour les fichiers locaux
CKV2_DOCKER_1	Utilisation de sudo	Indique un problème de gestion des privilèges	Configurer correctement USER

Ansible

Ansible présente des risques spécifiques liés à la gestion des secrets et aux modules qui peuvent désactiver la validation des certificats.

Exemple de playbook vulnérable

playbook.yml

---
- name: Configuration serveur web
  hosts: webservers
  become: true
  vars:
    # ❌ Mot de passe en clair dans le code
    db_password: "SuperSecret123!"
    api_key: "sk-1234567890abcdef"

  tasks:
    - name: Install packages with force
      ansible.builtin.apt:
        name: nginx
        state: present
        force: yes  # ❌ Force peut contourner des vérifications de sécurité

    - name: Download file
      ansible.builtin.get_url:
        url: https://example.com/config.tar.gz
        dest: /tmp/config.tar.gz
        validate_certs: no  # ❌ Désactive la validation TLS = vulnérable MITM

    - name: Set insecure permissions
      ansible.builtin.file:
        path: /etc/app/config
        mode: '0777'  # ❌ Permissions trop permissives

Résultat du scan

$ checkov -f playbook.yml --compact

ansible scan results:

Passed checks: 2, Failed checks: 2, Skipped checks: 0

Check: CKV_ANSIBLE_6: "Ensure that the force parameter is not used"
        FAILED for resource: tasks.ansible.builtin.apt.Install packages with force
        File: /playbook.yml:20-28

Check: CKV_ANSIBLE_2: "Ensure that certificate validation isn't disabled with get_url"
        FAILED for resource: tasks.ansible.builtin.get_url.Download file
        File: /playbook.yml:27-35

secrets scan results:

Passed checks: 0, Failed checks: 1, Skipped checks: 0

Check: CKV_SECRET_6: "Base64 High Entropy String"
        FAILED for resource: cbfdac6008f9cab4083784cbd1874f76618d2a97
        File: /playbook.yml:12-13

Comprendre les checks Ansible

Check	Description	Risque	Correction
CKV_ANSIBLE_2	validate_certs: no	Attaque Man-in-the-Middle possible	Garder la validation activée
CKV_ANSIBLE_6	force: yes dans apt	Peut installer des paquets corrompus	Retirer force: yes
CKV_SECRET_6	Secret détecté	Mot de passe/clé visible dans Git	Utiliser Ansible Vault

Détection de secrets

Checkov scanne automatiquement tous les fichiers pour détecter les secrets (credentials, API keys, tokens, mots de passe). Cette détection utilise des patterns d’entropie et des expressions régulières pour identifier les chaînes suspectes.

$ checkov -d . --framework secrets --compact

secrets scan results:

Passed checks: 0, Failed checks: 2, Skipped checks: 0

Check: CKV_SECRET_6: "Base64 High Entropy String"
        FAILED for resource: cbfdac6008f9cab4083784cbd1874f76618d2a97
        File: /ansible/playbook.yml:12-13

Check: CKV_SECRET_6: "Base64 High Entropy String"
        FAILED for resource: cbfdac6008f9cab4083784cbd1874f76618d2a97
        File: /terraform/main.tf:69-70

Types de secrets détectés

Checkov reconnaît automatiquement de nombreux types de secrets :

Check ID	Type de secret	Exemple de pattern
CKV_SECRET_2	AWS Access Key	AKIA...
CKV_SECRET_6	Chaîne haute entropie Base64	Mots de passe, tokens
CKV_SECRET_13	Clé privée	-----BEGIN RSA PRIVATE KEY-----
CKV_SECRET_14	Token Slack	xoxb-..., xoxp-...
CKV_SECRET_17	Clé Stripe	sk_live_..., rk_live_...
CKV_SECRET_19	Chaîne haute entropie Hex	Tokens hexadécimaux

Pour chaque mauvaise pratique détectée, Checkov indique comment la corriger et fournit un lien vers la documentation détaillée.

Génération de rapports

Une fois l’analyse effectuée avec Checkov, les résultats sont présentés sous forme de rapports détaillés. Ces rapports identifient les mauvaises configurations et les vulnérabilités dans votre code IaC. Par défaut, les résultats apparaissent dans la console avec une explication pour chaque règle violée, comprenant un identifiant de la règle, une description du problème et le fichier ou la ressource affectée.

Formats de sortie disponibles

Checkov supporte de nombreux formats d’export pour s’intégrer dans vos outils :

Format	Option	Usage principal
CLI (défaut)	-o cli	Affichage console lisible
JSON	-o json	Intégration avec d’autres outils
SARIF	-o sarif	GitHub Code Scanning, Azure DevOps
JUnit XML	-o junitxml	Jenkins, GitLab CI
CSV	-o csv	Excel, Google Sheets
CycloneDX	-o cyclonedx	SBOM
GitHub	-o github_failed_only	Annotations dans les PR

Exemples d’utilisation :

# Export JSON pour analyse
checkov -d ./projet -o json > rapport.json

# Plusieurs formats à la fois
checkov -d ./projet -o cli -o sarif --output-file-path console,results.sarif

# Format compact (sans afficher le code)
checkov -d ./projet --compact

# Afficher uniquement les échecs
checkov -d ./projet --quiet

Comprendre le résultat JSON

{
    "passed": 45,
    "failed": 12,
    "skipped": 3,
    "parsing_errors": 0,
    "resource_count": 60,
    "checkov_version": "3.2.495"
}

Le rapport distingue trois catégories :

• PASSED : Ressources conformes aux règles de sécurité
• FAILED : Problèmes de sécurité à corriger
• SKIPPED : Règles ignorées via commentaires ou CLI

Gestion des faux positifs et suppressions

Dans certains cas, Checkov identifie des problèmes qui ne sont pas pertinents pour votre contexte (faux positifs). Pour ces situations, plusieurs mécanismes existent.

Suppression en ligne de commande

Pour ignorer certaines règles lors de l’exécution :

# Ignorer une règle spécifique
checkov -d ./projet --skip-check CKV_AWS_20

# Ignorer plusieurs règles
checkov -d ./projet --skip-check CKV_AWS_20,CKV_AWS_21

# Ignorer une catégorie entière
checkov -d ./projet --skip-check LOW

Suppression inline par framework

Chaque framework utilise sa propre syntaxe de commentaire :

Terraform (HCL) :

resource "aws_s3_bucket" "example" {
  # checkov:skip=CKV_AWS_20: Bucket interne non exposé à Internet
  bucket = "mon-bucket-interne"
}

Kubernetes (YAML) :

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  annotations:
    checkov.io/skip1: "CKV_K8S_40=Pas de ressources pour cet environnement de test"
spec:
  containers:
    - name: app
      image: nginx:1.25

Dockerfile :

# checkov:skip=CKV_DOCKER_2: Image de base mise à jour via pipeline
FROM ubuntu:22.04

# checkov:skip=CKV_DOCKER_3: Utilisateur défini dans entrypoint
USER root

CloudFormation (YAML) :

Resources:
  MyBucket:
    # checkov:skip=CKV_AWS_18: Logs stockés dans un bucket dédié
    Type: AWS::S3::Bucket

Fichier de baseline

Pour les projets existants avec beaucoup de violations, créez une baseline :

# Créer la baseline
checkov -d ./projet --create-baseline

# Utiliser la baseline (ignore les violations connues)
checkov -d ./projet --baseline baseline.json

La baseline contient un hash des violations existantes. Seules les nouvelles violations seront signalées.

Configuration avec un fichier YAML

Pour des projets récurrents, un fichier de configuration évite de répéter les options en ligne de commande. Checkov recherche automatiquement .checkov.yaml ou .checkov.yml dans le répertoire courant.

Exemple de configuration complète

.checkov.yaml

# Répertoire à analyser
directory:
  - ./infrastructure
  - ./kubernetes

# Frameworks à analyser
framework:
  - terraform
  - kubernetes
  - dockerfile

# Règles à ignorer globalement
skip-check:
  - CKV_AWS_20  # Bucket public (géré autrement)
  - CKV_K8S_40  # Ressources (environnement de dev)

# Règles à exécuter (si défini, seules celles-ci sont lancées)
# check:
#   - CKV_AWS_18
#   - CKV_AWS_21

# Télécharger les modules Terraform externes
download-external-modules: true
external-modules-download-path: .external_modules

# Format de sortie
output:
  - cli
  - json

# Fichier de sortie pour JSON/SARIF
output-file-path: reports/checkov-report

# Options diverses
compact: true
soft-fail: false  # true = ne pas échouer le pipeline

Générer une configuration

Pour générer un fichier de configuration à partir de vos options actuelles :

checkov -d ./projet --skip-check CKV_AWS_20 --create-config .checkov.yaml

Pour visualiser la configuration active (ligne de commande + fichier + env) :

checkov --show-config

Création de politiques personnalisées

Les +800 règles intégrées ne couvrent pas tous les cas. Checkov permet de créer des politiques adaptées à vos normes internes.

Politique en Python

Voici une règle qui vérifie que les instances EC2 utilisent un type autorisé :

checks/ec2_instance_type.py

from checkov.common.models.enums import CheckResult, CheckCategories
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

class EC2InstanceTypeCheck(BaseResourceCheck):
    def __init__(self):
        name = "Ensure EC2 instances use approved instance types"
        id = "CKV_CUSTOM_01"
        supported_resources = ["aws_instance"]
        categories = [CheckCategories.GENERAL_SECURITY]
        super().__init__(
            name=name,
            id=id,
            categories=categories,
            supported_resources=supported_resources
        )

    def scan_resource_conf(self, conf):
        # Types autorisés dans votre organisation
        allowed_types = ["t3.micro", "t3.small", "t3.medium"]

        instance_type = conf.get("instance_type", [None])[0]
        if instance_type in allowed_types:
            return CheckResult.PASSED
        return CheckResult.FAILED

# Instancier pour enregistrer la règle
check = EC2InstanceTypeCheck()

Exécution avec les règles personnalisées :

checkov -d ./projet --external-checks-dir ./checks

Politique en YAML (plus simple)

Pour des vérifications simples, le format YAML suffit :

policies/s3_encryption.yaml

metadata:
  id: "CKV_CUSTOM_02"
  name: "Ensure S3 buckets have encryption enabled"
  category: "ENCRYPTION"

definition:
  cond_type: "attribute"
  resource_types:
    - "aws_s3_bucket"
  attribute: "server_side_encryption_configuration"
  operator: "exists"

checkov -d ./projet --external-checks-dir ./policies

Bonnes pratiques

• Préfixez vos IDs avec CKV_CUSTOM_ ou CKV_<ENTREPRISE>_
• Documentez chaque règle avec un name explicite
• Versionnez vos règles personnalisées dans un repo dédié
• Testez les règles sur des exemples avant déploiement

À retenir

• Shift-left security : Checkov détecte les problèmes dans votre IDE ou CI, pas en production
• +800 règles prêtes à l’emploi : AWS, Azure, GCP, Kubernetes, Docker… couverture immédiate sans configuration
• Zéro excuse pour les secrets : la détection automatique évite les fuites de credentials dans Git
• Faux positifs gérables : suppressions inline, baselines et fichier de config pour adapter à votre contexte
• Extensible : créez vos propres règles en Python ou YAML pour vos normes internes

Checkov s’intègre en quelques minutes dans n’importe quel pipeline CI/CD. Le retour sur investissement est immédiat : chaque mauvaiseconfiguration détectée avant le déploiement évite une potentielle brèche de sécurité.

Plus d’infos

• Site officiel Checkov ↗ — Documentation complète
• Quick Start ↗ — Démarrage rapide
• CLI Reference ↗ — Options en ligne de commande
• Policy Index ↗ — Liste des +800 règles
• Custom Policies ↗ — Politiques personnalisées
• GitHub Checkov ↗ — Code source
• Slack Community ↗ — Communauté d’entraide