AWS security

AWS security assessment, from the edge and from inside.

Skydra combines unauthenticated edge probes with authenticated inside-account audits. The combination is the point: finding a public S3 bucket is not the same as finding a bucket a privilege-escalation path lets a low-trust role make public.

Create a workspace Compare clouds

IAM path analysis
S3, ECR, Lambda, API Gateway
Edge probes for public resources
Account-scoped audit action

Two complementary surfaces

Edge probes and account audits.

Treat AWS security as one surface and it is impossible to prioritise. Skydra splits the detection into two deliberate sides — what anyone on the internet sees, and what a holder of audit credentials sees. The two find different things, and they correlate.

Outside-in

What an attacker without any credentials sees.

S3 bucket URL patterns — anonymous reads, directory listing, writable buckets
CORS misconfiguration on public buckets
Lambda function URLs with permissive invocation
API Gateway stage exposure
EC2 metadata service via application-side SSRF
CloudFront origin exposure
ECR public repositories, image pull without auth
Dangling S3 buckets (CloudFront origin → claimable subdomain)

Inside-account

What a least-privileged read-only auditor sees.

IAM paths that permit privilege escalation
Long-lived access keys and inactive users
S3 bucket policies: public, cross-account, overly broad
Secrets Manager rotation and resource policies
SNS, SQS, EventBridge: cross-account trust and open subscriptions
CloudTrail: coverage gaps, S3 logging, management-event filtering
SSM parameters: encryption, access policies
DynamoDB streams and resource policies
RDS: public accessibility, snapshot sharing, deletion protection
EC2 security groups: 0.0.0.0/0 on admin ports

Named detectors

Every check is a file in the public action catalog.

Nothing here is a wishlist. Each row below is implemented and lives in packages/actions/src — the same catalog the workspace sees in its Library.

Identity and access

aws.audit_identity
IAM users, roles, groups, access keys, and trust policies
aws.audit_privilege_escalation
IAM paths that let a role elevate privileges
aws.audit_dangling_delegation
Cross-account trust to accounts that no longer exist
aws.access_key_account
Resolve an access key id to its owning account
aws.sensitive_name_disclosure
Account id or role name disclosure in error responses

Storage

aws.audit_s3
S3 bucket policies, ACLs, encryption, logging, public access block
s3.cors
Allowed-origin CORS probe against public buckets
bucket.enumerate
Anonymous listing, well-known paths, writable probe
bucket.cors
Pattern-matched CORS inspection for every supported provider
cdk.bucket
CDK-synthesised buckets with disclosable configuration

Compute and functions

aws.audit_lambda
Lambda resource policy, environment variables, function URLs
lambda.url
Public function URL pattern parse and reachability
aws.audit_api_gateway
API Gateway stages, methods, authorizers
aws.audit_ec2
EC2 security groups, snapshots, AMIs, metadata exposure
aws.audit_cloudfront
Distributions, origin configuration, dangling origins

Observability and secrets

aws.audit_cloudtrail
CloudTrail configuration, S3 log destination, event selectors
aws.audit_secrets_manager
Secret rotation, resource policies, cross-account access
aws.audit_ssm
SSM parameters: encryption, access policies, naming hygiene
aws.audit_sns_sqs_events
SNS/SQS/EventBridge topic policies and subscriptions
aws.audit_cognito
User pool self-registration and sign-in configuration

A representative runbook

From an inventory list to a prioritised finding.

A real workflow a security team schedules against their AWS estate. Each step is a named action in the catalog; data flows from one into the next on typed edges.

daily-aws-posture.runbook (pseudo)

inputs:
  accounts: list<CloudAccount>

steps:
  audit:
    action: aws.audit
    forEach: inputs.accounts
    with: { connection: item.connection }
    produces: Finding[]

  critical:
    refine: filter(audit.output.findings, item.severity in ["critical", "high"])

  bucket_exposure:
    action: bucket.enumerate
    forEach: critical.output.filter(item.resourceKind == "s3.Bucket")
    with: { url: item.resourceUrl }

  notify:
    action: slack.post
    condition: bucket_exposure.output.findings ne []
    with:
      channel: "#security-ops"
      summary: templates.aws_posture_summary.render(bucket_exposure.output)
      runUrl: run.url

Nothing here is Skydra-proprietary vocabulary. aws.audit is one action; a different workspace writes a different runbook around it. The engine, not the catalog, is what makes the combination possible.

What we deliberately do not promise

Honesty about the edges.

Trust in a security tool is proportional to how clearly it names what it does not do. These are the edges where Skydra's AWS coverage is deliberately bounded today.

Skydra does not deploy agents or in-cluster components. All AWS checks run from Skydra infrastructure against the account via the AWS API.
Service-control-policy evaluation is partial — Skydra reports SCP-filtered permissions where the auditor role can read them, and does not run a solver to prove unreachability.
KMS key-usage simulation is limited to resource-policy inspection; cryptographic key rotation claims rely on provider-reported fields.
Compliance-framework mapping (SOC 2, ISO 27001, HIPAA) is not shipped. Skydra produces evidence, severity, and remediation — not framework-specific pass/fail scorecards.
Cost analysis is out of scope. Skydra audits security configuration, not spend.

See it against your own AWS estate.

Scope policy keeps probing actions off any account you have not added. Clone the AWS posture starter runbook, point it at a sandbox account, and inspect the finding evidence.

Create a workspace See Azure coverage