cfn_nag defined the job. Context finishes it.
cfn_nag taught a generation of AWS teams to lint CloudFormation for security before deploying it, and that instinct is exactly right. audytx is the next step for the same job: it builds a cross-resource relationship graph first and reasons about your template before it judges it, setting aside many of the findings you used to suppress by hand and printing the reason for each.
Two designs for one job
This is a design comparison, not a benchmark. audytx's own CloudFormation results are on the CloudFormation benchmark.
| Dimension | audytx | cfn_nag |
|---|---|---|
| Approach | cross-resource context reasoning: how resources relate decides which findings are kept | looks for patterns in CloudFormation templates, per its README |
| Findings that do not apply | set aside by context, each printed with its reason | rules_to_suppress entries under Metadata, written per resource |
Conditional resources (Fn::If) | both branches are evaluated; a finding that depends on an unresolved condition is marked conditional | — |
| Terraform + CloudFormation | one engine, the same AWS_* rule ids across both | CloudFormation templates |
| Delivery | hosted MCP server and GitHub App pull-request review | Ruby gem (gem install cfn-nag) |
| Failing the build | the check run and PR comment report findings; audytx does not fail the build | "A failing violation will return a non-zero exit code." |
cfn_nag facts (approach, suppression syntax, packaging, exit code) are from its repository README, checked 2026-10-01. The Fn::If row states audytx's behavior; cfn_nag's is not characterized.
The migration map
What each cfn_nag habit becomes:
| In cfn_nag | In audytx |
|---|---|
W- / F-numbered findings (W9, F27…), CloudFormation-specific | AWS_* rule ids shared with Terraform — one vocabulary if your estate has both |
Metadata → cfn_nag → rules_to_suppress entries with a reason, per resource | many findings are set aside by context with the reason printed; the rest stay reported |
gem install cfn-nag wired into CI | no install: your coding agent or CI calls scan_cloudformation on the hosted MCP server with a free Client ID |
| Non-zero exit on a failing violation, to gate the pipeline | no gate: findings go to the PR comment, the check summary and Code Scanning, and the merge decision stays with the reviewer |
Frequently asked questions
What is the best cfn_nag alternative?
Start from the job cfn_nag was doing for you. For its security-linting job, audytx adds cross-resource reasoning and lists each set-aside finding with its reason. Keep cfn-lint for template validity: per its README it validates templates against the CloudFormation resource provider schemas. One tool across many frameworks is a different job, for a breadth tool such as Checkov.
Does audytx scan CloudFormation today?
Yes. The hosted MCP server has a scan_cloudformation tool (verify on /status: supported_iac lists cloudformation), and the GitHub App reviews CloudFormation pull requests.
Scan your first template in one tool call
Mint a free Client ID, point your agent at the MCP server, and see which of your cfn_nag suppressions the context engine writes for you.