CloudFormation support is live on the MCP server
scan_cloudformation MCP tool. Templates are normalized into the same resource
model the Terraform engine reasons about, so findings carry the same
AWS_* rule ids, the same context suppression runs, and the response
shape is identical to scan_terraform. MCP first; GitHub App and CLI next.
One engine, now two languages
audytx has been a context-aware AWS Terraform reviewer since day one. As of engine v1.17, the parser front-end also reads CloudFormation and maps each template into the same resource vocabulary the rules and reasoning axes already understand — AWS::S3::Bucket lands where aws_s3_bucket does, before a single rule runs.
That one design decision carries the whole release:
- Same rule ids. A finding on a stack template has the id, severity, and remediation text it would have on Terraform. Mixed estates get one findings vocabulary, not two.
- Same context layer. The relationship graph — invocation edges, DLQ identity, IAM trust, exposure — is built from the normalized stack, and the false-positive suppression that graph powers runs unchanged, each suppression printed with its rationale.
- Same response shape.
scan_cloudformationreusesscan_terraform's implementation core, so agents consume both results with identical code.
Reading the template language properly
CloudFormation's intrinsic functions are a language, and a scanner that half-reads them manufactures false positives. The front-end ships with a real evaluator: YAML short tags (!Ref, !GetAtt, !Sub, !If), Fn::ForEach expansion, and symbolic tracking for ARNs that only exist at deploy time.
The case we sweated most is Fn::If. When a security-relevant attribute depends on a condition the template alone can't resolve, audytx evaluates both branches. If they disagree, the finding is downgraded one severity step, marked conditional, and annotated with why. It isn't dropped, and it isn't stated with more confidence than the template supports.
Behind the release sits a CloudFormation ground-truth corpus: every context axis is exercised by CFN-specific positive and negative suites plus a benign-template set — the same zero-false-positive discipline the Terraform engine is held to.
One tool call
# Register audytx with your agent (Claude Code shown), then ask it to scan — # or call the tool directly: curl -s https://audytx.com/mcp \ -H 'Content-Type: application/json' -H 'X-Client-ID: YOUR_CLIENT_ID' \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{ "name":"scan_cloudformation", "arguments":{"files":[{"path":"stack.yaml","content":"..."}]}}}'
Client IDs are free at the dashboard, and CloudFormation calls share your existing MCP quota — no new metering. Templates are parsed in memory and discarded per request, like every audytx scan.
What this release is not, yet
- The GitHub App and offline CLI scanned Terraform only at launch. MCP shipped first because coding agents are where new CloudFormation increasingly comes from, and the agent that wrote the template is in the best position to act on its findings. PR review and CLI support are the next surfaces. Update: shipped since — the GitHub App now reviews CloudFormation pull requests (templates changed in a PR are sniff-detected and get the same one-comment review and SARIF upload); the offline CLI still scans Terraform only.
- SAM's
AWS::Serverless::*resources parse but aren't expanded into checkable resources yet, so rules don't fire on them — and the scan result says so instead of reporting a silent clean. Update: shipped since — SAM resources are now expanded into the CloudFormation resources the transform would generate (auto-created IAM roles, event-source mappings, API stages) and scanned with the same rules, includingGlobals-section merge; the remaining gap is templates that configure an implicit API throughGlobals, which still defer with a warning. - No change-set enrichment yet — the CFN analogue of Terraform's plan upload is future work. Update: shipped since — a CI workflow can now POST
DescribeChangeSetoutput to/changeset-upload(OIDC-authenticated, mirroring plan upload) and the pull-request scan re-runs with resolved values. - No CloudFormation benchmark numbers yet. Our published precision and recall figures are Terraform-corpus results, and we won't relabel them. CFN gets its own measured numbers when the corpus work is done. Update: shipped since — the CloudFormation benchmark measures audytx against Checkov, Trivy, and KICS on three real public CloudFormation corpora with a pinned-SHA, reproducible methodology (no live-SARIF mixing, no relabeled Terraform numbers).
supported_iac live, and the MCP tools/list is open without auth. When the GitHub App surface lands, those are the places it will show first. Coming from cfn_nag? The migration page maps its W/F ids and suppression workflow onto audytx.Scan a stack template today
Point your coding agent at the MCP server and see the context engine read your CloudFormation — free during the beta.