Reading & triaging findings

Checks, severity, guides.

Intermediate12 min · lesson 3 of 12

Every Checkov finding has a stable check ID (CKV_AWS_18, CKV_K8S_20…), a description, the offending resource and location, and a remediation link. Triaging well means reading three things: what the check enforces, whether it genuinely applies to this resource, and how to fix it. The stable IDs matter — you reference them in suppressions, in your baseline, and when discussing a finding, so they are the vocabulary of the whole workflow.

terminal

$ checkov -d . --compact
Check: CKV_AWS_79: "Ensure Instance Metadata Service V2 is required"
	FAILED for resource: aws_instance.app
Check: CKV_K8S_20: "Ensure containers do not run with allowPrivilegeEscalation"
	FAILED for resource: Deployment.default.payments-api

Severity and prioritization

Not every finding is equally urgent. Checkov (especially with a Prisma/API key, or via metadata) associates checks with severities, and you prioritize by them — a publicly exposed database is critical; a missing tag is informational. In CI you typically gate hard on high/critical and report the rest, so developers fix what matters and are not blocked by cosmetic findings. The next lessons build on this: suppress deliberately, gate by severity, baseline the rest.

terminal

# gate only on high+ severity, report the rest (needs severity metadata / API key)
$ checkov -d . --check HIGH,CRITICAL
# or list/select specific checks by ID
$ checkov -d . --check CKV_AWS_18,CKV_AWS_79

A finding you do not understand is not a finding you can dismiss

The temptation with a failing check is to suppress it to make CI green. Resist it: read the guide, confirm whether the risk is real for your resource, and either fix it or suppress it with a documented reason (next lesson). Blind suppression turns a security tool into decoration — the finding you did not understand is often the one that matters.

Install & first scanFrameworks: Terraform, k8s, more