GitLab IaC scanning is a built-in SAST analyzer that inspects your infrastructure-as-code files, such as Terraform, Kubernetes manifests, and CloudFormation, for insecure configuration before they ever reach a cloud account. It catches the class of mistake that causes a huge share of cloud breaches: a storage bucket left public, a security group open to the world, encryption switched off.
The value is timing. A misconfiguration caught in a merge request costs a one-line change. The same misconfiguration discovered by an attacker in production costs an incident.
What GitLab IaC scanning actually inspects
GitLab implements IaC scanning as part of its SAST offering, using an analyzer built on the open source KICS engine (Keeping Infrastructure as Code Secure). It parses declarative infrastructure files and matches them against a large ruleset of known insecure patterns.
Supported formats include:
- Terraform (
.tffiles) - Kubernetes manifests and Helm charts
- AWS CloudFormation
- Ansible playbooks
- Dockerfiles
- Azure Resource Manager and Google Deployment Manager templates
The rules cover things like public network exposure, missing encryption at rest, overly permissive IAM, disabled logging, and containers running as root.
Turning it on
If your project already uses GitLab's managed SAST template, IaC scanning comes along for free. The minimal setup is a single include in your .gitlab-ci.yml:
include:
- template: Jobs/SAST-IaC.gitlab-ci.yml
That adds an iac-sast job to your pipeline. On the next run, GitLab scans any supported infrastructure files it finds and produces a report. If you want the full SAST suite (which bundles IaC alongside code analyzers), include Security/SAST.gitlab-ci.yml instead.
No extra credentials or cloud access are required. The analyzer reads the files statically; it never touches your live infrastructure.
Reading and triaging the results
Findings appear in the merge request widget and, on GitLab Ultimate, in the Vulnerability Report with full lifecycle tracking. Each finding names the file, the line, the rule that fired, and a severity.
The practical challenge is not getting results, it is triaging them. A first scan of a mature Terraform repo can surface hundreds of findings, many of them low severity or intentional. Two moves keep this manageable:
- Start by gating only on high and critical severity, so the pipeline blocks on genuinely dangerous settings while lower-severity items are tracked but do not fail the build.
- Use inline dismissal for accepted risks, with a documented reason, so the same finding does not resurface every pipeline.
variables:
# Only fail the pipeline on the most serious IaC findings at first
SAST_IAC_EXCLUDED_ANALYZERS: ""
# Gate configuration lives in the project's security policy, not the job itself
Where GitLab's native scanning stops
GitLab IaC scanning is strong at pattern-matching individual files, but it has boundaries worth knowing. It does not model runtime cloud state, so it cannot tell you that a resource which looks fine in Terraform was later changed by hand in the console. It also focuses narrowly on infrastructure files and does not correlate an IaC misconfiguration with the application vulnerabilities running on top of that infrastructure.
For most teams that is fine as a starting layer. Programs that need a unified view across infrastructure, dependencies, and application code often feed IaC results into a broader platform. A tool such as Safeguard can ingest IaC findings alongside dependency scanning results so a single risk view spans both the infrastructure and the software it hosts.
A sensible rollout order
Do not switch on gating for a large existing repo on day one; you will drown the team. A rollout that works:
- Enable the scan in report-only mode and let it run for a sprint.
- Review the high and critical findings, fix or formally accept each.
- Turn on gating for critical severity only.
- Ratchet down to high severity once the critical backlog is clear.
- Feed remaining findings into the normal backlog with owners.
Treating it as a ratchet, tightening the gate as the backlog shrinks, keeps developers on your side instead of teaching them to bypass the pipeline.
Keep the rules current
KICS and GitLab's analyzers update regularly as new cloud services and misconfiguration patterns emerge. Because the analyzer runs as a container image pinned by the template, you inherit updates when you keep the SAST template version current. Pin deliberately and review the changelog rather than floating on latest, so a ruleset change does not silently alter which merge requests pass. The security academy covers policy-as-code patterns for managing this at scale.
FAQ
Is GitLab IaC scanning available on the free tier?
The scanning job runs and produces findings on all tiers, including free. The richer features, such as the Vulnerability Report, merge request approvals based on findings, and security dashboards, require GitLab Ultimate.
What engine does GitLab use for IaC scanning?
GitLab's IaC scanning is built on KICS, an open source scanner that checks infrastructure-as-code against a large ruleset of insecure configuration patterns across Terraform, Kubernetes, CloudFormation, and other formats.
Does IaC scanning connect to my cloud account?
No. The analyzer reads your infrastructure-as-code files statically inside the pipeline. It never authenticates to or inspects your live cloud resources, which means it also cannot detect drift introduced by manual changes.
How do I avoid overwhelming developers on the first scan?
Start in report-only mode, then gate on critical severity only, and tighten to high severity once that backlog is cleared. Ratcheting the gate as findings shrink prevents the alert fatigue that leads teams to bypass scanning entirely.