Alright, I've been running Snyk for our infrastructure-as-code (Terraform, CloudFormation) for about 6 months now. Overall, it's been solid for catching high-severity misconfigurations in our repo—things like overly permissive S3 buckets or unencrypted databases. The dashboard is clean, and the Jira integration works smoothly.
But I keep hitting a frustrating snag with the **Terraform plan analysis**. It seems to parse the plan output incorrectly sometimes, especially with modules or complex `for_each` loops. For example, last week it flagged a security group rule as being "open to the world" because it read the temporary placeholder value from the plan phase (`0.0.0.0/0`) instead of the actual variable that resolves at apply. This creates noise and undermines trust in the results.
Has anyone else run into this? My workflow is basically:
* `terraform plan -out=tfplan`
* `terraform show -json tfplan > plan.json`
* Run Snyk on the `plan.json`
The findings from the `*.tf` files directly are accurate, but the plan analysis is where we want the security gate before applies. I'm starting to maintain a spreadsheet to track these false positives against actual Snyk results 😅. Wondering if there's a known workaround, or if I should just rely on the static file scan and skip the plan analysis for now.
Would love to compare notes with others using it for IaC in production.
— alex
Data > opinions
Yeah, I've hit the exact same thing. The plan JSON parsing is definitely the weak link. It's like Snyk's engine doesn't fully resolve all the interpolations before it checks the rules. Modules with for_each are the worst for me too.
I found a partial workaround: I run `terraform plan` with a dummy tfvars file that sets all the variables to their "worst case" values manually. It's ugly, but it cuts down the noise because the plan then shows the actual CIDRs instead of the placeholder. Still a pain to maintain.
Have you tried piping the plan through a quick jq filter to strip out the known false positives before Snyk sees it? That's on my todo list but I haven't had the time. I'd rather Snyk just fix their parser.
That placeholder value issue is a known parser limitation. Terraform's plan JSON outputs unknown values as placeholders for sensitive or computed attributes, and Snyk's engine isn't waiting for full resolution.
Your workflow is correct. The problem is you're trying to use the plan as a security gate, but the tool isn't giving you a valid signal. A spreadsheet for tracking false positives is a symptom of a broken process.
You need a deterministic artifact. Run Snyk against the rendered `*.tf` files *after* a `terraform plan` but *before* apply. Or, if you must gate on the plan, use a policy engine like OPA/Conftest that can evaluate the raw plan JSON with logic to ignore `known_after_apply` fields.
Five nines? Prove it.