Prisma Cloud: Image Scanning and IaC Checks

Posture management finds what already exists in your cloud. Shifting left means catching the same problems earlier: vulnerable packages in a container image before it is pushed, an open security group in a Terraform file before it is applied. Prisma Cloud offers both as CLI tools you can run in any pipeline, and the open-source engine behind the code checks, Checkov, works on its own too.

Versions in use on this date. Checkov 2.3.x (Python 3.7 to 3.11) and a current twistcli downloaded from your Prisma Cloud console, because the CLI must match your console version. Product and menu names change over time, so use the names in your own console.

Where the checks sit

flowchart TB
  PR[Pull request] --> IAC[Checkov on Terraform, CloudFormation, Dockerfile, Kubernetes manifests]
  IAC -->|fail on high severity| BLOCK1[Block merge]
  IAC -->|pass| BUILD[Build container image]
  BUILD --> SCAN[twistcli images scan<br/>vulnerabilities, compliance, secrets]
  SCAN -->|fails policy| BLOCK2[Fail build, report CVEs]
  SCAN -->|passes| PUSH[Push image to registry]
  PUSH --> RSCAN[Registry scan on schedule<br/>catches new CVEs in old images]
  PUSH --> DEPLOY[Deploy to Kubernetes or ECS]
  DEPLOY --> DEF[Defender runtime protection<br/>DaemonSet on nodes]
  DEF --> CONSOLE[(Prisma Cloud console)]
  SCAN --> CONSOLE

Scan images with twistcli

Download twistcli from the console (Manage, System, Utilities in many versions) and keep it with your CI tooling. Authenticate with an access key created for the pipeline with only the CI user role, never a personal admin account.

export PC_CONSOLE=https://console.example.com:8083     # your console address
./twistcli images scan \
  --address "$PC_CONSOLE" --user "$PC_USER" --password "$PC_PASS" \
  --details --ci shop-api:1.4.2

Credentials come from CI secrets (masked), never from the repository. The command compares the image’s packages and libraries with the vulnerability database and with the policy configured in the console (Defend, Vulnerabilities, Images, CI). It exits non-zero when findings exceed the policy, so the pipeline fails.

A sensible policy to start with:

Setting	Value
Block on	Critical and High severity vulnerabilities that have a fix available
Grace period	Short (for example 7 days) for newly published CVEs, so builds do not break on the day of disclosure
Compliance checks	Run as non-root, no secrets in the image, no ADD of remote URLs
Exceptions	Per CVE or per image with a reason and an expiry

Add it to the pipeline after the build and before the push:

- name: Scan image
  run: |
    ./twistcli images scan --address "$PC_CONSOLE" --user "${{ secrets.PC_USER }}" \
      --password "${{ secrets.PC_PASS }}" --details shop-api:${{ github.sha }}

Fixing findings usually means: rebuild on an updated base image, use a smaller base (distroless or Alpine), remove unneeded packages, and update application dependencies. Multi-stage builds keep compilers and test tools out of the final image.

Scan IaC with Checkov

Checkov is the open-source policy engine behind Prisma Cloud’s code security module. It parses files statically (no cloud access needed) and checks them against thousands of rules.

pip install "checkov==2.3.*"
checkov -d terraform/ --framework terraform
checkov -f template.yaml --framework cloudformation
checkov -d k8s/ --framework kubernetes
checkov -f Dockerfile --framework dockerfile
checkov -d . --compact --quiet --output cli --output sarif --output-file-path console,results.sarif

Each failed check has a rule ID and a link to the guideline, for example:

Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
  FAILED for resource: aws_s3_bucket.assets
  File: /main.tf:12-18

Other common findings: unencrypted EBS or RDS storage, S3 buckets without public access blocks, security groups open to 0.0.0.0/0, IAM policies with "*", missing CloudTrail validation, Kubernetes containers running as root or privileged.

Run it in the pull request and on main. Upload the SARIF file so findings appear in the code review (GitHub code scanning supports it), and use --soft-fail for the first weeks if you need time to clean up, then switch to blocking. Select what to enforce with --check and --skip-check or a .checkov.yaml configuration file.

Suppress accepted risks, visibly

Suppression belongs next to the code, with a reason, so reviewers see it:

resource "aws_s3_bucket" "assets" {
  #checkov:skip=CKV_AWS_18: access logs are delivered by the central logging bucket
  bucket = "acme-assets-prod"
}

For existing projects with many findings, create a baseline (checkov --create-baseline) so only new findings fail the build, and burn down the old ones over time. Review skips periodically; a skip without a reason is a hidden risk.

Runtime protection with Defenders

Scanning cannot catch everything that happens after deploy. Prisma Cloud’s Defenders are agents that run on hosts or as a DaemonSet in Kubernetes, enforcing runtime rules: block unexpected processes in containers, watch network connections, and detect file changes. Deploy them from the manifest or Helm command the console generates for your cluster, pinning the image version your console expects.

kubectl get pods -n twistlock -l app=twistlock-defender

Start in alert mode, review for two weeks to learn normal behaviour, and only then turn on prevent rules for well-understood workloads. Blocking too early breaks applications that legitimately spawn shells or write to unexpected paths.

Make it stick

1. Treat the scan as part of the definition of done: no merge without a clean IaC check and image scan.
2. Rescan registries on a schedule, since a clean image today can have a published CVE tomorrow.
3. Track mean time to fix critical findings, and report it with other delivery metrics.
4. Keep the tool versions pinned and update them regularly, so rule changes are intentional.
5. Do not let the scanners become noise: tune policy and exceptions until a red build means something.