checkov v3.3.12

Checkov est un outil d'analyse statique de code pour l'infrastructure en tant que code (IaC) et également un outil d'analyse de composition logicielle (SCA) pour les images et les packages open source.

Il scanne l'infrastructure cloud provisionnée avec Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates, ou OpenTofu et détecte les mauvaises configurations de sécurité et de conformité en utilisant un scan basé sur des graphes.

Il effectue une analyse de composition logicielle (SCA) qui est un scan des packages open source et des images pour les vulnérabilités et expositions communes (CVE).

Checkov alimente également Prisma Cloud Application Security, la plateforme orientée développeur qui codifie et rationalise la sécurité cloud tout au long du cycle de développement. Prisma Cloud identifie, corrige et prévient les mauvaises configurations dans les ressources cloud et les fichiers d'infrastructure en tant que code.

Table des matières

• Fonctionnalités
• Captures d'écran
• Pour commencer
• Avertissement
• Support
• Migration - de v2 à v3

Fonctionnalités

• Plus de 1000 politiques intégrées couvrant les bonnes pratiques de sécurité et de conformité pour AWS, Azure et Google Cloud.
• Scanne les fichiers de modèles Terraform, Terraform Plan, Terraform JSON, CloudFormation, AWS SAM, Kubernetes, Helm, Kustomize, Dockerfile, Serverless framework, Ansible, Bicep, ARM et OpenTofu.
• Scanne les fichiers de workflows Argo Workflows, Azure Pipelines, BitBucket Pipelines, Circle CI Pipelines, GitHub Actions et GitLab CI.
• Prend en charge les politiques contextuelles basées sur un scan en mémoire par graphes.
• Prend en charge le format Python pour les politiques d'attributs et le format YAML pour les politiques d'attributs et composites.
• Détecte les identifiants AWS dans les Userdata EC2, les variables d'environnement Lambda et les fournisseurs Terraform.
• Identifie les secrets à l'aide d'expressions régulières, de mots-clés et d'une détection basée sur l'entropie.
• Évalue les paramètres du fournisseur Terraform pour réguler la création, la gestion et les mises à jour des IaaS, PaaS ou SaaS gérés via Terraform.
• Les politiques prennent en charge l'évaluation des variables jusqu'à leur valeur par défaut optionnelle.
• Prend en charge la suppression en ligne des risques acceptés ou des faux positifs pour réduire les échecs de scan récurrents. Prend également en charge le saut global via l'utilisation de la CLI.
• Sortie actuellement disponible en CLI, CycloneDX, JSON, JUnit XML, CSV, SARIF et markdown GitHub, avec un lien vers les guides de correction.

Captures d'écran

Résultats de scan en CLI

Résultat de scan planifié dans Jenkins

Pour commencer

Prérequis

• Python >= 3.9, <=3.12
• Terraform >= 0.12

Installation

Pour installer pip, suivez la documentation officielle```sh pip3 install checkov

Certains environnements (par exemple, Debian 12) peuvent nécessiter d'installer Checkov dans un environnement virtuel.```sh
# Create and activate a virtual environment
python3 -m venv /path/to/venv/checkov
cd /path/to/venv/checkov
source ./bin/activate

# Install Checkov with pip
pip install checkov

# Optional: Create a symlink for easy access
sudo ln -s /path/to/venv/checkov/bin/checkov /usr/local/bin/checkov

ou avec Homebrew (macOS ou Linux)```sh brew install checkov

### Activer l'autocomplétion bash```sh
source <(register-python-argcomplete checkov)

Mise à niveau

si vous avez installé checkov avec pip3```sh pip3 install -U checkov

ou avec Homebrew```sh
brew upgrade checkov

Configurer un dossier ou fichier d'entrée```sh

checkov --directory /user/path/to/iac/code

Ou un fichier spécifique ou plusieurs fichiers```sh
checkov --file /user/tf/example.tf

Ou```sh checkov -f /user/cloudformation/example1.yml -f /user/cloudformation/example2.yml

