IaC scanning
What IaC scanning covers
| Format | Coverage |
|---|---|
Terraform (.tf, .tf.json) | Provider rules across AWS, GCP, Azure, OVHcloud, and Scaleway, modules and root modules |
Kubernetes manifests (.yaml, .yml) | Mirror of the KSPM rule set, evaluated statically |
| Dockerfiles | Image hygiene rules: pinned base images, non-root user, no secrets in ENV |
| Helm charts | Templated YAML, rendered and then scanned |
Rule keys mirror their CSPM and KSPM equivalents where it makes sense, so a finding caught in the IaC layer maps to the same rule that would catch it at runtime.
How it integrates with your repos
The exact integration model depends on your git provider. Common shapes:
- Scan branches when changes are pushed.
- Annotate pull requests / merge requests with a summary of findings.
- Optionally block merges above a configurable severity threshold.
The setup wizard handles the provider-specific bits. See Scan IaC from a Pull Request.
Drift between IaC and cloud
When IaC scanning is connected to the same project as a CSPM-scanned cloud, every finding gets a drift tag:
| Tag | Meaning |
|---|---|
code_and_cloud | The misconfig exists both in the IaC repo and in the live cloud. Fix once, deploy. |
drift | The cloud diverged from IaC. Either someone changed it manually or another tool did. |
code_only | The IaC has the misconfig but the cloud does not, yet. Fix before merging. |
Drift is reported next to the finding so you know whether to fix the code, the cloud, or both.
What an IaC finding looks like
| Field | Example |
|---|---|
| Rule key | TF-AWS-S3-PUBLIC |
| File path | terraform/prod/s3.tf |
| Line number | 42 |
| Resource type | aws_s3_bucket |
| Resource name | data_bucket |
| Repository | acme/infra |
| Branch | main |
| Commit | Short SHA |
What's next
- The IaC module, scan history, branches, drift visualisation
- Scan IaC from a Pull Request
- CSPM, the runtime sibling of IaC scanning