Infrastructure-as-code changes can create serious security risk with very little code.
A one-line permission change can expose a storage bucket. A GitHub Actions edit can expand token access. A Terraform module update can make a private service reachable from the internet. These changes often land through the same pull request process as application code, but they need a different kind of review.
IaC security review is about catching unsafe defaults and privilege expansion before they reach production.
What makes IaC review hard
IaC changes are easy to underestimate because they look declarative. The security impact depends on how the resource behaves after deployment.
Reviewers need to understand:
- Which identities gain new permissions.
- Whether access is public, cross-account, or tenant-scoped.
- Whether secrets move into logs, env vars, or build outputs.
- Whether CI/CD tokens can write where they should only read.
- Whether a new network path bypasses expected controls.
- Whether an application change depends on the infrastructure change.
That context is spread across Terraform, GitHub Actions, cloud policy, application config, and deployment conventions.
Common IaC security issues in PRs
Look closely for:
- Overly broad IAM actions such as wildcard resource access.
- Public buckets, queues, dashboards, or databases.
- Security groups that expose admin ports or internal services.
- GitHub Actions workflows with unnecessary write permissions.
- OIDC trust policies that match too many repositories or branches.
- Secrets added to repo variables, logs, build artifacts, or Docker layers.
- Terraform modules that change defaults during an upgrade.
- Production and staging policies copied without environment-specific constraints.
These mistakes are often not malicious. They happen because the fastest path to a working deployment is rarely the safest path.
Why scanners are not enough
IaC scanners are useful for known misconfigurations. They can catch broad public access, missing encryption, dangerous defaults, and policy violations.
The hard cases depend on intent:
- Is this role supposed to deploy production, or only preview environments?
- Is this bucket public because it serves static assets, or because a setting was copied?
- Is this workflow allowed to write packages from pull requests?
- Does this new outbound access create an SSRF impact path in the application?
Those questions require codebase and workflow context. That is why IaC review belongs in the pull request, not only in a later compliance report.
PR checklist for IaC security
Before merging infrastructure changes, check:
- Identity: Which users, services, roles, and CI jobs gain access?
- Scope: Are permissions limited by resource, environment, branch, and account?
- Exposure: Does anything become public or reachable from a new network?
- Secrets: Are tokens, keys, or credentials stored or printed anywhere new?
- CI/CD: Can a pull request influence a privileged workflow?
- Blast radius: If this resource is compromised, what else can it reach?
- Drift: Does this change bypass existing policy or monitoring assumptions?
- Application tie-in: Does the app now depend on a riskier infrastructure path?
The goal is not to block every infrastructure change. It is to make risky changes visible before they deploy.
How Hacktron helps
Hacktron Review reviews pull requests for security impact across application code, configuration, supply chain, and infrastructure-as-code.
For IaC changes, the useful output is not just “this policy is broad.” It is why the permission matters in the context of the repository and what the developer should tighten before merge.
Hacktron can also learn project-specific rules in .hacktron/rules.md, such as allowed deployment roles, trusted account IDs, branches that may publish artifacts, or resources that should never be public.
Hacktron is strongest when the infrastructure change and application change meet. A cloud permission may look low severity in isolation, but become critical if the PR also introduces an SSRF path, a public webhook, or a privileged GitHub Actions workflow.
How to evaluate IaC security review tools
Use pull requests that changed real infrastructure:
- A GitHub Actions workflow.
- A Terraform IAM policy.
- A storage bucket or CDN rule.
- A Kubernetes deployment.
- A cloud function permission.
- A dependency or container build step.
Then ask whether the tool explained the security impact in terms your developer could act on. A long list of misconfiguration labels is less useful than one precise comment that prevents a production exposure.