IaC scanning: 12 questions to ask a vendor before you buy

Ask an IaC scanning vendor what files it reads, whether it evaluates the real plan or only the text, how you suppress and tune findings, and what format results come in. Run a trial on your own repository, because the answers that matter show up on your code, not a demo.

What does the scanner read?

1. Which formats? Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfiles, Bicep, Ansible? List yours and test each.
2. Does it resolve variables and modules? A resource built from a variable looks harmless as text. Scanners that only read raw files miss values set elsewhere. Terraform can output a JSON form of a plan, which includes configuration and resolved values, using terraform show -json on a plan file. Ask whether the tool can read that.
3. Does it follow remote modules and Helm dependencies? Many risky settings come from a shared module you did not write.

What does it find?

4. What is the rule source? Can you read each rule, see the logic and the reference it came from? Opaque rules are hard to defend in an audit.
5. Can you write your own rules? Every organization has a naming, tagging or region policy. Check the language and the effort.
6. Does it test the settings that matter? Public storage, open ingress, missing encryption, broad permissions, logging turned off. Use a deliberately bad sample repo and see what it catches. Misconfiguration remains an OWASP Top 10 category, which is why this class of check matters.
7. Does it say why a finding matters? A fix hint beats a rule number.

How does it fit your workflow?

8. Where does it run? On a laptop, in a pull request, in the pipeline, on a schedule against the repository. Setup order is usually pull request first, because that is where a fix costs least.
9. What does the output look like? SARIF is an open format for static analysis results and makes it easier to combine tools. Ask for SARIF plus plain JSON, and check it loads in your code scanning view.
10. Can you suppress with a reason? Inline comments or a central file, with an owner and an expiry. A permanent silent ignore is how a real risk gets buried.

What about trust and cost?

11. Where does your code go? Does scanning happen locally or in the vendor's cloud, and what is stored? Get the answer in writing.
12. What is the false positive handling? Ask how rules are tuned, and how often the rule set changes. Frequent changes can break a clean build, so check whether you can pin versions.

What are the limits?

Static IaC scanning checks what you declare, not what is running. A resource changed by hand in a console, a drift from the template or a setting applied by another tool will not appear. Pair it with a check of live cloud configuration. It also cannot judge intent: a public bucket may be a deliberate website.

What to do

1. Write your top ten policies in plain words before you demo anything.
2. Build a sample repo with a known bad setting for each one.
3. Run each finalist on that repo and on a real service.
4. Score on coverage, noise, speed, output format and fix guidance.
5. Test suppression and a custom rule.
6. Check data handling and version pinning.
7. Start in the pull request as warnings, then promote selected rules to blocking.

Quick check

Sources

• Terraform CLI: terraform show
• OASIS SARIF 2.1.0 specification
• OWASP Top 10 project page

Last reviewed: 18 October 2026.