Checkov est un outil d'analyse de code statique pour l'infrastructure en tant que code (IaC) ainsi qu'un outil d'analyse de composition logicielle (SCA) pour les images et les packages open source.
Il analyse l'infrastructure cloud fournie à l'aide de Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates ou OpenTofu et détecte les erreurs de configuration en matière de sécurité et de conformité à l'aide d'une analyse basée sur des graphiques.
Il effectue une analyse de composition logicielle (SCA), qui est une analyse de packages et d'images open source pour détecter les vulnérabilités et expositions courantes (CVE).
Checkov alimente également Prisma Cloud Application Security , la plateforme réservée aux développeurs qui codifie et rationalise la sécurité du cloud tout au long du cycle de vie du développement. Prisma Cloud identifie, corrige et évite les erreurs de configuration dans les ressources cloud et les fichiers d'infrastructure en tant que code.
Résultats de l'analyse dans CLI
Résultat de l'analyse planifiée dans Jenkins
Pour installer pip, suivez la documentation officielle
pip3 install checkov
ou avec Homebrew (macOS ou Linux)
brew install checkov
source <( register-python-argcomplete checkov )
si vous avez installé checkov avec pip3
pip3 install -U checkov
ou avec Homebrew
brew upgrade checkov
checkov --directory /user/path/to/iac/code
Ou un ou plusieurs fichiers spécifiques
checkov --file /user/tf/example.tf
Ou
checkov -f /user/cloudformation/example1.yml -f /user/cloudformation/example2.yml
Ou un fichier plan Terraform au format json
terraform init
terraform plan -out tf.plan
terraform show -json tf.plan > tf.json
checkov -f tf.json
Remarque : le fichier de sortie terraform show
tf.json
sera une seule ligne. Pour cette raison, tous les résultats seront rapportés sur la ligne numéro 0 par Checkov.
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 le fichier json en plusieurs lignes avec la commande suivante :
terraform show -json tf.plan | jq ' . ' > tf.json
Le résultat de l’analyse serait très convivial.
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 référentiel des fichiers hcl utilisés pour générer le fichier plan, à l'aide de l'indicateur --repo-root-for-plan-enrichment
, pour enrichir la sortie avec le chemin de fichier, les numéros de ligne et le bloc de code appropriés de la ressource. (s). Un avantage supplémentaire est que les suppressions de chèques seront traitées en conséquence.
checkov -f tf.json --repo-root-for-plan-enrichment /user/path/to/iac/code
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 Mise en route.
docker pull bridgecrew/checkov
docker run --tty --rm --volume /user/tf:/tf --workdir /tf bridgecrew/checkov --directory /tf
Remarque : si vous utilisez Python 3.6 (version par défaut dans Ubuntu 18.04), checkov ne fonctionnera pas et échouera avec le message d'erreur ModuleNotFoundError: No module named 'dataclasses'
. Dans ce cas, vous pouvez utiliser la version Docker à la place.
Notez qu'il existe certains cas où la redirection de la sortie docker run --tty
vers un fichier - par exemple, si vous souhaitez enregistrer la sortie Checkov JUnit dans un fichier - entraînera l'impression de caractères de contrôle supplémentaires. Cela peut interrompre l'analyse des fichiers. Si vous rencontrez ce problème, supprimez l'indicateur --tty
.
L'indicateur --workdir /tf
est facultatif pour remplacer le répertoire de travail par le volume monté. Si vous utilisez la sortie SARIF -o sarif
cela affichera le fichier results.sarif sur le volume monté ( /user/tf
dans l'exemple ci-dessus). Si vous n'incluez pas cet indicateur, le répertoire de travail sera "/".
En utilisant des indicateurs de ligne de commande, vous pouvez spécifier d'exécuter uniquement les vérifications nommées (liste autorisée) ou d'exécuter toutes les vérifications à l'exception de celles répertoriées (liste de refus). Si vous utilisez l'intégration de la plateforme via une clé API, vous pouvez également spécifier un seuil de gravité à ignorer et/ou à inclure. De plus, comme les fichiers json ne peuvent pas contenir de commentaires, on peut transmettre un modèle d'expression régulière pour ignorer l'analyse secrète du fichier json.
Consultez la documentation pour des informations plus détaillées sur la manière dont ces indicateurs fonctionnent ensemble.
Autoriser uniquement l'exécution des deux vérifications spécifiées :
checkov --directory . --check CKV_AWS_20,CKV_AWS_57
Exécutez toutes les vérifications sauf celle spécifiée :
checkov -d . --skip-check CKV_AWS_20
Exécutez toutes les vérifications, à l'exception des vérifications avec des modèles spécifiés :
checkov -d . --skip-check CKV_AWS *
Exécutez toutes les vérifications de gravité MOYENNE ou supérieure (nécessite une clé API) :
checkov -d . --check MEDIUM --bc-api-key ...
Exécutez toutes les vérifications de gravité MOYENNE ou supérieure, ainsi que la vérification CKV_123 (en supposant qu'il s'agit d'une vérification de gravité FAIBLE) :
checkov -d . --check MEDIUM,CKV_123 --bc-api-key ...
Ignorez toutes les vérifications de gravité MOYENNE ou inférieure :
checkov -d . --skip-check MEDIUM --bc-api-key ...
Ignorez toutes les vérifications de gravité MOYENNE ou inférieure, ainsi que la vérification CKV_789 (en supposant qu'il s'agit d'une vérification de gravité élevée) :
checkov -d . --skip-check MEDIUM,CKV_789 --bc-api-key ...
Exécutez toutes les vérifications de gravité MOYENNE ou supérieure, mais ignorez la vérification CKV_123 (en supposant qu'il s'agit d'une vérification de gravité moyenne ou supérieure) :
checkov -d . --check MEDIUM --skip-check CKV_123 --bc-api-key ...
Exécutez la vérification CKV_789, mais ignorez-la s'il s'agit d'une gravité moyenne (la logique --check est toujours appliquée avant --skip-check)
checkov -d . --skip-check MEDIUM --check CKV_789 --bc-api-key ...
Pour les charges de travail Kubernetes, vous pouvez également utiliser des espaces de noms autoriser/refuser. Par exemple, ne signalez aucun résultat pour l'espace de noms kube-system :
checkov -d . --skip-check kube-system
Exécutez une analyse d’une image de conteneur. Extrayez ou créez d’abord l’image, puis faites-y référence par le hachage, l’ID ou le nom : balise :
checkov --framework sca_image --docker-image sha256:1234example --dockerfile-path /Users/path/to/Dockerfile --repo-id ... --bc-api-key ...
checkov --docker-image < image-name > :tag --dockerfile-path /User/path/to/Dockerfile --repo-id ... --bc-api-key ...
Vous pouvez également utiliser l'indicateur --image pour analyser l'image du conteneur au lieu de --docker-image pour le raccourcir :
checkov --image < image-name > :tag --dockerfile-path /User/path/to/Dockerfile --repo-id ... --bc-api-key ...
Exécutez une analyse SCA des packages dans un dépôt :
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 en supprimant la mise en mémoire tampon et en ajoutant des journaux de niveau de débogage :
PYTHONUNBUFFERED=1 LOG_LEVEL=DEBUG checkov -d .
OU activez les variables d'environnement pour plusieurs exécutions
export PYTHONUNBUFFERED=1 LOG_LEVEL=DEBUG
checkov -d .
Exécutez l'analyse des secrets sur tous les fichiers de MyDirectory. Ignorer CKV_SECRET_6 et vérifier sur les fichiers json que leur suffixe est DontScan
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 de MyDirectory. Ignorer la vérification CKV_SECRET_6 sur les fichiers json qui contiennent "skip_test" dans le chemin
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 l'analyse en fournissant un fichier de configuration (en utilisant l'indicateur --config-file) avec l'entrée de masque. Le masquage peut s'appliquer sur la ressource et la valeur (ou sur plusieurs valeurs, séparées par une virgule). Exemples :
mask:
- aws_instance:user_data
- azurerm_key_vault_secret:admin_password,user_passwords
Dans l'exemple ci-dessus, les valeurs suivantes seront masquées :
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’outils de gestion de configuration ultérieurs, la suppression peut être insérée sous la forme d’une simple annotation de code.
Pour ignorer une vérification sur un bloc de définition Terraform ou une ressource CloudFormation donnée, 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 chèques disponibles](docs/5.Policy Index/all.md)<suppression_comment>
est un motif de suppression facultatif à inclure dans la sortie Le commentaire suivant ignore la vérification CKV_AWS_20
sur la ressource identifiée par foo-bucket
, où l'analyse vérifie si un compartiment AWS S3 est privé. Dans l'exemple, le compartiment est configuré avec un accès public en lecture ; L'ajout du commentaire de suppression ignorerait la vérification appropriée au lieu de l'échec de la vérification.
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 désormais une entrée de résultat de vérification SKIPPED
:
...
...
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-les sous forme de 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 manifestes Kubernetes, les annotations sont utilisées au format suivant : checkov.io/skip#: <check_id>=<suppression_comment>
Par exemple:
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:
...
Pour une journalisation détaillée sur stdout, configurez la variable d'environnement LOG_LEVEL
sur DEBUG
.
La valeur par défaut est LOG_LEVEL=WARNING
.
Pour ignorer des fichiers ou des répertoires, utilisez l'argument --skip-path
, qui peut être spécifié plusieurs fois. Cet argument accepte les expressions régulières pour les chemins relatifs au répertoire de travail actuel. 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, en plus de tous les fichiers ou répertoires commençant par .
. Pour annuler le saut des répertoires commençant par .
remplacer l'exportation de la variable d'environnement CKV_IGNORE_HIDDEN_DIRECTORIES
export CKV_IGNORE_HIDDEN_DIRECTORIES=false
Vous pouvez remplacer l'ensemble de répertoires par défaut à 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 vous recommandons d'utiliser l'indicateur --skip-file
.
La sortie de la console est en couleur par défaut, pour passer à une sortie monochrome, définissez la variable d'environnement : ANSI_COLORS_DISABLED
Si vous souhaitez utiliser Checkov dans VS Code, essayez l'extension Prisma Cloud.
Checkov peut être configuré à l'aide d'un fichier de configuration YAML. Par défaut, checkov recherche un fichier .checkov.yaml
ou .checkov.yml
aux endroits suivants par ordre de priorité :
--directory
)Attention : il est recommandé que le fichier de configuration checkov soit chargé à partir d'une source fiable composée d'une identité vérifiée, afin que les fichiers analysés, les identifiants de contrôle et les contrôles personnalisés chargés soient conformes aux souhaits.
Les utilisateurs peuvent également transmettre le chemin d'accès à un fichier de configuration via la ligne de commande. Dans ce cas, les autres fichiers de configuration seront ignorés. Par exemple:
checkov --config-file path/to/config.yaml
Les utilisateurs peuvent également créer un fichier de configuration à l'aide de la commande --create-config
, qui prend les arguments de ligne de commande actuels et les écrit dans un chemin donné. Par exemple:
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 :
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 l'indicateur --show-config
pour afficher tous les arguments et paramètres et leur origine, c'est-à-dire la ligne de commande, le fichier de configuration, la variable d'environnement ou la valeur par défaut. Par exemple:
checkov --show-config
Affichera :
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
La contribution est la bienvenue !
Commencez par consulter les directives de contribution. Après cela, jetez un œil à un bon premier numéro.
Vous pouvez même démarrer cela avec un développement en un clic dans votre navigateur via Gitpod au lien suivant :
Vous cherchez à verser de nouveaux chèques ? Apprenez à rédiger un nouveau chèque (politique AKA) ici.
checkov
n'enregistre, ne publie ni ne partage avec quiconque aucune information client identifiable.
Aucune information client identifiable 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 remédiation. Pour ignorer cet appel d'API, utilisez l'indicateur --skip-download
.
Prisma Cloud construit et maintient Checkov pour rendre la politique en tant que code simple et accessible.
Commencez par notre documentation pour des didacticiels et des exemples rapides.
Nous suivons le cycle de support officiel de Python et utilisons des tests automatisés pour les versions prises en charge de Python. Cela signifie que nous prenons actuellement en charge Python 3.9 à 3.12 inclus. Notez que Python 3.8 a atteint EOL en octobre 2024 et Python 3.9 atteindra EOL en octobre 2025. Nous étudions la prise en charge de 3.13. Si vous rencontrez des problèmes avec une version non-EOL de Python, veuillez ouvrir un problème.