Amazon Web Services

Your AWS accounts, checked read-only and fixed in code.

ACSE runs 74 checks across the AWS services your workloads depend on, from S3 and IAM to EKS and CloudTrail. It shows which findings sit on a path from the internet to your data, and it turns the fix into a pull request against your own Terraform.

Talk to us See how it works

Know what is exposed first

Risk paths link a load balancer to the instance or function behind it, the role it assumes and the data that role can reach, so the exposed finding rises to the top.

Grant nothing you would not show an auditor

One read-only role per account, trusted only by your own runtime, with an external id you choose and keep in your own account.

Close findings without a ticket chain

Common S3 findings arrive as a validated draft pull request in your Terraform. Others come with an exact runbook.

What the checks cover

74 checks where AWS mistakes happen

Each check reads only the settings it needs, through read-only Get, List and Describe calls. None reads object contents, secret values or credentials.

Storage and databases

S3 Block Public Access at account and bucket level, default encryption, versioning, TLS-only policies, MFA delete and access logging. EBS, EFS and RDS encryption, public snapshots and public RDS instances.

Identity

Root user MFA and access keys, console MFA, key rotation and unused keys, password policy, full administrator policies, directly attached user policies and IAM Access Analyzer.

Network

Security groups and network ACLs open to administration or database ports, the default security group, VPC flow logs and load balancer listeners that are not HTTPS.

Compute and containers

IMDSv2 on EC2, public IPs, EKS endpoint exposure, audit logging and secrets encryption, ECS services with public IPs and Container Insights.

Serverless

Lambda function URLs and resource policies that let anyone invoke a function.

Logging and keys

CloudTrail in every region with log validation and KMS encryption, S3 data events, the CloudWatch alarms CIS recommends, AWS Config, GuardDuty, Security Hub and KMS key rotation.

Risk paths

See the path, not just the finding

A security group open to the internet matters more when it fronts an instance whose role can read a sensitive bucket. ACSE links those resources and scores the path from internet entry to data.

Paths follow the links ACSE establishes between resources: a load balancer targeting an instance or a function, the role that instance or function assumes, and what that role can access.

Paths scored and ranked, top 50 shown
Each step names the weakness that opens it
Fix one link and the path closes

Connect an account

One read-only role, trusted only by you

ACSE generates a CloudFormation template, or an equivalent Terraform module, for a role named ACSEReadOnlyScanner in each account in scope. Its trust policy names only your own ACSE runtime.

You choose the external id and store it in your runtime’s account. ACSE carries only a reference to it, never the value. For an AWS Organization, you name the accounts to scan.

Choose the cloud and the scopeIn Setup › Connect cloud, a Tenant Admin picks the provider and what to cover. ACSE lists every permission it will need and who in your team can grant them, before anything is created.
Run the generated setup in your cloudACSE generates a read-only setup bound to your tenant’s own runtime identity. Your team reviews and runs it. ACSE never runs it for you and never sees a key.
Test the connection and confirm with MFATest connection checks every permission and reports exactly what is missing. The Tenant Admin confirms with MFA, and the connection settings are recorded on your evidence chain.

Scope

One account, or every account in an AWS Organization or organizational unit.

What the setup creates

A read-only role, ACSEReadOnlyScanner, in each account in scope
A trust policy that lets only your own ACSE runtime assume it
A permissions boundary, so the role can never gain write access

Read-only by design. ACSE delivers fixes as pull requests to your code, so the connection never needs write access to your cloud.

Framework coverage on AWS

How many controls have a check behind them

Counts of the controls ACSE lists for each framework that at least one AWS check evaluates. The rest show as manual controls, beside the score.

CIS AWS Foundations 3.0.0: 51 of 62 recommendations
PCI DSS 4.0.1: 21 of 48 tracked requirements
NIST SP 800-53 Rev. 5: 24 of 45 tracked controls
FedRAMP Moderate: 24 of 45 tracked controls
CCCS Medium: 24 of 45 tracked controls
SOC 2: 8 of 38 tracked criteria
ISO/IEC 27001:2022: 12 of 93 Annex A controls

Questions

What people ask us

Does ACSE need AWS access keys?

No. Your runtime assumes the read-only role through its own task identity. There are no long-lived keys to issue, store or rotate.

Where does ACSE run on AWS?

The ACSE runtime runs in your AWS account. It opens every connection outbound, so nothing listens in your account, and it writes evidence to an S3 bucket under Object Lock that you own.

Which AWS fixes come as pull requests?

Fixes for public S3 buckets, default encryption, versioning and a growing set of other checks arrive as draft pull requests in Terraform on GitHub, validated with an offline plan before review. For other findings, ACSE gives the exact read-only checks and commands for a person to run.

What does the role let ACSE read?

Exactly the actions in the AWS pack’s published permission list, all of them Get, List or Describe. A permissions boundary keeps the role from ever gaining write access.

Keep reading

Platform

Talk to us

See ACSE on your cloud.

Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.

Talk to us Explore the platform