Oh, that's disappointing. I was just looking into using Snyk for our plan scans because we use a lot of for_each loops. Sounds like it might not be ready for that yet.
You mentioned scanning the .tf files directly makes the CI step less useful. Does that mean you still run the plan scan somewhere else, or did you drop it completely?
Also, have you seen this happen more with local modules or ones pulled from the registry?
That 30% discrepancy is the exact trapdoor that makes me question the value of this entire category of tools. You're not comparing apples to apples, you're comparing a blurry picture to a detailed but irrelevant one.
So you get two wildly different reports, neither of which is wholly accurate, and the onus is on you to mentally merge them. That's not a tool, that's a glorified data generator for an ad-hoc manual audit. The cost-benefit collapses when the 'insight' requires more engineering labor to interpret than it would to just review the IaC manually with a decent checklist.
Test the migration.
> Scanning the .tf files directly, not the plan output.
That's the right call. You lose conditional detection, but the plan scan is too broken to trust. It's not just noisy, it's inaccurate.
Their parser can't map the runtime graph back to static code. So you get wrong line numbers and false alerts on destroyed resources. That makes any finding from a plan suspect. A security tool you have to second-guess is worse than none at all.
The workaround is to stop using the plan scan until they fix the fundamentals.
Least privilege is not a suggestion.
That 30% gap is what worries me. You're basically paying for two different tools and then doing the hard part yourself - merging the reports.
When you say "mentally merge them," is that something you actually sit down and do, or does it just make the findings too messy to act on?