.avif){kind=icon}
🚀 CloudSEK featured in the 2026 Frost Radar™!
Read more
Infrastructure-as-Code security is the practice of enforcing security requirements inside infrastructure definitions, correcting misconfigurations and excess privileges before deploying cloud infrastructure.
CloudSEK's investigation into the March 2026 LiteLLM supply chain compromise identified more than 2,500 organizations and roughly 434,000 CI/CD pipelines potentially exposed. Harvested material covered AWS, Google Cloud, and Azure credentials, SSH keys, Kubernetes tokens, and pipeline secrets.
Pipelines that build infrastructure hold the credentials that create it. Template scanning that stops at the template leaves the most privileged component in the delivery chain unexamined, which is where the last two years of cloud incidents have concentrated.
Where IaC Security Acts in the Delivery Pipeline
IaC security operates at five gates between an engineer writing a template and an existing cloud resource. Each gate catches a different class of problem, and skipping one pushes its findings downstream into production.
- Authoring. First, editor plugins and pre-commit hooks flag insecure resource attributes while the template is still being written, when the cost of a fix is a keystroke.
- Pull request review. Second, automated scans annotate the diff so reviewers see which change opens a security group, widens an IAM policy, or disables encryption.
- Plan analysis. Third, evaluation of the execution plan resolves variables, modules, and interpolations, exposing the resource configuration that will actually be created.
- Deployment admission. Fourth, policy engines block or approve the apply step, which converts a security finding from advisory text into an enforced condition.
- Drift detection. Fifth, continuous comparison between deployed state and committed code catches manual console changes that move an environment away from its reviewed definition.
How Infrastructure-as-Code Security Works
Infrastructure-as-Code security works by parsing template files into a resource model, evaluating that model against security policy, and returning a pass or fail verdict the pipeline acts on.
Static Analysis of Template Files
Scanners parse Terraform, CloudFormation, Kubernetes manifests, Helm charts, ARM, Bicep, and Dockerfiles into a structured representation of resources and attributes. Rules then test that representation for public exposure, missing encryption, permissive ingress, and unmanaged identity permissions.
Graph-Based and Plan-Aware Evaluation
File-level analysis misses risk that only appears when resources reference each other. Graph evaluation follows those references, so a bucket that looks private in isolation gets flagged once a policy attached elsewhere grants public read, and plan-aware analysis resolves variables and module inputs before judging the final configuration.
Policy as Code Enforcement
Open Policy Agent and its Rego language express organizational requirements as executable policy, evaluated by Conftest against Terraform plans, Kubernetes manifests, and JSON configuration. Policy expressed this way is versioned, reviewed, and tested like any other code in the repository.
Secrets and State File Protection
Terraform state records every attribute of every managed resource, including database passwords and generated keys, in plain text. State belongs in an encrypted remote backend with access restricted to the deployment role, and credentials belong in a secrets manager referenced at runtime. CloudSEK's investigation into public Postman workspaces found more than 30,000 leaking access tokens and API keys, the same failure mode transferred to a different artifact. Leaked API keys behave identically whether they escape through a shared collection or a committed state file.
Drift Detection Against Deployed State
Environments diverge from their definitions through emergency console changes, automated remediation, and vendor-side defaults. Drift detection compares live configuration against committed code and reports the difference, which restores the assumption that reviewing the template tells anyone what is running.
Security Risks Introduced by Insecure IaC
Insecure infrastructure code introduces seven risks that scale with every reuse of the template. OWASP catalogues the pipeline half of this problem in its Top 10 CI/CD Security Risks, covering dependency chain abuse, poisoned pipeline execution, and insufficient pipeline access control.
- Public exposure: storage buckets, databases, APIs, and management interfaces reach the internet through a single permissive attribute, and the exposure persists until someone scans for it from outside.
- Excessive privilege: wildcard actions and broad resource scopes in IAM policy definitions turn one compromised credential into control of an entire account.
- Machine identity abuse: service accounts and roles created through templates rarely receive the review that human accounts get, giving attackers durable access that application controls never see.
- Network overreach: open security group rules and flat subnet design remove the isolation that limits blast radius after initial access.
- Pipeline abuse: a deployment role with administrative rights makes the pipeline itself the most valuable target in the environment, and a malicious pull request inherits those rights.
- Configuration drift: manual changes outside code leave the reviewed template describing an environment that no longer exists.
- Module supply chain risk: shared registry modules, community providers, and pinned-to-latest GitHub Actions execute third-party code with pipeline credentials, making a supply chain attack upstream a direct compromise downstream, and a third-party breach that no internal review could have caught.
Why Infrastructure-as-Code Security Matters
Infrastructure-as-Code security matters because one insecure attribute in a reused template becomes the same insecure attribute in every environment built from it. Correction at the definition stage carries five effects that post-deployment tooling cannot reproduce.
- Attack surface reduction before exposure: a public endpoint blocked at review never appears in an internet scan, which removes the window between provisioning and detection.
- Privilege limits at the definition stage: least privilege enforced in the policy document constrains an attacker holding valid credentials, long before any detection control notices the credential is stolen.
- Consistency across teams and environments: the same policy set evaluates every template, closing the variation that appears when each team configures infrastructure to its own standard.
- Containment of repeated mistakes: a rejected pattern stops replicating across regions and accounts, which is where a single template error turns into hundreds of exposed resources.
- Auditable change history: versioned definitions and scan results record what changed, who approved it, and which control evaluated it, giving security operations a reference point during investigation.
Infrastructure-as-Code Security Tools in 2026
Checkov, Trivy, and KICS carry active maintenance through 2026, and each covers a different span of template formats. Several tools on older comparison lists have since been archived or folded into other projects, and pipeline coverage degrades quietly when a frozen scanner keeps returning green.
Tool choice matters less than where the gate sits in the delivery sequence. A scanner running only on a nightly schedule reports findings after deployment, converting a preventive control into a slower version of posture management.
When IaC Security Scanners Become the Supply Chain Risk
Security scanners hold a privileged position in the pipeline, with simultaneous access to cloud credentials, repositories, and container infrastructure. That position made them a target in March 2026.
On March 19, the TeamPCP group force-pushed malicious code into 76 of 77 tags of the aquasecurity/trivy-action GitHub Action and all seven tags of aquasecurity/setup-trivy, alongside a trojanized Trivy binary. Four days later, credentials harvested from that compromise were used against Checkmarx, poisoning the kics-github-action and ast-github-action workflows. The Trivy incident carries CVE-2026-33634 at CVSS 9.4 and reached CISA's Known Exploited Vulnerabilities catalog within days.
Payloads in each wave scraped runner memory for cloud provider credentials, Kubernetes tokens, SSH keys, and pipeline secrets. Stolen tokens then reached LiteLLM's PyPI publishing pipeline, producing the AI supply chain exposure CloudSEK documented across 2,500 organizations. Every wave in that cascade entered through a tool teams had installed to improve security, which reframes supply chain defense as a pipeline problem before it is a vendor problem.
Mutable tags supply the mechanism behind every wave in that cascade. An Action referenced as v0.34.2 resolves to whatever commit the tag currently points at, and a force-push silently changes what runs. Pinning to a full commit SHA removes that pathway entirely.
IaC Security vs CSPM and Runtime Cloud Security
IaC security prevents insecure configurations from reaching a cloud account, and CSPM finds them once they arrive. Runtime cloud security handles what happens after that, and a working program funds all three.
Infrastructure-as-Code Security Best Practices
A program that blocks risk differs from one producing advisory reports across practices. Enforcement placement carries more weight in that difference than scanner selection does.
- Pin every third-party reference. Pin GitHub Actions to full commit SHAs and registry modules to exact versions, since mutable tags let an upstream compromise reach the pipeline without any local change.
- Fail the build on policy violations. Configure scanners to break the pipeline on findings above an agreed severity, because advisory output that nobody blocks on gets ignored within weeks.
- Scan on every change. Run analysis on modifications to existing templates and on new ones, since a safe resource turns unsafe when a referencing resource changes.
- Keep secrets out of templates and state. Reference a secrets manager at runtime, encrypt the state backend, and scan commit history for credentials that already landed in the repository.
- Scope the deployment identity narrowly. Grant the pipeline role only the permissions its resource types require, and apply zero trust conditions to the identity that holds cloud administrative rights.
- Standardize on reviewed modules. Publish an internal module registry with pre-approved patterns so teams inherit secure defaults instead of authoring resource blocks independently.
- Isolate pull request execution. Run plan operations from untrusted branches without production credentials, which removes the poisoned pipeline execution path.
- Verify the result from outside. Confirm through external attack surface management that deployed resources match what the templates intended, since a passing scan describes intent and not outcome.
How CloudSEK Complements IaC Security
IaC security identifies insecure configurations before deployment. However, secure IaC templates do not guarantee a secure production environment. Manual changes, configuration drift, shadow assets, and resources created outside IaC workflows can introduce exposures that the original code does not capture.
CloudSEK BeVigil complements IaC security by continuously monitoring the external attack surface after deployment. It discovers internet-facing assets and identifies vulnerabilities and misconfigurations across cloud infrastructure, web applications, APIs, DNS, SSL, networks, and other exposed services.
This provides an outside-in validation layer. IaC scanners such as Checkov, Trivy, and KICS assess infrastructure definitions before deployment. BeVigil assesses the deployed environment and shows what is externally exposed. It can identify configuration drift, forgotten assets, exposed services, cloud misconfigurations, and other potential initial-access vectors that may not appear during template review.
Together, these controls cover both infrastructure intent and outcome: IaC security reduces risk before deployment, while BeVigil verifies that the live external attack surface remains consistent with the intended secure configuration.
Frequently Asked Questions
Is IaC security only relevant for large organizations?
No. Any team provisioning cloud resources through automation replicates a misconfiguration across every environment that reuses the template.
Does IaC security cover resources created outside code?
No. Console-created and manually provisioned resources appear in no template, so drift detection and external scanning remain necessary alongside template review.
Who owns IaC security, DevOps or the security team?
Both. Engineering teams author the definitions and fix findings, while security defines the policy set and the severity threshold that blocks a build.
Does IaC scanning slow down deployment?
No. Scans complete in seconds against a template, and correcting a configuration before provisioning costs far less time than remediating a live resource.
Can IaC scanners detect hardcoded secrets?
Yes. Checkov, Trivy, and KICS include secret detection, though they catch only what reaches the repository and not values held in excluded variable files.
Does IaC security produce compliance evidence?
Yes. Versioned policy files, scan results, and pipeline logs document which control ran against which change, and when it blocked a deployment.
