Choose an infrastructure as code scanner by matching it to the formats you actually write, checking that it runs in the pull request and in the editor, and testing whether its findings explain the fix and can be suppressed with a reason and an expiry. We rank no vendors, so use this as a checklist.
Infrastructure as code scanning looks for misconfigurations before they reach a cloud account: open storage, wide permissions, missing encryption, public databases. The cheapest place to fix them is the file.
What should the shortlist ask first?
Which formats do you write? List them: Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfiles, Ansible, Pulumi programs. A tool that handles three of your five leaves a blind spot, and Helm templates and programmatic languages are the usual gaps.
Does it evaluate variables and modules? Many risks only show after variables resolve and modules expand. Test with a module that takes inputs from elsewhere.
Where does it run? Editor, pre-commit, pull request and CI each catch different mistakes. The ideal is the same rules in all of them.
What do findings look like? Each one should name the resource, the rule, why it matters and the corrected snippet. Check SARIF output if your platform shows results in code review.
How are rules managed? You will need custom rules for your own conventions. Check the language for writing them and whether policy can be shared across teams.
How does suppression work? A finding you cannot silence with a documented reason gets ignored wholesale. Look for inline suppression with a reason, expiry dates and an audit trail of who approved.
What are honest limits to look for?
Static scanning reads files, not live accounts. It cannot see drift, where someone changed a resource by hand, or resources created outside code. Pair it with a check on running cloud configuration if drift worries you.
It also cannot know your intent. A public bucket may be correct for a website. Good tools let you mark intent with context so the next reviewer knows.
Rule quality varies. Ask how rules are maintained and mapped to benchmarks, and test with your own deliberately bad file.
How do secrets and supply chain fit?
Hardcoded credentials in templates are a classic IaC finding. Check that the tool detects them or integrates with a secrets scanner. Modules and providers pulled from registries are dependencies too, so pinned versions and an inventory of them matter. NIST's Secure Software Development Framework, SP 800-218, is a useful reference for the broader practices around producing well secured software.
As one data point, the Safeguard CLI documentation lists finding hardcoded secrets and misconfigurations under its overview, via the detect command with table, JSON or SARIF output. We describe nothing about IaC format coverage because the docs we read do not say, so test any tool, ours included, on your formats.
How should you run the bake off?
Create a small repository with ten deliberate misconfigurations across your formats, plus a clean one. Run each candidate and count hits, misses and false alarms. Time a run in CI. Try suppressing one finding properly. Read three explanations as a junior engineer would.
What to do
- List the IaC formats and tools in use today, and what you expect to adopt.
- Build a test repository with ten known misconfigurations and a clean twin.
- Run each candidate in editor, pull request and CI.
- Count true findings, misses and false alarms.
- Test variable resolution and a module with inputs.
- Check output formats such as SARIF and the suppression workflow, including expiry.
- Confirm how secrets in templates are handled.
- Decide, and schedule a review in six months.
Quick check
Can an IaC scanner detect configuration drift?
Usually not. It reads code files. Drift appears only when you also check the running cloud configuration.
What matters most in a trial?
Coverage of your own formats and clear, fixable findings. Test with your files, not sample ones.
Sources
- NIST SP 800-218, Secure Software Development Framework, fetched 18 October 2026
- Safeguard CLI, Safeguard Docs, read 18 October 2026
Last reviewed: 18 October 2026.