Ou un fichier terraform plan au format JSON```sh
terraform init
terraform plan -out tf.plan
terraform show -json tf.plan  > tf.json
checkov -f tf.json

Note: terraform show le fichier de sortie tf.json sera une seule ligne. Pour cette raison, tous les résultats seront rapportés à la ligne 0 par Checkov```sh check: CKV_AWS_21: "Ensure all data stored in the S3 bucket have versioning enabled" FAILED for resource: aws_s3_bucket.customer File: /tf/tf.json:0-0 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3-16-enable-versioning

Si vous avez installé `jq`, vous pouvez convertir un fichier json en plusieurs lignes avec la commande suivante :```sh
terraform show -json tf.plan | jq '.' > tf.json

Le résultat du scan serait beaucoup plus convivial.```sh checkov -f tf.json Check: CKV_AWS_21: "Ensure all data stored in the S3 bucket have versioning enabled" FAILED for resource: aws_s3_bucket.customer File: /tf/tf1.json:224-268 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/s3-16-enable-versioning

	225 |               "values": {
	226 |                 "acceleration_status": "",
	227 |                 "acl": "private",
	228 |                 "arn": "arn:aws:s3:::mybucket",

Vous pouvez également spécifier la racine du dépôt des fichiers HCL utilisés pour générer le fichier plan, à l'aide du drapeau `--repo-root-for-plan-enrichment`, afin d'enrichir la sortie avec le chemin de fichier approprié, les numéros de ligne et le bloc de code de la ressource. Un avantage supplémentaire est que les suppressions de vérifications seront traitées en conséquence.```sh
checkov -f tf.json --repo-root-for-plan-enrichment /user/path/to/iac/code

Exemple de résultat de scan (CLI)```sh

Passed Checks: 1, Failed Checks: 1, Suppressed Checks: 0 Check: "Ensure all data stored in the S3 bucket is securely encrypted at rest" /main.tf: Passed for resource: aws_s3_bucket.template_bucket Check: "Ensure all data stored in the S3 bucket is securely encrypted at rest" /../regionStack/main.tf: Failed for resource: aws_s3_bucket.sls_deployment_bucket_name

Commencez à utiliser Checkov en lisant la page [Prise en main](https://github.com/bridgecrewio/checkov/blob/main/docs/1.Welcome/Quick%20Start.md).

### Utilisation de Docker```sh
docker pull bridgecrew/checkov
docker run --tty --rm --volume /user/tf:/tf --workdir /tf bridgecrew/checkov --directory /tf

Note: if you are using Python 3.6(Default version in Ubuntu 18.04) checkov will not work, and it will fail with ModuleNotFoundError: No module named 'dataclasses' error message. In this case, you can use the docker version instead.

Note that there are certain cases where redirecting docker run --tty output to a file - for example, if you want to save the Checkov JUnit output to a file - will cause extra control characters to be printed. This can break file parsing. If you encounter this, remove the --tty flag.

The --workdir /tf flag is optional to change the working directory to the mounted volume. If you are using the SARIF output -o sarif this will output the results.sarif file to the mounted volume (/user/tf in the example above). If you do not include that flag, the working directory will be "/".

Exécution ou saut des vérifications

By using command line flags, you can specify to run only named checks (allow list) or run all checks except those listed (deny list). If you are using the platform integration via API key, you can also specify a severity threshold to skip and / or include. Moreover, as json files can't contain comments, one can pass regex pattern to skip json file secret scan.

See the docs for more detailed information about how these flags work together.

Exemples

Allow only the two specified checks to run:```sh checkov --directory . --check CKV_AWS_20,CKV_AWS_57

Exécutez toutes les vérifications sauf celle spécifiée :```sh
checkov -d . --skip-check CKV_AWS_20

Exécuter toutes les vérifications sauf celles avec des motifs spécifiés :```sh checkov -d . --skip-check CKV_AWS*

Exécuter toutes les vérifications qui sont de sévérité MEDIUM ou supérieure (nécessite une clé API) :```sh
checkov -d . --check MEDIUM --bc-api-key ...

Exécutez toutes les vérifications de sévérité MEDIUM ou supérieure, ainsi que la vérification CKV_123 (en supposant qu'il s'agit d'une vérification de sévérité LOW) :```sh checkov -d . --check MEDIUM,CKV_123 --bc-api-key ...

Ignorez toutes les vérifications qui sont de sévérité MEDIUM ou inférieure :```sh
checkov -d . --skip-check MEDIUM --bc-api-key ...

Ignorer toutes les vérifications de sévérité MEDIUM ou inférieure, ainsi que la vérification CKV_789 (supposée être une vérification de haute sévérité) :```sh checkov -d . --skip-check MEDIUM,CKV_789 --bc-api-key ...

Exécutez toutes les vérifications de sévérité MEDIUM ou plus élevée, mais ignorez la vérification CKV_123 (en supposant qu'il s'agit d'une vérification de sévérité medium ou plus élevée) :```sh
checkov -d . --check MEDIUM --skip-check CKV_123 --bc-api-key ...

Exécutez la vérification CKV_789, mais ignorez-la si elle est de gravité moyenne (la logique --check est toujours appliquée avant --skip-check)```sh checkov -d . --skip-check MEDIUM --check CKV_789 --bc-api-key ...

Pour les charges de travail Kubernetes, vous pouvez également utiliser les espaces de noms d'autorisation/refus.  Par exemple, ne signalez aucun résultat pour l'espace de noms
kube-system :```sh
checkov -d . --skip-check kube-system

Lancez une analyse d'une image de conteneur. Tirez d'abord l'image ou construisez-la, puis référez-vous-y par le hachage, l'ID ou le nom:tag :```sh checkov --framework sca_image --docker-image sha256:1234example --dockerfile-path /Users/path/to/Dockerfile --repo-id ... --bc-api-key ...

checkov --docker-image :tag --dockerfile-path /User/path/to/Dockerfile --repo-id ... --bc-api-key ...

Vous pouvez également utiliser l'indicateur --image pour scanner l'image du conteneur au lieu de --docker-image comme raccourci :```sh
checkov --image <image-name>:tag --dockerfile-path /User/path/to/Dockerfile --repo-id ... --bc-api-key ...

Exécutez une analyse SCA des paquets dans un dépôt :```sh checkov -d . --framework sca_package --bc-api-key ... --repo-id <repo_id(arbitrary)>

Exécutez une analyse d'un répertoire avec des variables d'environnement supprimant la mise en mémoire tampon, ajoutant des logs de niveau débogage :```sh
PYTHONUNBUFFERED=1 LOG_LEVEL=DEBUG checkov -d .

OU activez les variables d'environnement pour plusieurs exécutions```sh export PYTHONUNBUFFERED=1 LOG_LEVEL=DEBUG checkov -d .

Exécutez l'analyse des secrets sur tous les fichiers dans MyDirectory. Ignorez la vérification CKV_SECRET_6 sur les fichiers json dont le suffixe est DontScan```sh
checkov -d /MyDirectory --framework secrets --repo-id ... --bc-api-key ... --skip-check CKV_SECRET_6:.*DontScan.json$

Exécutez l'analyse des secrets sur tous les fichiers dans MyDirectory. Ignorez la vérification CKV_SECRET_6 sur les fichiers json qui contiennent "skip_test" dans le chemin.```sh checkov -d /MyDirectory --framework secrets --repo-id ... --bc-api-key ... --skip-check CKV_SECRET_6:.*skip_test.*json$

On peut masquer les valeurs des résultats de scan en fournissant un fichier de configuration (en utilisant l'option --config-file) avec une entrée mask. Le masquage peut s'appliquer sur la ressource & valeur (ou plusieurs valeurs, séparées par une virgule).
Exemples :```sh
mask:
- aws_instance:user_data
- azurerm_key_vault_secret:admin_password,user_passwords

Dans l'exemple ci-dessus, les valeurs suivantes seront masquées :

• user_data pour la ressource aws_instance
• à la fois admin_password et user_passwords pour azurerm_key_vault_secret

Supprimer/Ignorer une vérification

Comme tout outil d'analyse statique, il est limité par sa portée d'analyse. Par exemple, si une ressource est gérée manuellement, ou à l'aide d'un outil de gestion de configuration ultérieur, la suppression peut être insérée comme une simple annotation de code.

Format du commentaire de suppression

Pour ignorer une vérification sur un bloc de définition Terraform ou une ressource CloudFormation donné, appliquez le modèle de commentaire suivant dans sa portée :

checkov:skip=<check_id>:<suppression_comment>

• <check_id> est l'un des [scanners de vérification disponibles](docs/5.Policy Index/all.md)
• <suppression_comment> est une raison de suppression facultative à inclure dans la sortie

Exemple

Le commentaire suivant ignore la vérification CKV_AWS_20 sur la ressource identifiée par foo-bucket, où le scan vérifie si un bucket S3 AWS est privé. Dans l'exemple, le bucket est configuré avec un accès en lecture publique ; l'ajout du commentaire de suppression ignorerait la vérification appropriée au lieu que la vérification échoue.```hcl-terraform resource "aws_s3_bucket" "foo-bucket" { region = var.region #checkov:skip=CKV_AWS_20:The bucket is a public static content host bucket = local.bucket_name force_destroy = true acl = "public-read" }

La sortie contiendrait maintenant une entrée de résultat de vérification ``SKIPPED`` :```bash
...
...
Check: "S3 Bucket has an ACL defined which allows public access."
	SKIPPED for resource: aws_s3_bucket.foo-bucket
	Suppress comment: The bucket is a public static content host
	File: /example_skip_acl.tf:1-25

...

Pour ignorer plusieurs vérifications, ajoutez chacune sur une nouvelle ligne.``` #checkov:skip=CKV2_AWS_6 #checkov:skip=CKV_AWS_20:The bucket is a public static content host

Pour supprimer les vérifications dans les manifests Kubernetes, on utilise des annotations avec le format suivant :
`checkov.io/skip#: <check_id>=<suppression_comment>`

Par exemple :```bash
apiVersion: v1
kind: Pod
metadata:
  name: mypod
  annotations:
    checkov.io/skip1: CKV_K8S_20=I don't care about Privilege Escalation :-O
    checkov.io/skip2: CKV_K8S_14
    checkov.io/skip3: CKV_K8S_11=I have not set CPU limits as I want BestEffort QoS
spec:
  containers:
...

Journalisation

Pour une journalisation détaillée vers stdout, définissez la variable d'environnement LOG_LEVEL sur DEBUG.

Par défaut, LOG_LEVEL=WARNING.

Ignorer des répertoires

Pour ignorer des fichiers ou répertoires, utilisez l'argument --skip-path, qui peut être spécifié plusieurs fois. Cet argument accepte des expressions régulières pour les chemins relatifs au répertoire de travail courant. Vous pouvez l'utiliser pour ignorer des répertoires entiers et/ou des fichiers spécifiques.

Par défaut, tous les répertoires nommés node_modules, .terraform et .serverless seront ignorés, ainsi que tous les fichiers ou répertoires commençant par .. Pour annuler l'ignorance des répertoires commençant par ., remplacez la variable d'environnement CKV_IGNORE_HIDDEN_DIRECTORIES par export CKV_IGNORE_HIDDEN_DIRECTORIES=false

Vous pouvez remplacer l'ensemble par défaut des répertoires à ignorer en définissant la variable d'environnement CKV_IGNORED_DIRECTORIES. Notez que si vous souhaitez conserver cette liste et y ajouter des éléments, vous devez inclure ces valeurs. Par exemple, CKV_IGNORED_DIRECTORIES=mynewdir ignorera uniquement ce répertoire, mais pas les autres mentionnés ci-dessus. Cette variable est une fonctionnalité héritée ; nous recommandons d'utiliser le drapeau --skip-file.

Sortie console

La sortie console est en couleurs par défaut. Pour passer à une sortie monochrome, définissez la variable d'environnement : ANSI_COLORS_DISABLED

Extension VS Code

Si vous souhaitez utiliser Checkov dans VS Code, essayez l'extension Prisma Cloud.

Configuration à l'aide d'un fichier de configuration

Checkov peut être configuré à l'aide d'un fichier de configuration YAML. Par défaut, checkov recherche un fichier .checkov.yaml ou .checkov.yml dans les emplacements suivants, par ordre de priorité :

• Répertoire dans lequel checkov est exécuté. (--directory)
• Répertoire de travail courant où checkov est appelé.
• Répertoire personnel de l'utilisateur.

Attention : il est recommandé que le fichier de configuration de checkov soit chargé à partir d'une source fiable composée d'une identité vérifiée, afin que les fichiers scannés, les identifiants de vérification et les vérifications personnalisées chargées soient conformes aux attentes.

Les utilisateurs peuvent également passer le chemin d'un fichier de configuration via la ligne de commande. Dans ce cas, les autres fichiers de configuration seront ignorés. Par exemple :```sh checkov --config-file path/to/config.yaml

Les utilisateurs peuvent également créer un fichier de configuration en utilisant la commande `--create-config`, qui prend les arguments actuels de la ligne de commande et les écrit dans un chemin donné. Par exemple :```sh
checkov --compact --directory test-dir --docker-image sample-image --dockerfile-path Dockerfile --download-external-modules True --external-checks-dir sample-dir --quiet --repo-id prisma-cloud/sample-repo --skip-check CKV_DOCKER_3,CKV_DOCKER_2 --skip-framework dockerfile secrets --soft-fail --branch develop --check CKV_DOCKER_1 --create-config /Users/sample/config.yml

Créera un fichier config.yaml qui ressemble à ceci :```yaml branch: develop check:

• CKV_DOCKER_1 compact: true directory:
• test-dir docker-image: sample-image dockerfile-path: Dockerfile download-external-modules: true evaluate-variables: true external-checks-dir:
• sample-dir external-modules-download-path: .external_modules framework:
• all output: cli quiet: true repo-id: prisma-cloud/sample-repo skip-check:
• CKV_DOCKER_3
• CKV_DOCKER_2 skip-framework:
• dockerfile
• secrets soft-fail: true

Les utilisateurs peuvent également utiliser le flag `--show-config` pour voir tous les arguments et paramètres ainsi que leur provenance, c'est-à-dire la ligne de commande, le fichier de configuration, la variable d'environnement ou la valeur par défaut. Par exemple :```sh
checkov --show-config

S'affichera :```sh Command Line Args: --show-config Environment Variables: BC_API_KEY: your-api-key Config File (/Users/sample/.checkov.yml): soft-fail: False branch: master skip-check: ['CKV_DOCKER_3', 'CKV_DOCKER_2'] Defaults: --output: cli --framework: ['all'] --download-external-modules:False --external-modules-download-path:.external_modules --evaluate-variables:True

## Contribuer

Les contributions sont les bienvenues !

Commencez par consulter les [directives de contribution](https://github.com/bridgecrewio/checkov/blob/main/CONTRIBUTING.md). Ensuite, jetez un œil à une [bonne première issue](https://github.com/bridgecrewio/checkov/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).

Vous pouvez même commencer avec un développement en un clic dans votre navigateur via Gitpod au lien suivant :

[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/bridgecrewio/checkov)

Vous souhaitez contribuer de nouvelles vérifications ? Apprenez à écrire une nouvelle vérification (aussi appelée politique) [ici](https://github.com/bridgecrewio/checkov/blob/main/docs/6.Contribution/Contribution%20Overview.md).

## Avertissement
`checkov` ne sauvegarde, ne publie ni ne partage avec quiconque aucune information identifiable sur les clients.  
Aucune information identifiable sur les clients n'est utilisée pour interroger les guides accessibles au public de Prisma Cloud.
`checkov` utilise l'API de Prisma Cloud pour enrichir les résultats avec des liens vers des guides de correction.
Pour ignorer cet appel API, utilisez le drapeau `--skip-download`.

## Assistance

[Prisma Cloud](https://www.prismacloud.io/?utm_source=github&utm_medium=organic_oss&utm_campaign=checkov) crée et maintient Checkov pour rendre la politique en tant que code simple et accessible.

Commencez par notre [Documentation](https://www.checkov.io/1.Welcome/Quick%20Start.html) pour des tutoriels et exemples rapides.

## Prise en charge des versions Python
Nous suivons le cycle de support officiel de Python et nous utilisons des tests automatisés pour les versions supportées de Python.
Cela signifie que nous supportons actuellement Python 3.9 à 3.13 inclus.
Notez que Python 3.8 a atteint sa fin de vie en octobre 2024 et que Python 3.9 atteindra sa fin de vie en octobre 2025.
Si vous rencontrez des problèmes avec une version de Python non en fin de vie, veuillez ouvrir une issue.