An infrastructure as code review reads your Terraform or CloudFormation before it builds anything, which is the cheapest moment to catch an AWS misconfiguration. Fixing a security group in code takes a pull request. Fixing it after deployment means a change window, a rollback plan and an awkward conversation about how long the port was open. The NCSC’s secure development and deployment guidance makes the same argument about moving checks earlier.
Why the code matters more than the console
In an estate built from modules, one mistake ships everywhere at once. A module that opens port 3389 to 0.0.0.0/0 for a bastion host will do it in development, staging, production and the two accounts nobody remembers. When we review the console instead, we find twelve instances of the same problem and write twelve findings. When we review the module, we write one, and the fix lands in a single merge. That difference in effort is the whole argument for reviewing code, and it is why an AWS penetration testworks better when the tester has seen the templates first.
What the automated scanners catch, and where they stop
Static tools such as Checkov and tfsec find the well known patterns quickly: public S3 buckets, unencrypted volumes, missing log configuration, wide open security groups. They cannot reason about intent. A policy granting s3:GetObject on a specific bucket looks fine to a scanner and looks alarming to a human who knows that bucket holds exports of the customer database. Nor do they follow a chain: a role that can create another role, that can attach an administrator policy, is three files apart and perfectly valid in isolation.
“The finding that costs clients most is not a wide security group, it is Terraform state sitting in a bucket the whole engineering team can read. State files hold outputs, and outputs hold database passwords and access keys in plain text. Lock the state bucket down to the pipeline role, turn on versioning, and stop letting laptops apply changes directly.”
William Fieldhouse, Director, Aardwolf Security Ltd
The AWS patterns worth checking by hand
You should read every IAM policy in the repository yourself, because that is where the real privilege decisions are written. Wildcards in the action or resource field deserve a comment explaining why they exist. Trust policies matter as much as permission policies, since a role that any account can assume is a door with no lock. Look at the default VPC, which many templates quietly use, and at security groups that reference other security groups in a chain nobody has drawn out. Data resources are worth a pass too, because a public snapshot or an unencrypted RDS instance in code becomes a public snapshot in production.
Fitting the review into a delivery pipeline
Run the cheap checks on every pull request and the expensive ones on a schedule. Static scanning belongs in continuous integration where it blocks a merge in seconds. A human review of IAM and network design belongs at the point a new service is designed, or quarterly for an estate that changes constantly. Pair that witha vulnerability assessmentof the running environment, because code review tells you what should exist and only a live check tells you what actually does. The gap between the two is usually the interesting part, and it is where console changes made during an incident tend to live.
Frequently asked questions about infrastructure as code reviews
Two questions come up on every engagement of this type.
Do you need access to the AWS account as well as the repository?
Read-only access to the account makes the review far more useful. Code shows intent, the account shows drift, and the difference between them is where incidents start.
Does this replace cloud penetration testing?
No. A review predicts what the environment will look like. Testing proves what an attacker can do in the environment you actually built, including everything created outside the pipeline.
