Terraform and infrastructure-as-code security review
An infrastructure-as-code security review reads your Terraform, or whatever defines your cloud, before it is applied and finds what it would let happen: insecure defaults, secrets sitting in state, IAM roles broader than the job, storage with no encryption or logging. We then add policy-as-code checks to your pipeline so the same mistakes are caught on the next pull request instead of in production.
What a Terraform security review covers
- Insecure defaults. Module inputs that default to public, unencrypted or unlogged, so every team that calls the module inherits the gap.
- Secrets in code and state. Passwords in variable files, API keys in outputs, and generated database passwords sitting in state in plain text.
- IAM breadth. Wildcard actions, roles that can pass or assume other roles, and the pipeline’s own credentials, which are often the most powerful identity in the account.
- Encryption and logging. Storage, queues, databases and load balancers created without either.
- Supply chain. Unpinned provider and module versions, and modules pulled from sources nobody reviewed.
Why state files need their own look
Terraform records resource attributes in state, and many of those are secrets: generated passwords, connection strings, private keys. Anyone who can read the state bucket can read them. We check where state lives, who can read and write it, whether it is encrypted and locked, and whether access to it is logged.
Drift: when the code stops describing the estate
A security group opened by hand during an outage, or a role widened in the console “for now”, is drift. The code says one thing and the account does another, and the next apply either reverts the fix or fails. Where you give read-only access, we compare the two and list what has moved.
Policy-as-code guardrails in CI
Findings fixed once tend to come back. The durable fix is a set of rules that run against every plan and fail the build when a change would, for example, create a public bucket or grant a wildcard role. We write those rules with your engineers, start them in warn-only mode, and move them to blocking when the false positives are gone. The same approach sits inside our broader secure development work.
What you receive
| Deliverable | What it is for |
|---|---|
| Findings report | Each issue tied to the file, module and line that causes it |
| Drift list | What the running estate does that the code does not say |
| Policy rules | Checks for your pipeline, with the reasoning for each |
| Re-review | Confirms each fix is in the code, where the next apply will not undo it |
If you want a quick self-check first, start with our Terraform security checklist. For what is already running, see the cloud security configuration review.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What access do you need?
Read access to the repositories that hold your infrastructure code, a recent plan output, and a description of where state is stored and who can read it. Read-only access to the cloud account is needed only if you want drift compared.
Which tools and languages do you cover?
Terraform and OpenTofu are the most common, followed by CloudFormation, Bicep, Pulumi and Kubernetes manifests. The questions are the same in each: what the code permits, what it stores, and whether the running estate still matches it.
Will policy checks slow our pipeline down?
Rarely by much. A policy check reads a plan that has already been computed, so it is quick next to the plan itself. New rules start in warn-only mode, false positives are tuned out with your engineers, and only then do the rules that matter switch to blocking.
How is this different from a cloud security review?
A cloud security review reads what is deployed today. An infrastructure-as-code review reads what will be deployed next, and the habits in your modules that keep producing it. The two pair well, and the findings map onto each other.
Get your infrastructure code reviewed
Tell us which tool you use, roughly how many repositories and accounts are involved, and whether you want drift compared. The reply says what a review would cover. See also all security services.