No Infrastructure-as-Code security scan in the pipeline
ID |
iac_scan_in_use |
Severity |
low |
Remediation Complexity |
medium |
Remediation Risk |
low |
Remediation Effort |
medium |
Family |
SCM |
Tags |
ASVS50:v15.1.1, ASVS50:v15.2.1, non-reachable, security, spvs10-v2.4.10, spvs10-v2.4.13, spvs10-v3.3.10, spvs10-v3.3.13, supply-chain, testing |
Description
Does the project run an Infrastructure-as-Code (IaC) security scanner in its pipeline?
Terraform, CloudFormation, Kubernetes manifests, and Helm charts are code, and they ship insecure defaults just like application code — open security groups, public buckets, privileged containers, missing encryption. An IaC security scanner (Checkov, KICS, tfsec, …) catches these before deployment. This check looks for a recognised IaC scanner in the project’s pipeline definitions (or build scripts) and reports when none is found (SPVS V2.4.10 / V3.3.10 IaC scanning; V2.4.13 / V3.3.13 IaC policy enforcement).
It reuses the shared security-tool catalog and the same PipelineToolDetector engine as sast_in_use / secrets_scan / pipeline_scan_vuln, so it is multi-CI (GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, CircleCI) and also matches invocations inside build scripts.
The recognised IaC scanners are those tagged iac_scanner in the security-tool catalog. The Xygeni IaC scan itself (xygeni … iac) also satisfies this check.
|
Unlike sast_in_use / secrets_scan, this check is conditional on the project actually shipping IaC. A repository with a pipeline but no infrastructure code has nothing for an IaC scanner to analyse, so the finding is suppressed there (SPVS V2.4.10 / V3.3.10 is not applicable rather than failing). The finding is only reported when the pipeline runs no IaC scanner and the repository contains at least one recognised IaC template — Terraform, CloudFormation, Kubernetes manifest, Helm chart, ARM/Bicep, Ansible, Pulumi, Puppet or Chef. A bare Dockerfile / docker-compose file does not count as an IaC template.
Security
Scanning IaC in the pipeline shifts cloud-misconfiguration detection left: a public S3 bucket or an over-permissive IAM role is caught at merge time instead of in production. Running an IaC scanner on every change (and failing the build on high-severity findings) is the SPVS V2.4/V3.3 expectation for infrastructure code.