audytx features: Terraform and CloudFormation security checks for AWS

Review time

How it shows up in a PR

A summary comment on the pull request each time it is scanned.

The audytx comment on a GitHub pull request: one high and one medium finding, one cost opportunity, and 26 findings reasoned away by context. — Captured on GitHub, 2026-09-08: the comment on a testbed pull request importing terraform-aws-modules/terraform-aws-rds (Apache-2.0). Two findings kept, 26 reasoned away.

An audytx inline review comment on the pull request diff: a plaintext Directory Service password, with a Terraform fix that generates the password and stores it in Secrets Manager. — The same pull request, Files changed tab: the finding lands on the line that introduced it, with the fix ready to paste.

One-click fixes

Line-anchored findings post as GitHub suggestions. A fix that can't be applied cleanly isn't offered.

Reasoning shown, never hidden

Suppressed findings are listed in the scan output with their check, resource, and the reason.

SARIF → Code Scanning

The same findings land in GitHub's Security tab, and suppressed findings are marked in the SARIF.

Code time · MCP

For the agents writing your infrastructure

The same engine over MCP, before the PR exists. Free with a Client ID.

POST /mcp · connect any MCP client

claude mcp add --transport http audytx https://audytx.com/mcp \
  --header "X-Client-ID: YOUR_CLIENT_ID"

`scan_terraform` · `scan_cloudformation`

Findings with file and line, severity, and a fix snippet. CloudFormation covers JSON, YAML, SAM, and CDK output.

`autofix_terraform` · `autofix_cloudformation`

Applies the sound fixes, re-scans, and loops up to three passes. Dry-run variants of both.

Plan-enhanced scans

Opt in with terraform show -json or DescribeChangeSet output to resolve variables, count, and for_each.

IAM attack paths

IAM privilege-escalation paths

Finds multi-step IAM privilege-escalation paths.

31 / 31 privesc paths on iam-vulnerable · engine 1.18.276 · 2026-08-07

See the benchmark →

Secrets detection

Hardcoded credentials, found by format

Most secret checks match the format of a credential, and known password fields are checked by name. None of them score how random a string looks.

Known formats

AWS access key IDs, private key headers, GitHub tokens, and other well-known API-token formats.

Where it looks

Resource attributes in Terraform and CloudFormation, Terraform variable defaults, .tfvars files and output values, and CloudFormation Outputs values.

Password fields and provider blocks

A literal in a known password or auth-token argument, and a credential-shaped access_key or secret_key in the AWS provider block.

References are not literals

A reference with no literal behind it, such as var.db_password with no default, is not reported. A separate check reports an output that publishes a credential AWS generates, such as a new access key's secret.

The reasoning layer

The reasoning engine

33 reasoning axes look at the surrounding resources before a finding is reported.

The audytx console Findings tab: kept findings by severity, the rules that fired most, and the findings reasoned away with the reason for each. — The console keeps score: what fired, what was reasoned away, and why.

Each axis, in one line.

network_acl_pathTakes into account whether attached network access controls block database traffic.

subnet_route_pathTakes into account whether a database's subnets have a route to the internet.

ecr_registry_scanningTakes into account how the registry scans repository images.

restore_inheritanceTakes into account where restored database encryption comes from.

lambda_invocation_graphTakes into account how a Lambda function is invoked.

sqs_dlq_identityTakes into account the role a queue plays.

encryption_variantsTakes into account how a resource is encrypted at rest.

iam_policy_riskTakes into account what access an IAM role or user actually holds.

iam_trust_graphTakes into account who can actually assume an IAM role.

deletion_guardTakes into account whether a resource is protected against deletion.

disabled_resource_countTakes into account whether the code creates a resource at all.

module_synthesized_inputTakes into account where the settings of a module call come from.

tag_environmentTakes into account the environment a resource belongs to.

imdsv2_enforcementTakes into account where instance metadata settings come from.

ecs_module_templateTakes into account whether a container task is a reusable module template.

lambda_module_templateTakes into account whether a Lambda function is a reusable module template.

sqs_module_templateTakes into account whether a queue is a reusable module template.

eventbridge_external_lambdaTakes into account where the function an event rule triggers is defined.

secret_rotationTakes into account whether a secret is rotated automatically.

rcp_data_perimeterTakes into account organization policies that limit who can access a resource.

ec2_declarative_policyTakes into account organization-wide settings that apply to new instances.

scp_deny_guardrailTakes into account organization policies that limit what an identity can do.

dynamic_referenceTakes into account where a credential value comes from.

cdk_bootstrapTakes into account whether a resource belongs to the tooling CDK itself uses.

rds_instance_relationshipTakes into account how a database instance relates to its cluster or source.

rds_iops_authorshipTakes into account where a database's provisioned performance settings come from.

firehose_source_encryptedTakes into account where a delivery stream gets its data from.

module_output_wiringTakes into account how values are passed between modules.

elasticache_global_datastoreTakes into account how a regional cache relates to its global datastore.

upstream_cdn_edgeTakes into account whether a CDN sits in front of a resource.

ecs_exec_log_routeTakes into account where interactive container shell sessions are logged.

lambda_package_typeTakes into account how a function's code is packaged for deployment.

lambda_failure_destinationTakes into account where a function sends the record of a failed asynchronous event.

Free plan

Start free

The Free plan includes 100 scans a month, on public and private repos.

Install the GitHub App Read the docs

Deliberate scope limits

Not yet (and why)

The questions we get asked most, answered. Going deep on AWS is the strategy, and we intend to keep it.

Does audytx support multi-cloud (Azure or GCP)?

No — AWS only, by design, in both Terraform and CloudFormation.

Does audytx support CloudFormation, Pulumi, or CDK?

CloudFormation: yes — live on the hosted MCP server (JSON, YAML including short tags, SAM, CDK-synthesized output) and in GitHub App pull-request review, with the Terraform AWS_* rule ids plus a few CloudFormation-only ones. CDK: covered — point audytx at the synthesized templates in cdk.out. Pulumi: no — the strategy is still depth over breadth, one stack at a time.

Does audytx open auto-remediation pull requests on arbitrary infrastructure?

No. audytx shows the fix and applies the sound ones as one-click suggestions or through the autofix loop. We don't open fix PRs on infrastructure we've never seen deployed — that's a level of trust a scanner has to earn, and we'd rather show you the change first.

Does audytx enforce org policies, merge gates, or compliance export?

Not yet. audytx reviews and flags pull requests; it never blocks a merge. A governance layer (block-on-Critical, cross-repo baselines, CIS or SOC 2 evidence) is planned, but we want real org usage to shape it before we build it.

Does audytx offer SAML SSO or SOC 2 certification?

No. SAML SSO and SOC 2 certification are not available yet.