Terraform Plan Blast Radius Reviewer That Explains Risky Infrastructure Changes on Pull Requests

The problem: approving infrastructure changes nobody read

Teams that manage cloud infrastructure as code review changes in pull requests, and the plan output shows what will happen. In practice the plan for a modest change can run to hundreds of lines, and a reviewer skims it. Somewhere in the middle, a renamed attribute forces a database to be replaced (destroyed and recreated), or a security group rule now allows the whole internet, or a role now has * permissions. These lines look like all the others.

Outages and data loss caused by infrastructure changes are common, and many of them were visible in the plan. The problem is attention, not information.

What already exists and the gap

• Atlantis and similar tools run plans in pull requests and post the raw output.
• Checkov, tfsec and Trivy scan Terraform code for misconfigurations, on the code rather than the change being made.
• Infracost shows the cost change of a plan.
• Open Policy Agent with conftest lets teams write policies against plans, but they must write all of them themselves.

The gap is a reviewer that focuses on the change, not the whole codebase, and explains its consequences: what data could be lost, what becomes reachable, what access grows. It should come with sensible built-in rules for common resources and let teams add their own.

Inspiration

"The Seven Sins: Security Smells in Infrastructure as Code Scripts" by Akond Rahman, Chris Parnin and Laurie Williams (ICSE 2019) identified seven recurring security smells in infrastructure code, including admin by default and invalid IP address binding, and found 21,201 occurrences in 15,232 scripts from 293 open source repositories. That work looks at code; this project applies the same careful categorisation to the change a plan describes, which is what a reviewer must approve.

What you build

• Reviewers see a three-line summary at the top of each pull request: "High risk: 1 database will be replaced (data loss); 1 security group opens port 5432 to 0.0.0.0/0. Medium: IAM role gains s3:* on all buckets."
• Authors see the same summary before they ask for review and can fix accidents early.
• Platform teams set rules such as "replacing a stateful resource needs two approvals".

The technically interesting part

• Reading plans precisely. The JSON plan lists actions per resource, including "delete then create" for replacements, and the attribute that forced the replacement. Surface that attribute, because it is usually the accidental cause.
• Knowing what is stateful. A replaced database, disk, bucket or queue may lose data; a replaced load balancer listener does not. Build a catalogue of common resource types with their risk properties.
• IAM diffs. Compare old and new policy documents, expand wildcards against known action lists, and describe the growth: "from 3 read actions on one bucket to all S3 actions on every bucket".
• Exposure. Detect new ingress from the internet, public bucket access, public database flags and new public IPs, considering the rules that already exist.
• Readable output. Most value is in a short, correct summary. Test the wording with real reviewers.
• Modules and unknown values. Plans built from modules nest resources deeply, and some values are only "known after apply". Handle both, and when a risk depends on an unknown value, say so instead of guessing.
• Lifecycle settings. Respect prevent_destroy and create_before_destroy, which change how risky a replacement really is, and suggest adding them to stateful resources that lack them.

How to evaluate it

• Seeded changes: create a set of risky and harmless changes on sample infrastructure and measure detection and false alarms.
• Real history: run on the pull request history of open source infrastructure repositories and judge flagged changes by hand.
• Review time: in a small study, compare how long reviewers take and how many risky changes they catch, with and without the summary.

Suggested plan

• Weeks 1 to 3: Terraform or OpenTofu on a small AWS setup within free tier; produce JSON plans.
• Weeks 4 to 7: plan reader and the resource risk catalogue.
• Weeks 8 to 11: IAM diff, exposure checks and pull request comments.
• Weeks 12 to 15: Rego policies, evaluation and report.

Path to a product

Infrastructure teams care about change safety, and a focused, readable reviewer is easy to try on one repository. An open source action with a hosted tier for organisations with many repositories and audit needs is a familiar model.

Scope warning

You do not need real cloud resources to test most of this: plans can be generated against a mocked or local provider, and against a free-tier account with strict budget alerts. Support AWS first. Do not apply plans automatically.

Learn what you need on Sefism

• Cloud engineering roadmap: networking, IAM and stateful services on the cloud.
• Terraform Tutorials: plans, state and providers.
• OpenTofu Documentation: the open source alternative and its plan format.
• Terraform: Up and Running: how teams manage infrastructure changes safely.
• How do I practise on AWS, Azure or Google Cloud without getting a surprise bill?: keep your test account safe.

Get help with this idea

The risk is a reviewer that flags everything or misses replacements. Tauseef can help you build the risk catalogue, plan the seeded change set and keep cloud costs at zero while testing. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session