DEV Community: Bala Paranj

What SCPs Can't Verify, Snapshots Can

Bala Paranj — Tue, 06 Oct 2026 13:03:41 +0000

Can an SCP require EKS clusters to use customer-managed KMS keys?

No. Because the information the SCP needs doesn't exist in the place the SCP can look.

The request context is incomplete

What happens when someone creates an EKS cluster with encryption:

aws eks create-cluster \
  --name production \
  --encryption-config '[{
    "provider": {
      "keyArn": "arn:aws:kms:us-east-1:123456789012:key/abc-123"
    },
    "resources": ["secrets"]
  }]' \
  ...

The SCP sees this request context. It can evaluate:

The action: eks:CreateCluster
The key ARN: arn:aws:kms:us-east-1:123456789012:key/abc-123
The condition key: eks:encryptionConfigProviderKeyArns

The SCP can deny if no key ARN is provided. That's straightforward:

{
  "Sid": "DenyEKSWithoutEncryptionKey",
  "Effect": "Deny",
  "Action": "eks:CreateCluster",
  "Resource": "*",
  "Condition": {
    "Null": {
      "eks:encryptionConfigProviderKeyArns": "true"
    }
  }
}

But can the SCP deny if the provided key is AWS-managed instead of customer-managed?

No.

Look at the key ARN: arn:aws:kms:us-east-1:123456789012:key/abc-123. It's a string. There's nothing in the ARN that says "customer-managed" or "AWS-managed." Both types have identical ARN formats. The distinction lives in the KMS key's metadata. Specifically the KeyManager field which is stored on the key object in KMS, not in the request to create an EKS cluster.

The SCP evaluates the request. The answer is in the key's metadata. The SCP can't cross that boundary.

The workaround is a governance band-aid

The community's best workaround: enforce a naming convention on key aliases, then write an SCP that denies if the key alias doesn't match the convention.

{
  "Sid": "DenyGrantOnAWSManagedEKSKey",
  "Effect": "Deny",
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "eks.us-east-1.amazonaws.com"
    },
    "ForAnyValue:StringLike": {
      "kms:ResourceAliases": "alias/aws/eks"
    }
  }
}

This blocks the AWS-managed key specifically (alias/aws/eks). It works for the narrow case of blocking the default AWS-managed key.

But it doesn't prove the key that is used is customer-managed. It proves the key isn't the specific AWS-managed key with the alias/aws/eks alias. If someone creates a key with a different alias, or no alias, or an alias that matches your naming convention but is an AWS-managed key from another service, the SCP passes it through.

The workaround works when everyone follows the naming convention. "When everyone follows the convention" is the security equivalent of "when everyone remembers to lock the door." It's the same rubber-stamping pattern SOC 2 auditors keep catching. The control looks correct on paper, the underlying property isn't verified.

The snapshot contains the truth

Here's what the KMS key looks like in a configuration snapshot, the actual key object:

{
  "KeyId": "arn:aws:kms:us-east-1:123456789012:key/abc-123",
  "KeyManager": "CUSTOMER",
  "Origin": "AWS_KMS",
  "KeyState": "Enabled",
  "KeyUsage": "ENCRYPT_DECRYPT",
  "Description": "EKS secrets envelope encryption",
  "CreationDate": "2025-03-15T10:30:00Z",
  "Enabled": true
}

Here's the EKS cluster's encryption configuration in the same snapshot:

{
  "ClusterName": "production",
  "EncryptionConfig": [
    {
      "Provider": {
        "KeyArn": "arn:aws:kms:us-east-1:123456789012:key/abc-123"
      },
      "Resources": ["secrets"]
    }
  ],
  "Status": "ACTIVE"
}

The KeyManager field is right there. "CUSTOMER" or "AWS". Binary. No naming convention needed. No alias enforcement or workaround. The snapshot contains the truth about the key — not the request's claim about the key, but the key's own metadata.

A snapshot-based verification tool joins the two:

Read the EKS cluster's EncryptionConfig.Provider.KeyArn
Look up that ARN in the KMS key inventory
Check KeyManager == "CUSTOMER"
If KeyManager == "AWS": FAIL
If KeyManager == "CUSTOMER": PASS
If no EncryptionConfig at all: FAIL (no encryption configured)
If the key ARN doesn't resolve (key deleted, cross-account, or missing from snapshot): FAIL (can't verify — fail loud, don't assume)

Deterministic. Same answer every time. No convention to follow or alias to enforce. The property is verified against the configuration state, not inferred from the request.

Why this gap is structural, not accidental

The SCP limitation isn't a bug. It's a consequence of where SCPs operate in the architecture.

SCPs evaluate request context at API call time. The request context contains what the caller sent. The action, resource ARN, tags the caller attached and the condition keys AWS defined for that API. It does not contain the metadata of resources the request references. When you create an EKS cluster and specify a KMS key ARN, the SCP sees the ARN string. It does not query KMS to check what kind of key that ARN points to. That cross-service metadata lookup doesn't happen during policy evaluation.

This is by design. SCPs need to evaluate in microseconds. A cross-service lookup (call KMS to check KeyManager for every key ARN in every request) would add latency, create circular dependencies, and introduce failure modes. AWS made the right engineering decision. The SCP evaluates what's in front of it, fast.

But that means any property that requires joining data from two services such as the EKS cluster's encryption config AND the KMS key's metadata is structurally invisible to the SCP. The SCP can see either one in isolation. It can't join them.

A configuration snapshot can. The snapshot contains both services' configuration at the same point in time. The join is a lookup, not a cross-service API call. The EKS cluster says "I use key ARN X." The KMS inventory says "key ARN X has KeyManager: AWS." The verification engine reads both and produces the verdict.

The pattern generalizes

EKS encryption is one instance. The same structural gap applies anywhere a preventive policy needs to verify a property that lives in a different service's metadata:

S3 bucket encryption — is the KMS key customer-managed or AWS-managed?
RDS encryption — same question for database encryption keys
EBS volume encryption — is the default EBS encryption key a CMK?
Lambda function environment encryption — is the KMS key attached to the function a CMK?
Secrets Manager encryption — is the secret encrypted with a CMK or the default aws/secretsmanager key?
SQS/SNS encryption — is the queue/topic using a CMK?

Every one of these requires joining the resource's configuration with the KMS key's metadata. Every one of these is invisible to an SCP for the same structural reason. Every one of these is a deterministic check against a configuration snapshot.

The pattern: SCPs verify properties within the request context. Snapshots verify properties across the configuration graph. Both are needed. SCPs prevent. They block requests that violate policy. Snapshots verify. They prove the configuration satisfies the property after deployment. The SCP catches the violation at creation time (when it can see enough to evaluate). The snapshot catches the violation at any time (because it can see everything).

The gap between prevention and verification

Most organizations treat SCPs as the security mechanism and stop there. "We have an SCP that requires encryption keys." The property they think they've verified: EKS clusters use customer-managed keys. The property they've verified: EKS clusters provide a key ARN. Whether that key ARN points to a customer-managed key is unverified. Because the SCP structurally can't check it.

This is the gap between prevention and verification. Prevention says "I blocked the bad request." Verification says "the resulting configuration satisfies the property." Prevention operates at request time with partial context. Verification operates on the full configuration with complete context. Prevention is necessary. Verification proves the property holds.

Stave is an open-source tool that verifies cloud configuration against declared invariants using three formal reasoning engines (CEL, Z3, Soufflé). It reads configuration snapshots without any credentials and joins data across services to verify properties that per-service or per-request controls structurally cannot see. The EKS/KMS check described above is one of 3,000+ controls in the catalog.

An AWS library stored SQS payloads in S3 without encryption for 4 years and nobody's tooling caught it

Bala Paranj — Mon, 05 Oct 2026 12:15:27 +0000

In June 2016, a user reported about the Amazon SQS Extended Client Library. It is an official AWS library that stored large SQS message payloads in S3 without server-side encryption.

The question: "the messages stored in S3 do not have encryption turned on. For the best HIPAA compliance, I think they should be?"

The issue sat open for 4 years. It was resolved in July 2020 with version 1.1.0, which added SSE-KMS support.

Why this matters

The SQS Extended Client Library is used when message payloads exceed the 256KB SQS limit. The library transparently stores the payload in S3 and sends a pointer via SQS. The consuming application retrieves the payload from S3.

If those payloads contain PHI such as patient records, diagnostic results, insurance claims, they're stored unencrypted in S3. This violates HIPAA §164.312(a)(2)(iv) (encryption and decryption) regardless of how the SQS queue itself is configured.

The problem is invisible to most tooling because:

The bucket exists but isn't in any IaC template. The library creates or uses a bucket programmatically. CloudFormation linters like cfn_nag never see it.
AWS Config checks the bucket, not the application. Config's S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED rule would flag the bucket but only if Config is enabled, and the finding has no context that the bucket stores SQS message payloads containing PHI.
No duration tracking. Even if a tool flagged the missing encryption, nobody tracked how long the bucket was non-compliant. The answer: 4 years.

What Stave detects

Missing encryption at rest

# CTL.S3.ENCRYPT.001
unsafe_predicate:
  all:
    - field: properties.storage.kind
      op: eq
      value: bucket
    - field: properties.storage.encryption.at_rest_enabled
      op: eq
      value: false

Stave's CTL.S3.ENCRYPT.001 fires immediately when the extractor captures a bucket without server-side encryption. The finding includes the HIPAA citation:

[FAIL] CONTROLS.001 — high
Compliance: §164.312(a)(2)(iv) — Encryption and Decryption
Finding: Bucket sqs-extended-payloads: server-side encryption is not enabled

Missing KMS customer-managed key

Even after enabling SSE, if the bucket uses the AWS-managed key (alias/aws/s3), Stave's CONTROLS.001.STRICT fires:

[FAIL] CONTROLS.001.STRICT — critical
Compliance: §164.312(a)(2)(iv) — CMK required for key revocation
Finding: SSE-KMS uses the AWS-managed key. CMK required for breach
response — AWS-managed keys cannot be revoked by the customer.

The AWS-managed key cannot be disabled during a breach. A customer-managed key can be immediately revoked, rendering all encrypted objects unreadable. For PHI, this distinction is the difference between containment and exposure.

Duration tracking

Finding: sqs-extended-payloads
  First unsafe: 2016-06-15T00:00:00Z
  Last seen:    2020-07-29T00:00:00Z
  Duration:     36,000+ hours (threshold: 168 hours)

4 years of non-compliance. 36,000 hours past the 168-hour SLA threshold. No other tool surfaces this. They report "non-compliant right now" without temporal context.

Compound risk: unencrypted + data classification

If the bucket is tagged data-classification: phi (as it should be for SQS payloads containing patient data), Stave's CTL.S3.ENCRYPT.004 escalates:

[FAIL] CTL.S3.ENCRYPT.004 — high
Sensitive Data Requires KMS Encryption
Finding: Bucket tagged "phi" uses AES256, not SSE-KMS with CMK

The classification tag becomes evidence. The organization's own metadata proves the data is sensitive while the encryption is insufficient.

The deeper problem: application-created buckets

This case exposes a gap in infrastructure security that most tools miss: buckets created by application libraries, not by infrastructure teams.

The SQS Extended Client Library creates or references a bucket at runtime. This bucket:

Doesn't appear in CloudFormation or Terraform
Isn't in the infrastructure team's inventory
May not have the organization's standard bucket policy
May not have encryption, logging, or Public Access Block

These shadow buckets are everywhere. They are created by AWS SDKs, CI/CD tools, log aggregators, backup solutions, and application frameworks. They inherit whatever defaults the library uses, not the organization's security baseline.

Stave catches them because it evaluates observed state. Whatever buckets exist in the AWS account, regardless of how they were created. The extractor captures all buckets. The controls evaluate all of them.

The timeline problem

The most damaging aspect of this case is the 4-year gap between discovery and fix.

June 2016: User reports the issue
2016-2018: Community discussion, feature requests
July 2020: Fixed in version 1.1.0

During those 4 years, every organization using this library with PHI payloads was non-compliant. No tool tracked the duration. No tool escalated based on how long the gap persisted.

Stave's duration tracking turns this from "we have a finding" into "we have a finding that has been open for 36,000 hours past the SLA." That temporal evidence changes the conversation with auditors, management, and regulators.

What this means for HIPAA programs

Audit application-created buckets, not just IaC-managed ones. Libraries create S3 buckets that your infrastructure tools don't see.
Track duration, not just state. A 4-year compliance gap is categorically different from a 4-hour one. Duration is the missing dimension in most compliance programs.
Require CMK, not just "encryption enabled." The AWS-managed key is a false sense of security for breach response. HIPAA's encryption requirement should be interpreted as "encryption you can revoke."
Evaluate observed state. Template scanning catches what you intend to deploy. State evaluation catches what actually exists — including the buckets nobody intended to create.

This is implemented in Stave, an open-source cloud security platform. The kernel evaluates predicates. The YAML encodes the domain insight. Try it: bash examples/demo-ai-security/run.sh

"Our auditor wants proof of S3 compliance, what do we give them?" Automating HIPAA S3 evidence for your auditor

Bala Paranj — Sun, 04 Oct 2026 12:35:16 +0000

The Reddit Question

The thread on r/aws: "Our auditor wants proof of S3 HIPAA compliance. We have AWS Config and SecurityHub, but they want something more structured. What do we give them?"

The usual answers such as console screenshots, CSV exports, GRC platform PDFs are not what auditors need.

What Auditors Want

Auditors want evidence: deterministic, reproducible artifacts traceable to specific HIPAA requirements.

What was evaluated — which controls, mapped to which HIPAA sections
When it was evaluated — a timestamp for the compliance period
What the result was — COMPLIANT, NON_COMPLIANT, or AT_RISK with findings
That the evaluation is repeatable — same inputs, same output

How Stave Produces Evidence

Stave produces deterministic, machine-readable compliance evidence with HIPAA section citations in every finding:

stave evaluate \
  --controls controls/s3/ \
  --observations observations/ \
  --eval-time 2026-04-08T00:00:00Z \
  --format json

The JSON output follows the out.v0.1 schema:

{
  "schema": "out.v0.1",
  "evaluated_at": "2026-04-08T00:00:00Z",
  "summary": {
    "total_controls": 12,
    "total_assets": 5,
    "compliant": 4,
    "non_compliant": 1
  },
  "security_state": "NON_COMPLIANT",
  "findings": [
    {
      "asset": "phi-reports-bucket",
      "control": "CTL.S3.PRESIGNED.001",
      "severity": "MEDIUM",
      "status": "UNSAFE",
      "compliance": {
        "hipaa": "164.312(a)(1)"
      },
      "message": "Presigned URL access unrestricted",
      "remediation": "Add s3:signatureAge or s3:authType condition"
    }
  ],
  "risk_signals": [
    {
      "asset": "phi-logs-bucket",
      "control": "CTL.S3.LOCK.003",
      "signal": "approaching-threshold",
      "detail": "Retention period 2200 days, minimum 2190 days"
    }
  ]
}

Every finding includes the HIPAA section citation. The auditor can trace each finding to the regulatory requirement it maps to.

CI Pipeline Integration

The real power is running Stave in CI on every deployment. Exit codes make this straightforward:

# .github/workflows/hipaa-compliance.yml
name: HIPAA S3 Compliance Check
on:
  push:
    paths:
      - 'terraform/s3/**'
      - 'observations/**'

jobs:
  compliance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Stave
        run: cd stave && make build

      - name: Evaluate S3 compliance
        run: |
          stave evaluate \
            --controls controls/s3/ \
            --observations observations/ \
            --eval-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
            --format json \
            > compliance-report.json

      - name: Upload evidence artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: hipaa-compliance-${{ github.sha }}
          path: compliance-report.json
          retention-days: 2190  # 6 years per HIPAA

Exit codes drive the pipeline:

Exit Code	Meaning	Pipeline Action
0	All controls pass	Deploy proceeds
3	Violations found	Deploy blocked
2	Input error	Pipeline fails, investigate
4	Internal error	Pipeline fails, investigate

Every CI run produces a compliance artifact tied to a specific commit SHA. Over time, this creates a continuous compliance trail of evidence for every deployment.

Stop giving auditors screenshots. Give them JSON reports with HIPAA section citations, produced by a deterministic tool, run on every deployment, stored as build artifacts with 6-year retention. Stave makes compliance evidence a CI artifact that is reproducible, traceable, and machine-readable. When the auditor asks "prove this bucket was compliant on March 15th," you pull the artifact from that date's deployment and hand them the JSON.

How this relates to existing compliance mods

For the HIPAA dashboard the auditor will recognize on sight — control-family layout, pass/fail per requirement, framework section labels matching their workpaper — turbot/steampipe-mod-aws-compliance ships a dedicated HIPAA Security Rule benchmark with the framework's section IDs already mapped to controls. That's the auditor-facing dashboard half of the evidence story. The snapshot-anchored, commit-SHA-tied, 6-year-retention CI artifact this article describes is the machine-readable proof half — deterministic JSON the auditor can re-run, not a dashboard screenshot they have to take on faith. Both halves serve the same auditor; both halves should ship in the same compliance pipeline. Framework benchmark on the dashboard surface for recognizability, snapshot-anchored verdicts in the artifact store for reproducibility. The two-tool decision matrix: aws-compliance-mod.

Your Lambda Has Admin on S3 and Doesn't Know It

Bala Paranj — Sat, 03 Oct 2026 12:14:22 +0000

The Lambda function reads one file from one bucket. The policy attached to its execution role looks like this:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:111122223333:*"
    }
  ]
}

The CloudWatch Logs statement is correctly scoped with three specific actions on the account's log-group ARN namespace. The developer who wrote this policy knows how to scope a permission set. They wrote the second statement deliberately.

The first statement is "this works, ship it" reflex. s3:* on * is the policy that requires the least time to write and the least time to debug; the function doesn't fail on permission errors during local testing; nobody asks "what S3 actions does this code call?" before merge.

The Capital One breach was this configuration plus an SSRF on a publicly-reachable web application. The SSRF reached the EC2 metadata endpoint, retrieved temporary credentials for the role attached to the running compute, and used those credentials' s3:* grant to read 100 million records from buckets the application never intended to touch.

What `s3:*` Grants

The S3 service has more than 100 actions. Most teams only think about a handful:

s3:GetObject — read.
s3:PutObject — write.
s3:ListBucket — list.
s3:DeleteObject — delete.

s3:* admits all of those, plus all of these:

Action	What it does
`s3:PutBucketPolicy`	Replace the bucket's policy. One call makes any bucket public.
`s3:PutBucketAcl`	Grant the canonical `AllUsers` ACL. Same outcome through a different door.
`s3:DeletePublicAccessBlock`	Remove the safety net so the next misconfiguration sticks.
`s3:PutBucketReplication`	Configure replication of every new object to an attacker-owned bucket in another account.
`s3:DeleteBucket`	Delete the bucket. Forensic logs in the bucket vanish.
`s3:GetBucketLogging`	Read which buckets have access logging configured.
`s3:PutBucketLogging`	Disable bucket access logging silently.

A function that calls s3:GetObject once gets every one of these on every bucket the account owns. The Lambda's control plane is now an attack surface for the entire account's S3 footprint.

The System Invariant

In Stave's observation schema, the engine pre-computes a boolean by walking each role's attached policy statements:

{
  "id": "arn:aws:iam::111122223333:role/DataProcessorLambdaRole",
  "type": "aws_iam_role",
  "properties": {
    "identity": {
      "kind": "role",
      "trusted_services": ["lambda.amazonaws.com"],
      "policies": {
        "has_resource_wildcard_on_sensitive": true,
        "attached_policies": [
          {
            "name": "DataProcessorBroadPolicy",
            "statements": [
              {"Effect": "Allow", "Action": "s3:*", "Resource": "*"},
              {"Effect": "Allow", "Action": ["logs:..."], "Resource": "arn:aws:logs:..."}
            ]
          }
        ]
      }
    }
  }
}

has_resource_wildcard_on_sensitive is the engine's verdict; attached_policies[].statements carries the evidence. CEL reads the boolean to fire the control. Z3 reads the statements to enumerate the specific dangerous calls the wildcard admits.

The Stave Control

id: CTL.IAM.POLICY.RESOURCE.WILDCARD.001
name: Sensitive Actions Must Not Use Resource Wildcard
severity: high
unsafe_predicate:
  all:
    - field: properties.identity.policies.has_resource_wildcard_on_sensitive
      op: eq
      value: true

One leaf clause. The engine has already done the work of deciding whether any of the role's statements pair a sensitive action with Resource: "*". CEL's job is to report it.

Why CEL is Not Enough

The customer reading the finding sees:

…and asks the follow-up:

CEL evaluates a state predicate. It does not enumerate the admitted action × resource set. The risk of s3:* on * is not "your policy is broad". It is "your role can do these specific dangerous things on these specific sensitive resources."

The Z3 Witness Model

The companion program at stave/examples/iam-overpermission-wildcard/z3prove/ walks the role's policy statements and encodes:

0 = (s3:GetObject,        app-data-production/input/file.csv)    intended
1 = (s3:PutObject,        app-data-production/output/result.json) intended
2 = (s3:PutBucketPolicy,  customer-pii-bucket)                   DANGEROUS
3 = (s3:DeleteObject,     billing-archives/jan-2026.csv)         DANGEROUS
4 = (s3:PutBucketAcl,     audit-logs-bucket)                     DANGEROUS

The Go side computes which witnesses each Allow statement admits s3:* matches every s3:Foo action; Resource: "*" matches every ARN and feeds the admitted-set boolean to Z3. The solver then discharges:

unsafe = admitted ∧ dangerous ∧ ¬intended

Output for the broad policy:

=== before (s3:* on *) ===
  policy statements: 2
    [0] Effect=Allow Action=s3:* Resource=*
    [1] Effect=Allow Action=[logs:CreateLogGroup logs:CreateLogStream logs:PutLogEvents] Resource=arn:aws:logs:us-east-1:111122223333:*
  admitted requests: 5 / 5
  intended scope:    [s3:GetObject → app-data-production/input/file.csv
                      s3:PutObject → app-data-production/output/result.json]
  dangerous set:     [s3:PutBucketPolicy → customer-pii-bucket
                      s3:DeleteObject → billing-archives/jan-2026.csv
                      s3:PutBucketAcl → audit-logs-bucket]
  verdict: SAT — witness: s3:PutBucketPolicy on customer-pii-bucket

Five of five witnesses admitted. The solver picks the first dangerous-and-not-intended one as a proof: an attacker with this role's credentials can make customer-pii-bucket public with a single s3:PutBucketPolicy call. The customer does not need to read the policy carefully or imagine the attack chain. The witness is the attack chain.

After the policy is scoped:

=== after  (scoped actions + ARNs) ===
  policy statements: 3
    [0] Effect=Allow Action=s3:GetObject Resource=arn:aws:s3:::app-data-production/input/*
    [1] Effect=Allow Action=s3:PutObject Resource=arn:aws:s3:::app-data-production/output/*
    [2] Effect=Allow Action=[logs:...] Resource=arn:aws:logs:...
  admitted requests: 2 / 5
  ...
  verdict: UNSAT — no dangerous action admitted outside intended scope

UNSAT. Two admitted requests, both intended. No dangerous-and-unintended request remains.

The CI Gate

The same policy that grants s3:* on * also contains a correctly-scoped CloudWatch Logs statement:

{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "arn:aws:logs:us-east-1:111122223333:*"
}

Three specific actions, one regional ARN namespace. The developer knew how to scope a permission. They chose not to scope S3, because:

The function's S3 usage was being iterated on during development; broad permissions kept the test loop fast.
Scoping S3 requires knowing the exact bucket prefix the function reads, which depends on whether you're in dev, staging, or prod. The developer was about to template that out, but the deadline arrived first.
The same broad policy worked the last time the team shipped a Lambda. Nobody filed a follow-up to scope it.

Pen testers and SOC analysts often blame the developer who wrote this kind of policy. The CloudWatch Logs statement proves they had the skill. What they didn't have was a CI gate that said "you're shipping s3:*, this fails the build."

The Remediation

 {
   "Statement": [
     {
       "Effect": "Allow",
-      "Action": "s3:*",
-      "Resource": "*"
+      "Action": "s3:GetObject",
+      "Resource": "arn:aws:s3:::app-data-production/input/*"
+    },
+    {
+      "Effect": "Allow",
+      "Action": "s3:PutObject",
+      "Resource": "arn:aws:s3:::app-data-production/output/*"
     },
     {
       "Effect": "Allow",
       "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
       "Resource": "arn:aws:logs:us-east-1:111122223333:*"
     }
   ]
 }

Three lines turn into seven. The function's behaviour doesn't change; the role's reach does. The CEL predicate goes from has_resource_wildcard_on_sensitive: true to false; Z3 goes from SAT-with-witness to UNSAT.

The Prevention Lesson

The fix is three layers, in order of leverage:

Service Control Policy denying wildcard sensitive actions for compute roles. At the organisation level:

{
  "Sid": "DenyWildcardSensitiveActions",
  "Effect": "Deny",
  "Action": [
    "s3:*",
    "kms:*",
    "dynamodb:*",
    "secretsmanager:*"
  ],
  "Resource": "*",
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalArn": [
        "arn:aws:iam::*:role/SecurityBootstrap*",
        "arn:aws:iam::*:role/CloudOps*"
      ]
    }
  }
}

The SCP refuses to apply any policy of this shape to non-bootstrap roles. The denial is global and silent. The developer's broad-policy attempt fails at policy-attach time, never reaches deploy.

Module-level enforcement in IaC. The Terraform / CDK / Pulumi module that creates a Lambda execution role takes an s3_resources: list(string) parameter. The module composes the statement itself; passing ["*"] is rejected at plan time.

CI gate on stave apply. The example shipped with this article is the template. A PR that introduces a role with has_resource_wildcard_on_sensitive: true produces exit 3 from CTL.IAM.POLICY.RESOURCE.WILDCARD.001. Same predicate, same exit code as the example; the build fails before the PR is mergeable.

The CI gate catches policies created outside IaC. A console click during incident response, an emergency hotfix, a third-party service that creates a role on first install. The other two layers prevent the unsafe shape. The CI gate makes sure the prevention is working.

Checklist

Service Control Policy denies wildcard sensitive actions on Resource: "*" for non-bootstrap roles
IaC modules for compute-service execution roles take a typed list of allowed resources, not a free-form policy document
stave apply runs in CI against the post-deploy observation snapshot; PRs with has_resource_wildcard_on_sensitive: true fail
Production roles do not pair s3:*, kms:*, dynamodb:*, or secretsmanager:* with Resource: "*"
Code review for new Lambda functions reads the role's policy, not just the function's code, because what the role can do matters more than what the function currently does

The policy in the before fixture is honest. It says: "I am too broad." The CEL predicate reads the boolean and agrees; the Z3 witness names the specific dangerous call. The SCP at the org level makes that combination impossible to ship in the first place. The lesson is "infrastructure should make broad policies hard to write by mistake."

The $1.5B Wildcard: When `company-frontend-*` Matches Production

The Lambda fixture above uses Resource: "*". The CEL predicate sets has_resource_wildcard_on_sensitive: true and the control fires loudly. That is the easy case.

The interesting case is the one the boolean misses. In March 2025, attackers stole $1.5 billion in ETH from Bybit's hot wallet. The attack didn't exploit Bybit's infrastructure directly. It exploited Safe{WALLET}'s. A developer at the wallet provider had an IAM policy roughly like this:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:DeleteObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::company-frontend-*",
    "arn:aws:s3:::company-frontend-*/*"
  ]
}

Every action is a specific named operation; every resource is scoped to a prefix. The CEL boolean has_resource_wildcard_on_sensitive is set to false. The engine is reading "scoped" because the ARN isn't the literal *. The policy looks fine to a heuristic checker.

It is not fine. The prefix company-frontend-* matches both company-frontend-dev (intended) and company-frontend-prod (not intended). The developer could write to production. The production bucket served the application's JavaScript via CloudFront. Compromise the developer's machine, run a single aws s3 cp app.js s3://company-frontend-prod/app.js, and every user of the application loads attacker-supplied code on the next page reload.

This is in the example as fixtures/bybit-pattern-before/. The CEL control stays silent on it. Z3 finds the witness:

=== bybit-pattern-before (developer with s3:PutObject on company-frontend-*) ===
  policy statements: 1
    [0] Effect=Allow
        Action=[s3:GetObject s3:PutObject s3:DeleteObject s3:ListBucket]
        Resource=[arn:aws:s3:::company-frontend-*
                  arn:aws:s3:::company-frontend-*/*]
  buckets observed:  2
    - company-frontend-prod   environment=production   served_via=cloudfront
    - company-frontend-dev   environment=development   served_via=

  --- Bybit Pattern: Developer Write to Production S3 ---
  verdict: SAT
  witness: s3:PutObject on arn:aws:s3:::company-frontend-prod/app.js
           (resource pattern matches both dev and prod)
  rationale: environment=production, served_via=cloudfront — modifying
             app.js is a supply chain attack via CloudFront

Z3 enumerates buckets by integer index, asks for an admitted-by-policy witness whose environment tag is production, and reports the prod bucket. The prefix wildcard the heuristic accepted is the same wildcard Z3 makes concrete.

The compound finding — undetectable supply chain

Write access to production isn't enough on its own. The attacker needs the write to be invisible. Z3's second query compounds four conditions:

write_access_to_prod   ∧   no_mfa_condition   ∧
no_ip_condition        ∧   no_object_logging

Each is independently not remarkable. Together they describe the Bybit attack:

  --- Compound: Undetectable Production Write ---
  verdict: SAT
  witness: developer can write to production S3 from any IP,
           without MFA, with no CloudTrail data-event record
  rationale: write_access=true   no_mfa=true   no_ip=true   no_logging=true

A heuristic scanner would issue four separate alerts ("policy is broad", "no MFA condition", "no IP restriction", "data events disabled"). Most of which look like reasonable choices in isolation. Together they are the attack path. Z3 finds the conjunction.

Why this is the harder case

The Lambda example fires on the CEL boolean. The Bybit example does not. It caused a $1.5 billion theft. Because the unsafe state is a join across multiple assets:

Signal	Lambda example	Bybit example
Resource wildcard	literal `*`	prefix `*` (after `-`)
Sensitive action	`s3:*`	`s3:PutObject`
What CEL sees	one role asset	one user + two buckets
What CEL reports	NON_COMPLIANT	COMPLIANT (silent)
Z3 verdict	SAT	SAT
Real exposure	high	$1.5B

The CEL control isn't broken. It's working as designed: it detects what its boolean field encodes, and the boolean encodes "literal Resource:*". The policy that took down Safe{WALLET} doesn't have that. It has a prefix wildcard that, paired with the bucket naming convention, admits the action that mattered.

This is the case for two-level architecture. The CEL boolean covers the obvious case in milliseconds. The Z3 prover covers the conjunctive case with the same observation file, same asset graph, different reasoning depth. Both fire on fixtures that ship with this article. One catches the easy case; the other catches the case that happens.

The fix is one character

company-frontend-* → company-frontend-dev.

The remediated fixture splits the policy into
two statements: full read/write on dev, read-only on prod.
Z3 reports UNSAT on both queries:

  --- Bybit Pattern: Developer Write to Production S3 ---
  verdict: UNSAT
  rationale: no production bucket admitted by s3:PutObject

  --- Compound: Undetectable Production Write ---
  verdict: UNSAT
  rationale: write_access=false   no_mfa=true   no_ip=true   no_logging=true

One character difference between the policies that enabled the largest cryptocurrency theft in history. The infrastructure question — how do you make that mistake hard to commit by accident is the same one the Lambda example raises. The answer is the same: typed IaC modules, SCPs that deny prefix-wildcard resources on production buckets, and a checker that reasons about which buckets the wildcard admits, not just whether it looks like a wildcard.

The example at iam-overpermission-wildcard is two binaries side by side: a CEL evaluation via pkg/stave.Apply (asserts the unsafe state when the attached policy has a wildcard sensitive action) and a Z3 SAT prover (extracts a concrete dangerous action the policy admits — s3:PutBucketPolicy on customer-pii-bucket in the demo). The Z3 binary lives in a sibling Go module so its libz3 link stays out of Stave's main vendored tree. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, without cloud credentials.

I Ran a Security Scanner Against Mastodon, Discourse, and Chatwoot's AWS Defaults. Here's What I Found.

Bala Paranj — Fri, 02 Oct 2026 12:38:32 +0000

You deploy a Rails app to AWS. You follow the README. File uploads work. You move on.

But what just happened to the S3 bucket your app is writing to? Is it encrypted? Is it public? Could someone use it to ransom your data?

I used Stave, an open-source configuration safety tool, to answer those questions for three of the most popular open-source Rails applications: Mastodon (47K stars), Discourse (43K stars), and Chatwoot (22K stars).

The results: 47 security findings across three projects. Two of the three default to publicly readable S3 buckets. None configure encryption, access logging, or Public Access Block.

This isn't a vulnerability disclosure. These projects work exactly as documented. The problem is the documentation.

The Methodology

Clone each project's source code
Extract AWS configuration from initializers, config/storage.yml, environment templates, and site settings
Generate JSON snapshots representing "what a deployer gets if they follow the docs without additional hardening"
Run Stave's control catalog against those snapshots

No AWS credentials needed. No running infrastructure. Stave evaluates configuration snapshots offline. It checks what the bucket would look like based on the application defaults.

Finding #1: Mastodon Defaults to public-read

Open config/initializers/paperclip.rb in Mastodon's repo. Line 57:

s3_permissions: ENV.fetch('S3_PERMISSION') { 'public-read' },

If you don't set the S3_PERMISSION environment variable, every file your Mastodon instance uploads to S3 gets a public-read ACL. Profile pictures, media attachments, header images are all readable by anyone on the internet.

This is intentional for federation. Mastodon needs remote servers to fetch media. But the security implications go beyond serving images:

No safety net. Without S3 Public Access Block enabled, there is no account-level guard preventing this bucket or any bucket in your AWS account from being public.
Scanners are watching. Automated tools continuously enumerate S3 bucket names. Once your bucket name leaks (it's in every image URL your instance serves), every object key someone can guess is downloadable.
ACLs override policies. Even if you add a restrictive bucket policy later, the object-level public-read ACL still grants access. The ACL and the policy are evaluated independently either one granting access is sufficient.

Stave flagged this as CTL.S3.PUBLIC.001 critical severity, exposure score 100/100.

The fix for Mastodon deployers: Set S3_PERMISSION='' (empty string) in your environment. Line 75 of the same file disables ACLs entirely when this is set:

Paperclip::Attachment.default_options[:s3_permissions] = ->(*) {} if ENV['S3_PERMISSION'] == ''

Finding #2: Discourse Does the Same Thing, But Through Admin Settings

Discourse doesn't use environment variables for S3 ACLs. It uses SiteSetting:

# config/site_settings.yml:2629
s3_use_acls:
  default: true

Combined with:

secure_uploads:
  default: false

When s3_use_acls is true and secure_uploads is false, non-secure uploads get a public-read ACL. The logic lives in lib/file_store/s3_store.rb:

# lib/file_store/s3_store.rb:390
def s3_bucket_folder_path
  # When secure_uploads is disabled, uploads are public
end

Same critical finding. Same exposure. Different mechanism.

The fix for Discourse deployers: Enable secure_uploads in admin settings, or disable s3_use_acls.

Finding #3: Chatwoot Gets One Thing Right

Chatwoot uses Active Storage with S3. Here's their config/storage.yml:

amazon:
  service: S3
  access_key_id: <%= ENV.fetch('AWS_ACCESS_KEY_ID', '') %>
  secret_access_key: <%= ENV.fetch('AWS_SECRET_ACCESS_KEY', '') %>
  region: <%= ENV.fetch('AWS_REGION', '') %>
  bucket: <%= ENV.fetch('S3_BUCKET_NAME', '') %>

No ACL configuration. Active Storage creates private objects by default. Chatwoot is the only project of the three that does NOT default to public-read.

Result: 15 findings instead of 16. The public access finding doesn't fire. Everything else does.

The 15 Findings Every Rails-on-S3 Deployer Shares

All three projects share these findings. They are infrastructure settings that Rails applications never touch and that setup documentation never mentions:

Critical

Finding	What It Means in Plain English
SSE-C not disabled	Anyone with `s3:PutObject` permission can encrypt your files with their own key. You can't decrypt them. AWS can't help. This is the S3 ransomware vector and it requires zero KMS permissions.

High

Finding	What It Means in Plain English
No account-level Public Access Block	Any bucket in your AWS account can be made public by a single misconfiguration. PAB is the kill switch that prevents it.
No bucket-level Public Access Block	Same as above, but per-bucket. Without it, a bad bucket policy or ACL change exposes your data with no warning.
No encryption at rest	Your files sit unencrypted on AWS disks. If AWS has a physical security incident, your data is readable. Every compliance framework requires this.
No HTTPS enforcement	Without a bucket policy denying `aws:SecureTransport=false`, someone could access your bucket over plain HTTP. Your Rails app uses HTTPS, but the S3 API doesn't enforce it by default.
No VPC endpoint restriction	Your bucket is reachable from any network path on the internet. No IP or VPC condition limits who can even try to connect.
No ownership controls	ACLs are still active on the bucket. Any uploader can set object-level ACLs that override your bucket policy.
BlockPublicAcls not enabled	Someone can add a `public-read` ACL to an object. PAB would reject this at the API level.
BlockPublicPolicy not enabled	Someone can add a bucket policy granting `Principal: "*"` access. PAB would reject this at the API level.
IgnorePublicAcls not enabled	Existing public ACLs are honored. PAB would ignore them.
RestrictPublicBuckets not enabled	Cross-account access via public policies is unrestricted. PAB would block it.

Medium

Finding	What It Means in Plain English
No access logging	You have zero visibility into who accessed your bucket, when, and what they downloaded. If you get breached, you won't know what was taken.
No versioning	If someone deletes or overwrites a file, it's gone. No recovery. Combined with the ransomware vector above, this means a complete data loss scenario.
No multipart upload cleanup	Incomplete multipart uploads accumulate forever, costing you money. A lifecycle policy cleans these up automatically.

Low

Finding	What It Means in Plain English
No governance controls	No Object Lock, no legal hold, no retention policies. Your files can be deleted by any principal with the right permissions.

Why This Happens: The Rails-AWS Gap

Rails has excellent abstractions for storage. Active Storage and Paperclip make file uploads trivial. But they abstract at the application level what goes into the bucket, not how the bucket is configured.

The bucket is infrastructure. Infrastructure configuration lives in a different world:

Your Rails app                  Your AWS account
┌──────────────┐                   ┌──────────────────────┐
│  Paperclip   │── s3:PutObject ──▶│  S3 Bucket           │
│  or Active   │                   │  - No encryption     │
│  Storage     │                   │  - No PAB            │
│              │                   │  - No logging        │
│  "It works!" │                   │  - No versioning     │
└──────────────┘                   │  - SSE-C enabled     │
                                   │  - Public ACLs ok    │
                                   └──────────────────────┘

Your app works. Your bucket is a liability.

This isn't a Rails problem specifically. It's a deployment documentation problem. The gap exists because:

Rails gems configure the client, not the bucket. aws-sdk-s3 sets up the connection. It doesn't run put-bucket-encryption or put-public-access-block.
Setup docs stop at "uploads work." Mastodon's docs explain how to configure S3 credentials. They don't mention encryption, PAB, or access logging.
Terraform and CloudFormation exist, but aren't part of the Rails story. Infrastructure-as-code tools handle bucket hardening well. But a developer following a Rails project's README will create a bucket through the AWS console and move on.
Security is someone else's job. Application developers think the cloud team handles bucket security. Solo deployers don't have a cloud team.

How Stave Works

Stave doesn't scan your AWS account or need credentials. It evaluates JSON snapshots. A structured representations of your infrastructure configuration against a catalog of controls written as CEL (Common Expression Language) predicates.

For example, the public access control checks:

storage.access.public_read eq true

If that property is true in your observation snapshot, the control fires. Each control maps to compliance frameworks (CIS, NIST, PCI DSS, HIPAA, SOC 2) and includes a severity, remediation steps, and an exposure score.

For this analysis, I extracted configuration defaults from source code and translated them into Stave observation snapshots. The approach is deterministic: given the same source code defaults, Stave will always produce the same findings.

What You Should Do

If you're deploying any Rails application to AWS with S3:

Right now (5 minutes):

# Enable account-level Public Access Block
aws s3control put-public-access-block \
  --account-id YOUR_ACCOUNT_ID \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

This single command prevents any bucket in your account from being accidentally made public. It's the highest-impact change you can make.

This week:

# Enable default encryption on your bucket
aws s3api put-bucket-encryption \
  --bucket YOUR_BUCKET \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# Enforce HTTPS
aws s3api put-bucket-policy \
  --bucket YOUR_BUCKET \
  --policy '{
    "Version":"2012-10-17",
    "Statement":[{
      "Sid":"EnforceHTTPS",
      "Effect":"Deny",
      "Principal":"*",
      "Action":"s3:*",
      "Resource":["arn:aws:s3:::YOUR_BUCKET","arn:aws:s3:::YOUR_BUCKET/*"],
      "Condition":{"Bool":{"aws:SecureTransport":"false"}}
    }]
  }'

# Enable access logging
aws s3api put-bucket-logging \
  --bucket YOUR_BUCKET \
  --bucket-logging-status \
  '{"LoggingEnabled":{"TargetBucket":"YOUR_LOG_BUCKET","TargetPrefix":"s3-access-logs/"}}'

# Enable versioning
aws s3api put-bucket-versioning \
  --bucket YOUR_BUCKET \
  --versioning-configuration Status=Enabled

If you're running Mastodon: Set S3_PERMISSION='' in your environment. This is the most important single change.

If you're running Discourse: Enable secure_uploads in your admin panel.

The Scorecard

Project	Findings	Worst Finding	One-Line Fix
Mastodon	16	public-read default	`S3_PERMISSION=''`
Discourse	16	public-read via SiteSetting	Enable `secure_uploads`
Chatwoot	15	SSE-C ransomware vector	Account-level PAB

Chatwoot's Active Storage default (private objects) is the safer pattern. If you're building a new Rails app, prefer Active Storage's defaults over configuring ACLs.

Methodology Notes

Analysis based on source code defaults only. Actual deployments vary based on operator configuration.
Observation snapshots represent "follow the docs, change nothing else" deployments.
Stave's control catalog covers S3 only for this analysis. Discourse's SNS, MediaConvert, and Bedrock integrations were not evaluated.
The public-read default in Mastodon is documented behavior. Discourse's ACL behavior is configurable. Neither is a vulnerability. Both are deployment defaults that produce a weak security posture.

Stave is an open-source configuration safety tool. It evaluates infrastructure configuration snapshots against security controls without credentials or API access. Install it with go install github.com/sufield/stave@latest.

Your Deny Policy Blocks Six Privesc Paths. There Are Nine.

Bala Paranj — Thu, 01 Oct 2026 11:34:02 +0000

In July 2022 Edoardo Rosa published a writeup documenting a privilege escalation in AWS where a principal carrying the AWS-managed DataScientist policy plus AmazonElasticMapReduceFullAccess could escalate to admin even with an explicit deny policy in place. The deny DemoDenyPrivEscs in the writeup listed six actions:

{
  "Effect": "Deny",
  "Action": [
    "cloudformation:CreateStack",
    "cloudformation:UpdateStack",
    "ec2:RunInstances",
    "lambda:Create*",
    "lambda:Update*",
    "lambda:InvokeFunction"
  ],
  "Resource": "*"
}

Each one is a known compute-launch path that, combined with iam:PassRole, lets a principal launch compute running as a different role. The deny list reads like the result of a security review where someone enumerated "ways to launch EC2 with a role" and copied them into a policy.

The writeup shows that this list is incomplete. The author found one bypass: autoscaling:CreateLaunchConfiguration + autoscaling:CreateAutoScalingGroup by manual inspection of the AWS service catalog. The path works: the launch configuration specifies an admin role as the instance profile, the autoscaling group launches an EC2 with that role, the principal reads IMDS credentials and gains admin.

This article runs the same configuration through a Z3 SAT solver with a registry of nine known compute-launch vectors. The solver finds five bypasses. After remediation when the deny list is expanded to cover all nine the solver proves the architectural residual: every new compute service AWS adds becomes a new bypass path.

The deny-list approach to privilege escalation prevention is structurally fragile. The math says so.

Compute-launch vector

A compute-launch vector is any (set of actions) combination that, with iam:PassRole, results in compute running as a specified role. The known vectors:

Service	Action(s)	PassedToService
EC2	`ec2:RunInstances`	`ec2.amazonaws.com`
Lambda	`lambda:CreateFunction`	`lambda.amazonaws.com`
Lambda	`lambda:UpdateFunctionConfiguration`	`lambda.amazonaws.com`
CloudFormation	`cloudformation:CreateStack`	`cloudformation.amazonaws.com`
Auto Scaling	`autoscaling:CreateLaunchConfiguration` + `CreateAutoScalingGroup`	`ec2.amazonaws.com`
ECS	`ecs:RunTask`	`ecs-tasks.amazonaws.com`
CodeBuild	`codebuild:CreateProject` + `StartBuild`	`codebuild.amazonaws.com`
Glue	`glue:CreateJob`	`glue.amazonaws.com`
SageMaker	`sagemaker:CreateNotebookInstance`	`sagemaker.amazonaws.com`

Nine vectors. Each one is a different code path inside AWS, but each one ends at the same place: an EC2-like compute environment running with the IAM role you named.

The writeup's deny list covers four: ec2:RunInstances, lambda:CreateFunction (via lambda:Create*), lambda:UpdateFunctionConfiguration (via lambda:Update*), and cloudformation:CreateStack. Plus cloudformation:UpdateStack (which doesn't itself launch compute but is included for completeness) and lambda:InvokeFunction (also not a compute-launch). The five it misses are autoscaling, ECS, CodeBuild, Glue, and SageMaker.

The author found one of those five. The other four were sitting there untouched.

The Z3 setup

The Z3 prover walks the principal's three policies DataScientist, EMRFullAccess, DemoDenyPrivEscs and computes the effective permission set: actions that appear in at least one Allow statement and no Deny statement. For each of the nine compute-launch vectors, the prover checks whether all required actions are effectively permitted and iam:PassRole is allowed for the vector's PassedToService.

vector_available(vector) :=
  ALL action in vector.RequiredActions:
    action in any Allow statement
    AND action not in any Deny statement
  AND iam:PassRole is allowed AND not denied
  AND vector.PassedToService in some PassRole condition

The Z3 query for Finding 1: is there any vector for which vector_available(vector) is true?

Three findings on the writeup config

Finding 1: deny coverage gap

--- Finding 1: deny coverage gap ---
  query:    among 9 known compute-launch vectors, is any one
            effectively permitted (Allow ∧ ¬Deny)?
  vectors available: 1 / 9
  verdict:  SAT — witness: autoscaling — Auto Scaling launch config + group with instance profile
            actions: [autoscaling:CreateLaunchConfiguration autoscaling:CreateAutoScalingGroup]
            (deny does not cover these actions; the path is open)

vectors available: 1 / 9 The prover counts the autoscaling vector as the one reachable path. The other available vectors are filtered by the PassedToService condition: ECS needs ecs-tasks.amazonaws.com in the condition list, which isn't there; CodeBuild needs codebuild.amazonaws.com, also missing; same for Glue and SageMaker. The autoscaling vector matches because EMRFullAccess's PassRole condition includes ec2.amazonaws.com.

But the deny coverage table separate from the SAT proof shows which actions the deny does and doesn't cover:

--- Deny coverage analysis ---
  ec2             BLOCKED    : Direct EC2 launch with instance profile
  lambda          BLOCKED    : Create Lambda with execution role
  lambda          BLOCKED    : Update existing Lambda to use different execution role
  cloudformation  BLOCKED    : Create CloudFormation stack with execution role
  autoscaling     NOT BLOCKED : Auto Scaling launch config + group with instance profile
  ecs             NOT BLOCKED : Run ECS task with task role
  codebuild       NOT BLOCKED : Create and start CodeBuild project with service role
  glue            NOT BLOCKED : Create Glue job with execution role
  sagemaker       NOT BLOCKED : Create SageMaker notebook with execution role

Five vectors not blocked. The autoscaling one is currently exploitable because the principal's PassRole condition includes EC2. The other four are not currently exploitable because the PassRole condition list doesn't include their respective services. But that's a fragile gate. If the principal later acquires ec2.amazonaws.combroader PassRole (say, through a different attached policy that broadens the service list), or if AWS introduces a new service whose role-passing convention reuses ec2.amazonaws.com, four more vectors become immediately reachable. The deny doesn't block them because the deny doesn't know about them.

Finding 2: PassRole reaches an admin-equivalent role

--- Finding 2: PassRole reaches an admin-equivalent role ---
  query:    is there an admin role whose trust matches the principal's
            PassRole `iam:PassedToService` condition?
  reachable admin roles: 1 / 1
  verdict:  SAT — witness: arn:aws:iam::111122223333:role/demo-EC2Admin
            (trusts [ec2.amazonaws.com]; has AdministratorAccess; PassRole condition
             admits any role trusting one of those services)

The EMR policy's PassRole grant:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": [
        "elasticmapreduce.amazonaws.com",
        "ec2.amazonaws.com"
      ]
    }
  }
}

Resource: "*" and a service-only condition. This is the second architectural fragility: the grant scopes which services the role can be passed to, but not which roles can be passed. Any role in the account trusting elasticmapreduce.amazonaws.com or ec2.amazonaws.com is a passable target. The fixture's demo-EC2Admin trusts ec2.amazonaws.com and has AdministratorAccess.

Finding 3: the compound chain

--- Finding 3: complete privesc chain ---
  query:    is there an available compute-launch vector + an admin
            role + a trust relationship that all line up?
  compound paths: 1
  verdict:  SAT — witness: vector=autoscaling role=arn:aws:iam::111122223333:role/demo-EC2Admin
            chain: [autoscaling:CreateLaunchConfiguration autoscaling:CreateAutoScalingGroup] → role with AdministratorAccess assumed by EC2 →
            principal reads IMDS credentials → admin

The conjunction lands. A vector is reachable, an admin role is PassRole-reachable, and the role's trust service matches the vector's PassedToService. Three API calls CreateLaunchConfiguration, CreateAutoScalingGroup, then SSH into the launched instance and the principal has admin.

The remediated config and the residual

The natural fix: expand the deny list to cover every known compute-launch action.

 {
   "Effect": "Deny",
   "Action": [
     "cloudformation:CreateStack",
     "cloudformation:UpdateStack",
     "ec2:RunInstances",
     "lambda:Create*",
     "lambda:Update*",
-    "lambda:InvokeFunction"
+    "lambda:InvokeFunction",
+    "autoscaling:CreateLaunchConfiguration",
+    "autoscaling:CreateAutoScalingGroup",
+    "autoscaling:UpdateAutoScalingGroup",
+    "ecs:RunTask",
+    "ecs:CreateService",
+    "codebuild:CreateProject",
+    "codebuild:StartBuild",
+    "glue:CreateJob",
+    "sagemaker:CreateNotebookInstance",
+    "sagemaker:CreateTrainingJob"
   ],
   "Resource": "*"
 }

Re-run the prover:

========== remediated-config (deny expanded to all 9 known vectors) ==========
--- Finding 1: deny coverage gap ---
  vectors available: 0 / 9
  verdict:  UNSAT — every known compute-launch vector is denied
            (the expanded deny list covers all 9 known vectors today;
             see Finding 2 for the residual structural risk)

--- Finding 2: PassRole reaches an admin-equivalent role ---
  verdict:  SAT — witness: arn:aws:iam::111122223333:role/demo-EC2Admin
            **RESIDUAL** — the remediated config closes today's launch
            vectors but does not scope PassRole by role ARN. Any new
            compute service AWS adds becomes an immediate exploit
            path until the deny list is expanded.

--- Finding 3: complete privesc chain ---
  compound paths: 0
  verdict:  UNSAT — no compound privesc path open
            (Finding 1 closed all launch vectors; without one of those,
             the PassRole reachability in Finding 2 has nowhere to land)

Two of three queries flipped to UNSAT. Finding 2 remains SAT.

The remediation works. Finding 3 is UNSAT, no exploit path is currently open. But Finding 2's persistent SAT is the formal proof that the architecture is structurally fragile. The principal can still pass an admin role to "any service in the condition list." The principal cannot currently use that role because all known compute-launch services are denied. The day AWS introduces a new compute service that the deny list doesn't know about and AWS introduces roughly a new service per quarter. Finding 3 flips back to SAT.

The architectural fix the deny list doesn't make

Two ways to scope iam:PassRole:

// What the writeup uses (and what the remediation
// keeps unchanged):
{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": [
        "elasticmapreduce.amazonaws.com",
        "ec2.amazonaws.com"
      ]
    }
  }
}

// What's structurally sound:
{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": [
    "arn:aws:iam::111122223333:role/EMRClusterRole",
    "arn:aws:iam::111122223333:role/EMRDataNodeRole"
  ]
}

The first form scopes by which services and delegates the question of "which roles trust those services" to the IAM trust-policy graph, which the operator does not control globally. The second form scopes by which roles which is explicit and finite.

The deny list approach is a chase: every time AWS adds a service that supports an instance profile or task role, the deny list grows. The PassRole-by-role approach is a fixed enumeration: the only roles that can ever be passed are the named ones, regardless of what AWS launches next month. Z3's residual SAT on Finding 2 is the formal way of saying "the deny list is the wrong shape; the PassRole grant is the right shape."

What pattern-matching tools miss

A heuristic IAM scanner like PMapper detects this specific bypass. Edoardo Rosa's writeup acknowledges PMapper. But a heuristic scanner reports "this principal can launch autoscaling with an admin role". A true positive, the kind of finding a SOC reviewer would action. The reviewer fixes autoscaling and moves on.

The Z3 prover reports the same finding and the deny coverage table and the residual. The reviewer sees:

The autoscaling exploit path is currently active.
Four other compute-launch vectors are also not blocked (and waiting for a PassRole condition broadening).
After fixing all five vectors, the underlying PassRole grant is still over-broad. The correct long-term fix is at the PassRole layer.

That last point is the difference between "close the autoscaling hole" and "close the deny-list-architecture issue." The first a heuristic recommends. The second formal verification recommends.

Checklist

No principal has iam:PassRole with Resource: "*". The resource is always a specific role ARN list
Service Control Policies enforce iam:PassRole resource scoping for non-admin principals at the org level
Deny lists are not the primary defense for privilege escalation. They're a defense in depth behind PassRole-by-role
CI runs stave apply against post-deploy observation snapshots; the existing CTL.IAM.ESCALATE.PASSROLE.AUTOSCALING.001 and similar per-technique controls fire on regressions
When AWS launches a new compute service, the review explicitly checks whether iam:PassRole grants in production policies could now reach the new service's role-pass mechanic

The researcher found one bypass through expert knowledge. Z3 found five. After remediation, the solver is still finding something. A structural feature of the architecture that guarantees more exploits will appear. That's the difference between checking the configuration's current state and checking the configuration's durability. Pattern matchers do the first. Z3 does both.

The example at iam-autoscaling-privesc-bypass has two binaries side by side: a CEL evaluation via pkg/stave.Apply (uses the existing CTL.IAM.ESCALATE.PASSROLE.AUTOSCALING.001 per-technique control) and a Z3 SAT prover that walks the principal's effective permission set against a 9-vector compute-launch registry, prints the deny coverage table, and surfaces the residual PassRole-scoping finding that survives remediation. The Z3 binary lives in a sibling Go module so its libz3 link stays out of Stave's main vendored tree. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, without cloud credentials.

Why `Resource: bucket/${tenant}/*` is Not Enough

Bala Paranj — Wed, 30 Sep 2026 13:02:48 +0000

A multi-tenant SaaS that stores customer files in S3 has a predictable architectural choice: one bucket shared across tenants with prefix-based isolation, or one bucket per tenant. Per-tenant buckets cap out around the AWS soft-limit (100 buckets per account); shared-bucket isolation scales further but only works if every layer of the stack respects the prefix invariant.

Two HackerOne reports describe what happens when a layer doesn't:

Shopify 94087 — signed S3 object keys allowed ../ path traversal. One tenant's signed URL reached another tenant's prefix.
Unikrn 254200 — the upload-URL signer didn't enforce per-tenant prefix at all. Tenant A could request a presigned PUT against tenant B's prefix; the signer minted it; S3 honoured it.

Both reports look like S3 misconfigurations. They aren't. The S3 bucket policy in both cases probably contained the right idea — Resource: arn:aws:s3:::<bucket>/${aws:userid}/*, or a StringEquals aws:PrincipalTag/tenant_id condition. The bucket was tenant-aware. The signer was not.

The Layer Boundary

The mental model:

client → API server → S3 bucket policy → object

Bucket-level tenant isolation lives in the third box. Tag the principal, condition the policy on the tag, the policy rejects cross-tenant requests at S3's API layer.

The reality with presigned URLs:

client → API server → app-signer → presigned URL → object (S3 honors signature)
                       ↑
              the prefix-enforcement layer

S3 sees a validly-signed request and serves the object. It does not re-evaluate the bucket policy against the requesting client's identity. The signature is the proof of authorisation. Whatever prefix the signer wrote into the URL S3 honours.

So the tenant-isolation invariant has to be enforced by the signer itself, at signing time, before the URL is minted. That means the signer needs:

The requesting tenant's identity (from the session).
A normalised target key (no .., no extra slashes).
A check that the target key starts with the requesting tenant's prefix.

If any of those three is missing, the signer is the breach surface. The bucket policy could still pass a SOC 2 audit; the signer is the layer where one tenant becomes the next.

The System Invariant

Stave's observation schema has a top-level identities list (sibling to assets) that tracks long-lived signing identities. An app_signer identity carries a purpose field listing the security-relevant flags:

{
  "id": "appsigner:s3:acme-uploads",
  "type": "app_signer",
  "vendor": "aws",
  "properties": {
    "purpose": "signs_uploads;enforce_prefix=false;allow_traversal=true"
  }
}

The enforce_prefix and allow_traversal flags are the operational state of the signer, captured by whatever collector observes the signing service. The bucket asset is separate, and tagged with the tenant scheme:

{
  "id": "acme-tenant-data",
  "type": "aws_s3_bucket",
  "properties": {
    "storage": {
      "kind": "bucket",
      "tags": {
        "tenant_mode": "shared",
        "tenant_prefix": "tenants/{tenant_id}/"
      }
    }
  }
}

Two assets, one invariant: shared-tenant-mode bucket AND permissive signer = unsafe.

The Stave Control

id: CTL.S3.TENANT.ISOLATION.001
name: Shared-Bucket Tenant Isolation Must Enforce Prefix
severity: high
unsafe_predicate:
  all:
    - field: properties.storage.kind
      op: eq
      value: bucket
    - field: properties.storage.tags.tenant_mode
      op: eq
      value: shared
    - field: properties.storage.tags.tenant_prefix
      op: present
      value: true
    - field: identities
      op: any_match
      value:
        all:
          - field: type
            op: eq
            value: app_signer
          - field: id
            op: contains
            value: "appsigner:s3:"
          - any:
              - field: purpose
                op: contains
                value: "allow_traversal=true"
              - field: purpose
                op: contains
                value: "enforce_prefix=false"

The predicate uses any_match. Stave's quantifier over the identities list to look for at least one app-signer with either flag in the unsafe state. CEL evaluates this predicate over the static configuration. The verdict: "the signer is permissive."

Why CEL is Not Enough

CEL detects the unsafe configuration. The natural follow-up question is reachability: given this signer, which tenant-to-tenant request can be made? That's a search across the (requesting_tenant, target_key) space, not a fold over property bags.

Customer-facing impact reports want concrete answers:

Tenant A can request a signed URL for tenants/B/photos/1.jpg.
Path traversal works: tenants/A/../B/secret.json resolves to tenant B's prefix when the signer doesn't normalise.

CEL says the configuration is unsafe. Z3 enumerates the specific requests it admits.

The Z3 Witness Model

The companion program at stave/examples/s3-tenant-prefix-isolation/z3prove/ encodes:

0 = (tenant=A, target="tenants/A/photo.png")        intended
1 = (tenant=A, target="tenants/B/photo.png")        cross-tenant
2 = (tenant=A, target="tenants/A/../B/secret.json") path traversal

The admitted set is parameterised by the signer flags:

Signer state	Admitted set
`enforce_prefix=false`	`{0, 1, 2}` (everything)
`enforce_prefix=true`, `allow_traversal=true`	`{0, 2}` (own + traversal)
`enforce_prefix=true`, `allow_traversal=false`	`{0}` (own only)

The intended set is {0} — each tenant only legitimately needs their own prefix.

Solver discharges unsafe = admitted ∧ ¬intended against the configuration data the fixture provides:

=== before (signer permissive) ===
  signer purpose: signs_uploads;enforce_prefix=false;allow_traversal=true
  flags: enforce_prefix=false   allow_traversal=true
  admitted set: [tenant=A → tenants/A/photo.png
                 tenant=A → tenants/B/photo.png
                 tenant=A → tenants/A/../B/secret.json]
  intended set: ["tenant=A → tenants/A/photo.png"]
  verdict: SAT — witness request: tenant=A → tenants/B/photo.png

SAT. The witness is concrete: tenant=A → tenants/B/photo.png. That's the request a penetration tester can replay; the audit trail will show tenant A signing the URL through normal API channels; nothing about the bucket itself looks misconfigured.

After the signer is fixed:

=== after  (signer enforced) ===
  signer purpose: signs_uploads;enforce_prefix=true;allow_traversal=false
  flags: enforce_prefix=true   allow_traversal=false
  admitted set: [tenant=A → tenants/A/photo.png]
  intended set: ["tenant=A → tenants/A/photo.png"]
  verdict: UNSAT — every admitted request is intended

UNSAT. There is no cross-tenant request the signer admits.

Why This Pattern Hides

The configuration audits a SOC 2 reviewer runs against the bucket itself look fine. The bucket is private, has no public-read or public-list flag, the bucket policy references ${aws:PrincipalTag/tenant_id} in a Resource condition, the IAM roles for human users are all tenant-tagged. Every layer the auditor examines is tenant-aware.

The signer is application code. It runs in the API tier. It takes a session, takes a target key, returns a URL. The SOC 2 reviewer looks at it as a function call, not a security boundary. The function is correct. It produces URLs that work. Nobody re-runs the prefix-enforcement check because nobody filed it as a security control to begin with.

The Remediation

In application code:

 def sign_upload_url(session, target_key):
+    if "/.." in target_key or target_key.startswith("../"):
+        raise SecurityError("path traversal not allowed")
+    expected_prefix = f"tenants/{session.tenant_id}/"
+    if not target_key.startswith(expected_prefix):
+        raise SecurityError(f"key must start with {expected_prefix}")
     return s3.generate_presigned_url(
         "put_object",
         Params={"Bucket": "acme-tenant-data", "Key": target_key},
         ExpiresIn=900,
     )

Two checks: traversal rejection, prefix enforcement. Both run before the signer mints anything. The application is now the layer that holds the tenant-isolation invariant.

For belt-and-braces enforcement at the bucket layer too:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "TenantScopedAccess",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:role/UploadProxy"},
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::acme-tenant-data/tenants/${aws:PrincipalTag/tenant_id}/*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalTag/tenant_id": "${aws:PrincipalTag/tenant_id}"
      }
    }
  }]
}

The condition is the keystone. A presigned URL minted with a session tagged tenant_id=A can never access tenants/B/..., regardless of what the signer does, because the URL's principal tag locks the resource ARN. This is the defense-in-depth layer; the signer is the primary enforcement layer.

The Prevention Lesson

The two reports happened because the signer wasn't audited as a security boundary. Three layers of prevention:

Library default. The presigned-URL helper API takes a session and a target key, and the helper itself enforces the tenant prefix. The application code can't construct an unsafe URL because the helper rejects them. This is the highest-leverage layer. Every existing and future upload feature inherits the invariant.

CI invariant check. stave apply runs against the pre-merge observation snapshot. A signer with enforce_prefix=false or allow_traversal=true produces exit 3 from CTL.S3.TENANT.ISOLATION.001. The fixture shipped with this article is the template with the same predicate, same exit code.

Resource-tag condition on the bucket policy. Even if the signer regresses, the bucket policy's Condition clause on aws:PrincipalTag/tenant_id rejects cross-tenant requests at S3's request-evaluation layer. This is the safety net, the layer that catches mistakes the primary missed.

Checklist

Every app-signer wrapping S3 presigned URLs enforces the tenant prefix and rejects traversal patterns
The presigned-URL helper API takes a session AND a target key (signer has access to both); calls passing arbitrary keys fail at helper boundary
Bucket policy on shared-tenant buckets carries a Condition clause on aws:PrincipalTag/tenant_id that locks the Resource ARN to the requester's tenant
stave apply runs in CI against snapshots that include app_signer identities; PRs introducing a permissive signer fail the gate
Code review for new tenant-aware features explicitly asks "what does the signer enforce?" not just "what does the bucket policy enforce?"

The two HackerOne reports differ in product, in industry, in whether the breach was read-only or write-capable. The configuration that exposed them was identical: a shared bucket with a tenant-aware policy, and a signer that didn't share the same awareness. The lesson is that the bucket policy is not the only layer. The application's signing helper is the layer that mints the URLs S3 will honour, and it has to enforce the same invariant the bucket policy enforces or the bucket policy is decorative.

The example at stave/examples/s3-tenant-prefix-isolation/ is two binaries side by side: a CEL evaluation via pkg/stave.Apply (asserts the unsafe state when the signer is permissive) and a Z3 SAT prover (extracts a concrete cross-tenant request the signer admits but the application never intended). The Z3 binary lives in a sibling Go module so its libz3 link stays out of Stave's main vendored tree. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, with no cloud credentials.

Your S3 bucket is encrypted at rest. It is not encrypted in transit by default.

Bala Paranj — Tue, 29 Sep 2026 13:26:30 +0000

In 2015 a researcher pointed at HackerOne's own attachment bucket and noted that the objects were retrievable over plain HTTP. The data was encrypted at rest. The bucket was private. The objects required authentication. But the HTTP transport itself was unencrypted, and the bucket policy did not deny non-TLS requests. The report became HackerOne #43280.

This is the configuration gap that survives every "encrypt your data" presentation. Encryption-at-rest is the default. Encryption-in-transit is not. Closing the gap is one bucket policy statement, eight lines of JSON. Not closing it is a HIPAA finding (164.312(e)(2)(ii)), a PCI-DSS finding (4.2.1), a SOC 2 finding (CC6.1), and a CIS AWS finding (2.1.1) — simultaneously, on the same bucket, every audit cycle.

The configuration that fails

{
  "storage": {
    "kind": "bucket",
    "id": "aws:s3:::hackerone-attachments",
    "access": {
      "public_read": false,
      "public_list": false
    },
    "encryption": {
      "in_transit_enforced": false
    },
    "controls": {
      "public_access_fully_blocked": true,
      "public_access_block": {
        "block_public_acls": true,
        "ignore_public_acls": true,
        "block_public_policy": true,
        "restrict_public_buckets": true
      }
    }
  }
}

Every line in this block reads like a well-secured bucket. Public read off. Public list off. Public Access Block fully enabled (all four flags). Anonymous access denied at every layer.

The vulnerability is one field: in_transit_enforced: false. The bucket allows HTTPS or HTTP. Any client that calls a presigned URL, a redirect, or a misconfigured CDN over HTTP gets the object delivered in plaintext over the wire.

In transit

AWS S3 supports HTTPS on every endpoint. The question is not "can the bucket be reached over HTTPS?" — it can. The question is "does the bucket refuse HTTP?" and the default answer is no.

The fix is a single bucket policy statement:

{
  "Statement": [{
    "Sid": "DenyInsecureTransport",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::hackerone-attachments",
      "arn:aws:s3:::hackerone-attachments/*"
    ],
    "Condition": {
      "Bool": { "aws:SecureTransport": "false" }
    }
  }]
}

aws:SecureTransport is an IAM condition key. When false, the request came in over HTTP. The deny statement above blocks every action on the bucket from every principal when the request is not TLS. The deny is unconditional, applies to authenticated and anonymous requests alike, and is the canonical fix referenced by every compliance benchmark.

Without this statement, the bucket policy does not say "HTTPS required." It says "any transport works." The default-deny logic of IAM does not save you here. s3:GetObject is explicitly allowed by the bucket policy or by the caller's IAM, and the policy evaluator does not care which TCP socket it arrived on.

Why this hides

The check is fast in audit. The check is invisible in operation. Three reasons:

S3 console UX never surfaces it. The console encourages you to set up encryption at rest (KMS or SSE-S3), configure replication, configure lifecycle. Transport encryption is a policy concern, and you only see it if you go read the policy. The console's "Permissions" tab does not have an "HTTPS required" checkbox the way it has a "Block public access" checkbox.

Working HTTPS hides broken HTTP. Every SDK uses HTTPS by default. Every console operation uses HTTPS. Every CloudFront-fronted object uses HTTPS. The HTTP path is reachable but rarely traversed by your own code. Until an old SDK, a legacy integration, a custom uploader, or a presigned URL leak takes the HTTP path, nothing visibly breaks.

Scanners report compliance, not transport. Most scanners flag "encryption at rest enabled?" with a checkmark and move on. The transport-encryption check is a separate rule, often grouped with TLS-version checks on ALB and CloudFront, and is missing from a surprising number of CSPM defaults. CIS AWS v3.0 control 2.1.1 explicitly calls it out and the corresponding policy-as-code rules are present in OPA-libraries but often disabled because they generate noise.

The system invariant

The invariant for the data layer:

Restated as a fact predicate: for every bucket, storage.encryption.in_transit_enforced must be true. The boolean is a projection of "does this bucket have a policy statement denying aws:SecureTransport: false?" produced once by the extractor, then evaluated by every consumer (audit, gate, dashboard, compliance report) against the same projected value.

What Stave detects

id: CTL.S3.ENCRYPT.002
name: Transport Encryption Required
description: >
  S3 buckets must enforce HTTPS via a deny policy on aws:SecureTransport=false.
  Without this, data transfers occur in plaintext.
severity: high
compliance:
  hipaa: "164.312(e)(2)(ii)"
  cis_aws_v3.0: "2.1.1"
  pci_dss_v4.0: "4.2.1"
  soc2: "CC6.1"
  nist_800_53_r5: "SC-8"
unsafe_predicate:
  all:
    - field: properties.storage.kind
      op: eq
      value: bucket
    - field: properties.storage.encryption.in_transit_enforced
      op: eq
      value: false

Two-line predicate. The first line scopes to buckets (the same property block can describe replication targets or website endpoints; this control only applies to the bucket asset). The second line is the actual check: in-transit enforcement must be true.

The compliance block carries six framework citations. Each is a separately motivated reason this control exists. None of them changes the predicate. The rule is the same regardless of which audit the customer is preparing for.

Run the fixture

cd stave && make build

# The fixture ships two snapshots (T1 unsafe, T2 fixed). Evaluate T1 alone to
# reproduce the original finding.
tmp=$(mktemp -d)
cp testdata/e2e/e2e-h1-hackerone-43280/observations/2015-01-11T000000Z.json "$tmp/"

./stave apply \
  --controls testdata/e2e/e2e-h1-hackerone-43280/controls \
  --observations "$tmp" \
  --max-unsafe 168h \
  --eval-time 2015-01-18T00:00:00Z \
  --allow-unknown-input \
  --format json | jq '.findings[0]'

{
  "control_id": "CTL.S3.ENCRYPT.002",
  "control_severity": "high",
  "asset_id": "aws:s3:::hackerone-attachments",
  "evidence": {
    "misconfigurations": [
      { "property": "storage.encryption.in_transit_enforced",
        "actual_value": false,
        "operator": "eq",
        "unsafe_value": false }
    ]
  },
  "remediation": {
    "description": "Bucket does not enforce HTTPS for data transfers. Requests over plain HTTP transmit data in cleartext.",
    "action": "Add a bucket policy statement that denies all actions when aws:SecureTransport is false. This forces all API calls to use HTTPS."
  }
}

One field, property path and shell-pasteable fix. The compliance citations live on the control YAML, they show up in the report renderer when the operator asks for "show me findings tagged HIPAA" or "show me findings tagged CIS AWS v3.0."

The remediation

aws s3api put-bucket-policy \
  --bucket hackerone-attachments \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [{
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::hackerone-attachments",
        "arn:aws:s3:::hackerone-attachments/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }]
  }'

If the bucket already has a policy with other statements (e.g., a CloudFront OAI grant), append the DenyInsecureTransport statement to the existing policy rather than overwriting. The deny is evaluated before any allow in IAM policy logic, so it composes with any existing allow statements you have.

Why it generalises

This is the cheapest possible class of HIPAA-grade finding to close. One bucket policy statement, eight lines of JSON, zero performance cost, no application changes required. The reason it persists in the wild is the same reason most cloud security findings persist: the configuration was set up before the compliance bar existed, never re-audited against the current bar, and the tool the team uses to audit does not check this specific predicate by default.

The right answer is a presence check at the project layer: every bucket your snapshot extractor finds must have in_transit_enforced: true, evaluated continuously, in CI, with the failing PR blocked from merging until the policy statement is added. Stave's CTL.S3.ENCRYPT.002 is that presence check, the fixture above is the e2e regression test for it, and the cost of running it on every commit is roughly the cost of one s3:GetBucketPolicy call per bucket well within the API budget of every audit pipeline.

HackerOne fixed their own bucket policy in 2015. The class of finding has not disappeared since.

Source Code in a Public Bucket: When .git/ Survives Deployment

Bala Paranj — Mon, 28 Sep 2026 12:19:09 +0000

A static-site S3 bucket is, by design, public. Marketing copy, infographics, downloadable assets, anyone on the internet can read the contents. The bucket policy admits Principal: "*" for s3:GetObject, the CDN serves the URLs, the team treats this as a feature.

The bug Mozilla shipped to production in HackerOne 2383486 was that the .git/ directory shipped with the marketing content.

$ curl -s https://acme-marketing-site.example/.git/HEAD
ref: refs/heads/main

$ curl -s https://acme-marketing-site.example/.git/config
[core]
    repositoryformatversion = 0
    filemode = true
[remote "origin"]
    url = git@github.com:acme/marketing-site.git
[user]
    email = alice@acme.example

.git/HEAD is two lines. .git/config is more interesting. It leaks the git remote, the developer's email, and the path of the credential store that was committed once and git rm'd later. From there:

$ wget --mirror https://acme-marketing-site.example/.git/
$ cd acme-marketing-site.example/.git/..
$ git checkout HEAD -- .
# Full repository history, every branch, every commit.
$ git log --all --full-history -- '.env' 'credentials*' 'config/*.yml'
# Every secret ever committed, even the ones that were
# "removed" in a later commit.

Three commands turn a public bucket into a source-code disclosure. Plus the credential set the team thought they had rotated when they git rm'd the original commit.

Why This Pattern Recurs

The deployment pipeline looks like:

# In the build server / CI runner
git clone https://github.com/acme/marketing-site.git build/
# Build steps run inside build/...
aws s3 sync build/ s3://acme-marketing-site/ --delete

build/ is a clone, not an export. It contains .git/. aws s3 sync faithfully uploads every file under build/, including the .git/ subdirectory. The team's mental model is "we sync the build output to S3"; reality is "we sync the build directory plus whatever non-build files are in it."

The fix is one line. The bug ships because nobody's testing "is .git/ in the published artefacts?" before the aws s3 sync runs.

This pattern is broader than a single Mozilla report. Searching public S3 endpoints for .git/HEAD returns hits across every industry; the count tracks how many teams use git clone as their deployment-source step. Most of those teams' S3 buckets are public for the same reason as Mozilla's. The site is intentionally public and the same mistake exposes the same artefacts.

The same shape applies to:

.svn/ — older, but recurring on legacy infrastructure.
.env — environment files committed by a developer for local convenience, never rewritten out of history.
node_modules/.cache/, __pycache__/ — sometimes leak module names not intended for public consumption.
.aws/credentials, .ssh/id_rsa — the developer-machine artefacts that occasionally end up in a build directory through a misconfigured Dockerfile.

The .git/ is the most catastrophic and the source of the failure is the most generic.

The Layer Boundary Problem

Article on (s3-public-read-policy) was about buckets that should not be public. This bucket is supposed to be public. The bucket policy is correct; making the bucket private would break the marketing site.

The fix is at the deployment pipeline layer:

 # In the build server / CI runner
 git clone https://github.com/acme/marketing-site.git build/
 # Build steps run inside build/...
+rm -rf build/.git
 aws s3 sync build/ s3://acme-marketing-site/ --delete

…or use git archive (which has no .git/):

git archive --format=tar HEAD | tar -xC build/

…or have the build pipeline write to a separate dist/ directory and sync only that.

The bucket policy is the right layer for "is this bucket public?" The deployment pipeline is the right layer for "are sensitive paths in the published artefact set?" Conflating them produced the bug.

The System Invariant

In Stave's observation schema, the bucket's content is modelled with two fields under storage.content:

{
  "storage": {
    "access": {
      "public_read": true
    },
    "content": {
      "exposed_repo_artifacts": true,
      "exposed_paths": [
        ".git/HEAD",
        ".git/config",
        ".git/objects/pack/pack-abc123.pack",
        ".env"
      ]
    }
  }
}

exposed_repo_artifacts is the engine's verdict (a collector inspects the bucket's object listing for the known unsafe path patterns). exposed_paths is the evidence which is the key set the collector found.

The Stave Control

id: CTL.S3.REPO.ARTIFACT.001
name: Public Buckets Must Not Expose VCS Artifacts
severity: medium
unsafe_predicate:
  all:
    - any:
        - field: properties.storage.access.public_read
          op: eq
          value: true
        - field: properties.storage.access.public_list
          op: eq
          value: true
    - field: properties.storage.content.exposed_repo_artifacts
      op: eq
      value: true

Two clauses, both required. Either alone is a non-finding:

A private bucket with .git/ in it is fine (IaC backups can be stored that way deliberately).
A public bucket with no repo artefacts is the intended static-site case.

The combination of public and repo artefacts present is the one that fires. Severity is medium because the intended content of the public bucket is by definition public. The escalation comes from artefact paths revealing content the team didn't intend to publish.

Why Z3 Doesn't Help

Same answer as bucket name dangling: this is a presence check at the collector layer, not a reachability question. The collector observes the bucket's object inventory, applies a known-unsafe-paths filter, and emits a boolean. CEL evaluates two booleans.

A reachability question would look like "given this set of admitted requests, is there one that produces a different intended output?". Here the unsafe state is: "the set of objects in the public bucket contains a key matching a known unsafe pattern." That's a deterministic look-up, not a search.

The article's value is in the layer-boundary framing (the bucket policy is the wrong layer to fix this), not in solver mechanics. Some bugs are small predicates with big stories.

Reproducing The Detection

The example is at stave/examples/s3-dotgit-readable/:

go run ./examples/s3-dotgit-readable before

Captured stdout (expected/before-output.txt):

=== before (.git/ exposed) ===
  status: NON_COMPLIANT   total_assets=1   violations=1
  CTL.S3.REPO.ARTIFACT.001 fired on 1 asset(s):
    - arn:aws:s3:::acme-marketing-site   severity=medium   exposure_score=51.10
  assertion: fires=true (expected) ✓

After the deployment pipeline is fixed:

=== after  (artefacts removed) ===
  status: COMPLIANT   total_assets=1   violations=0
  CTL.S3.REPO.ARTIFACT.001: no findings
  assertion: fires=false (expected) ✓

public_read is still true in the after fixture. The bucket is still a public marketing site. The remediation is at the deployment-pipeline layer.

The Remediation

Three options, escalating in robustness:

A. rm -rf .git before s3 sync. Smallest change.
Works as long as nobody changes the deployment script:

git clone "$REPO" build/
# build steps...
rm -rf build/.git
aws s3 sync build/ s3://acme-marketing-site/ --delete

B. Use git archive instead of git clone. Stronger — the source has no .git/ directory at all:

mkdir build/
git archive --format=tar --remote="$REPO" HEAD | tar -xC build/
# build steps...
aws s3 sync build/ s3://acme-marketing-site/ --delete

C. Two-directory build pipeline. Strongest — the build output goes to dist/, the bucket only sees dist/:

git clone "$REPO" src/
cd src && build && cd ..
# build/ is the source-of-truth checkout
# dist/ is the artefact-only output
aws s3 sync dist/ s3://acme-marketing-site/ --delete

Option C is the right pattern for any non-trivial pipeline because it forces the team to be explicit about what is and isn't deployable. The artefact set is a separate output, not a filtered view of the source tree.

The Prevention Lesson

Three layers prevent recurrence:

Pre-deploy artefact scan. Before aws s3 sync runs, the deployment script scans the build directory for known-unsafe paths and aborts if any are present. A small helper, ~20 lines:

unsafe_paths=$(find dist/ -type d -name '.git' -o -name '.svn' \
  -o -name '.env' -o -name '.aws')
if [ -n "$unsafe_paths" ]; then
  echo "ERROR: unsafe artefacts in dist/:" >&2
  echo "$unsafe_paths" >&2
  exit 1
fi
aws s3 sync dist/ s3://...

The check runs in the same script that does the deploy, so the gate is in the right place.

Post-deploy invariant check. stave apply runs against the post-deploy observation snapshot. The observation collector includes a step that probes the bucket for known-unsafe path patterns and emits exposed_repo_artifacts: true/false. The example shipped with this article is the template with the same predicate, same exit code 3 for any regression.

.gitignore + secret scanning. Upstream of all of this: a .gitignore that includes .env, *.key, credentials*, and a pre-commit secret-scanner that prevents the secrets from ever reaching .git/ in the first place. This is the layer that handles the "secrets in old commits even after git rm" failure mode. If the secret was never committed, the .git/ disclosure has nothing of value to reveal.

Checklist

[ ] Deployment scripts use git archive or a separate dist/ directory; git clone output never reaches aws s3 sync
[ ] Pre-deploy script scans the artefact directory for .git/, .svn/, .env, .aws/, .ssh/ and aborts on any hit
[ ] stave apply runs in CI against post-deploy observations; PRs that introduce a public bucket with exposed_repo_artifacts: true fail the gate
[ ] Repo-level secret scanning prevents .env / credential files from being committed in the first place
[ ] Quarterly bucket inventory check looks for any public bucket with .git/ paths in its key set (catches drift introduced outside the deployment pipeline)

The bucket was always going to be public. The marketing site is for the public. The bug was that public got applied to one more directory than the team meant.

The example at stave/examples/s3-dotgit-readable/ is a self-contained Go program that loads two fixture snapshots, runs pkg/stave.Apply, asserts that CTL.S3.REPO.ARTIFACT.001 fires on the .git-exposed fixture and is silent on the cleaned one, and exits zero when both assertions hold. The remediation in the after fixture leaves public_read: true on purpose where the bucket is intentionally public; only the artefact paths needed removal. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, with no cloud credentials.

When an Upload Form Becomes a Foothold: Broad S3 Write Scope

Bala Paranj — Sun, 27 Sep 2026 12:47:03 +0000

A signed POST form is the standard pattern for letting a browser upload a file directly to S3 without routing the bytes through your servers. When it works, it works beautifully. When the policy authorising the POST is too broad, every signed URL the server hands out is a write primitive on the entire bucket prefix.

Four HackerOne reports describe the same shape:

Shopify 93691 — signed upload policy used starts-with $key files/ instead of an exact key.
Shopify 98819 — authenticated S3 read paired with broad policy-write scope; the policy could be mutated by anyone authenticated.
BCM 764243 — bucket-level write scope too broad; one foothold became a supply-chain implant point.
Shopify 94502 — multi-bucket exposure with public read/list/write across several keys.

All four ship the same operational shape: an upload feature, a hurry, a policy that works because it doesn't reject valid uploads and silently accepts every other key under the prefix.

Broad Write Scope

A signed POST policy from a Rails / Express / Django controller looks something like this:

upload_policy = {
    "expiration": "2026-01-09T00:00:00Z",
    "conditions": [
        {"bucket": "acme-uploads"},
        ["starts-with", "$key", "files/"],   # ← the problem
        {"acl": "private"},
        ["content-length-range", 0, 10485760],
    ]
}

["starts-with", "$key", "files/"] is the line that breaks the model. It says: "the user can upload to any key that starts with files/." That includes:

files/abc-uuid/photo.png — what the application expects.
files/admin.html — fine for the policy, parsed by whatever serves assets.acme.example/admin.html.
files/../etc/passwd — fine for the policy, problematic if any downstream code naïvely joins the key to a filesystem path.
files/customer-data-dump.csv — fine for the policy, potentially overwriting an unrelated object.

The right policy uses exact match, not prefix match, binding each signed POST to one specific key the server generates server-side:

key = f"files/{user_id}/{uuid.uuid4()}/{filename}"
upload_policy = {
    ...
    "conditions": [
        {"bucket": "acme-uploads"},
        {"key": key},                       # exact-match condition
        ...
    ]
}

The conceptual difference: prefix policies admit a set of keys; exact policies admit a single key. The set is hard to bound; the single key is trivially bounded.

The System Invariant

In Stave's observation schema, the policy itself is modelled as a separate asset s3_upload_policy because the vulnerability lives in the policy contract, not in the bucket:

{
  "id": "acme-uploads-signed-policy",
  "type": "s3_upload_policy",
  "vendor": "aws",
  "properties": {
    "type": "s3_upload_policy",
    "s3_upload": {
      "bucket": "acme-uploads",
      "operation": "write",
      "allowed_key_mode": "prefix",
      "allowed_prefix": "files/"
    }
  }
}

allowed_key_mode carries the engine's verdict ("prefix" vs "exact"); allowed_prefix / allowed_key carries the evidence which is the actual prefix or exact key the policy admits.

The Stave Control

id: CTL.S3.WRITE.SCOPE.001
name: S3 Signed Upload Must Bind To Exact Object Key
severity: high
unsafe_predicate:
  all:
    - field: type
      op: eq
      value: "s3_upload_policy"
    - field: properties.s3_upload.operation
      op: eq
      value: "write"
    - field: properties.s3_upload.allowed_key_mode
      op: eq
      value: "prefix"

CEL fires whenever the upload policy is in prefix mode for a write operation. That is the state assertion — "this configuration is unsafe."

Why CEL is Not Enough Here

CEL answers a yes/no question: is the configuration in the unsafe state? It does not answer the natural follow-up: if it is, what's the impact. What specific keys can an attacker reach that the application doesn't intend?

That second question is reachability. A search over the key space, not a fold over the property bag. That's where Z3 earns its complexity.

The previous articles in the series stopped at CEL because the patterns were state assertions: "is the bucket public?", "does this reference dangle?" Those are fold-over-properties questions. "Which specific keys does this policy admit that the app doesn't want?" is a different shape.

The Z3 Witness Model

The companion Z3 program at stave/examples/s3-broad-write-scope/z3prove/ reads the same fixture and encodes the question:

The model uses three named witness keys, encoded as integer constants:

0 = "files/abc-uuid/photo.png"   (intended — UUID-prefixed)
1 = "files/admin.html"            (admitted by prefix, NOT intended)
2 = "files/../etc/passwd"         (admitted, path traversal)

The constraints:

admitted = key ∈ admitted_set       (prefix mode → {0,1,2}; exact mode → {0})
intended = (key == 0)
unsafe   = admitted AND NOT intended

The solver discharges the conjecture against the configuration data the fixture provides:

=== before (prefix-mode) ===
  policy mode: prefix   exemplar: files/*
  admitted set: [files/abc-uuid/photo.png files/admin.html files/../etc/passwd]
  intended set: ["files/abc-uuid/photo.png"]
  verdict: SAT — witness key "files/admin.html" is admitted but unintended

SAT, with a concrete witness files/admin.html. The prefix policy admits this key (it starts with files/); the application's UUID-prefixed key generator never produces it. The witness is the answer to "what specific filename can a tester write to?"

After the policy is scoped to exact match:

=== after  (exact-mode) ===
  policy mode: exact   exemplar: files/abc-uuid/photo.png
  admitted set: [files/abc-uuid/photo.png]
  intended set: ["files/abc-uuid/photo.png"]
  verdict: UNSAT — every admitted key is intended

UNSAT. There is no key the policy admits that the application does not intend. The remediation provably closes the class.

Why Witness Extraction is The Stronger Claim

Pen-test reports often end with "this configuration is permissive." The customer asks "permissive how?" A list of synthetic example keys is the answer that turns "permissive" into actionable concrete impact. CEL produces the first; Z3 produces the second.

Z3's contribution for this small enum it is straightforward search. The encoding is declarative: the program describes the admitted set and the intended set, and lets the solver find the gap. Adding a new witness key (e.g., files/customer-12345/private-data.json) is a single line. Generalising to a different attack class (write to files/<other-tenant>/...) is a different predicate, not a different program.

The Remediation

Two changes in the application's upload-controller code:

 def signed_upload_policy(user_id, filename):
-    key = f"files/{filename}"
+    key = f"files/{user_id}/{uuid.uuid4()}/{filename}"
     return s3.generate_presigned_post(
         Bucket="acme-uploads",
         Key=key,
         Conditions=[
-            ["starts-with", "$key", "files/"],
+            {"key": key},                 # exact match
             ["content-length-range", 0, 10485760],
         ],
     )

The first change widens the key namespace per upload (UUID in the path) so two uploads cannot collide. The second change replaces the prefix condition with an exact match. The policy now admits the key the server generated.

Verify with aws s3api put-bucket-policy --policy file://... on a stricter resource-policy too, if you want belt-and-braces enforcement that an attacker who somehow gets a broader signed URL still cannot write outside their UUID prefix:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "TenantScopedWrites",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:role/UploadProxy"},
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::acme-uploads/files/${aws:userid}/*",
    "Condition": {
      "StringEquals": {
        "s3:x-amz-server-side-encryption": "aws:kms"
      }
    }
  }]
}

The bucket policy and the signed-URL policy are two independent layers; either alone closes most of the attack surface, both together close it under attacker assumptions that get more aggressive.

The Prevention Lesson

The four reports happened because the upload controller was written in a hurry against a feature deadline, the signed URL worked in QA, and nobody re-read the conditions before shipping. Three layers prevent recurrence:

Library default. The application's signed-URL helper takes a key parameter (not a prefix) and rejects calls that pass a prefix-shaped value. The library's API makes the unsafe form syntactically harder to express. This is the highest-leverage fix. It converts every future upload feature into a safe one by construction.

CI invariant check. stave apply runs on the pre-merge observation snapshot. A PR that introduces an s3_upload_policy asset with allowed_key_mode: "prefix" fails CI. The example shipped with this article is the template with the same predicate and exit code 3.

Z3 mode in code review. For changes that do deliberately use prefix conditions (rare — public-archive buckets, multi-key bulk uploads), the review template asks the author to enumerate "admitted keys outside the intended set" with the same reasoning the Z3 program automates. The author either produces a clean witness-free justification or reaches for a tighter policy.

The Z3 mode is not a CI gate. It's a thinking discipline. The witness extraction in the example "think like Z3" looks like in code: write down the set of admitted keys and the set of intended keys, find the gap. The solver removes the manual enumeration; the discipline removes the policy.

Checklist

Signed-URL helper rejects prefix conditions on $key; only exact-key conditions are accepted
Server-side key generation uses a UUID layer so two uploads cannot collide on key
stave apply runs in CI and blocks PRs that introduce s3_upload_policy assets in prefix mode
Bucket-level policy carries a tenant-scoped Resource condition so a broader signed URL still cannot write outside its tenant prefix
Code review for new upload features enumerates admitted keys outside the intended set (the "Z3 mode" check) and either produces a witness-free justification or tightens the policy

The four HackerOne reports differ in industry, in feature, in the data their broad write scope eventually reached. The policy line that exposed it was identical: a starts-with where an exact match belonged.

The example at s3-broad-write-scope is two binaries side by side: a CEL evaluation via pkg/stave.Apply (asserts the unsafe state) and a Z3 SAT prover (extracts a concrete witness key the policy admits but the application does not intend). The Z3 binary lives in a sibling Go module so its libz3 link stays out of Stave's main vendored tree. Stave detects this pattern and 31 other H1-grounded scenarios from local AWS configuration snapshots, with no cloud credentials.

You Don't Own Your CloudFront Subdomain Until You Register the Distribution

Bala Paranj — Sat, 26 Sep 2026 13:32:04 +0000

A researcher checked cdn.grab.com in a browser. The page did not load, because the CloudFront distribution that the CNAME pointed to was not registered in any AWS account. The researcher registered it in their own account. Then cdn.grab.com was serving their content.

This is a gap in how AWS CloudFront distribution ownership works, and it shows up repeatedly across companies that use CloudFront for CDN delivery.

How CloudFront Subdomain Takeover Works

When you create a CloudFront distribution, AWS assigns it a domain name like d1234abcd5678.cloudfront.net. You then create a CNAME in your DNS pointing your branded subdomain to that distribution:

cdn.grab.com  CNAME  d1234abcd5678.cloudfront.net

When you delete the CloudFront distribution for any reasons such as migrating CDN providers, cleaning up old infrastructure, or decommissioning a product the distribution is gone. The CNAME in your DNS is still present.

cdn.grab.com still resolves. It still points to *.cloudfront.net. But the distribution at that endpoint no longer exists in your account.

Anyone can create a new CloudFront distribution. CloudFront distribution domain names follow a predictable format. If an attacker creates a distribution and configures it to respond to cdn.grab.com as an alternate domain name which is a standard CloudFront feature, CloudFront will serve their content when cdn.grab.com is requested.

@todayisnew did this. They registered the distribution, configured it to respond to cdn.grab.com, and served a PoC page at http://cdn.grab.com/index.html. Grab's security team triaged it within hours and confirmed it valid.

Why This is Worse Than Third-Party SaaS Takeover

The previous article in this series covered subdomain takeovers via third-party services such as Vercel, Squarespace, Brandpad, Unbounce. Those services have free tiers. An attacker signs up for free and claims the subdomain.

CloudFront distributions are different in two ways.

First, the trust level is higher. A subdomain like cdn.grab.com is serving static assets such as JavaScript files, images, CSS, potentially SDKs. When an attacker controls cdn.grab.com, they are not just serving a phishing page. They are serving whatever the Grab application loads from that CDN endpoint. If the application loads JavaScript from cdn.grab.com/app.js, that JavaScript now comes from the attacker.

Second, the HTTPS certificate is valid. CloudFront provides SSL certificates via ACM. When an attacker registers a distribution with cdn.grab.com as an alternate domain, they can provision a certificate for cdn.grab.com through CloudFront's certificate management. The browser sees a valid HTTPS connection to cdn.grab.com. There is no certificate warning. The lock icon is green.

The combination of trusted CDN subdomain, valid HTTPS certificate, serving attacker-controlled JavaScript is a supply chain attack vector, not just a phishing risk.

The Attack Path

1. Attacker finds cdn.grab.com CNAME pointing to *.cloudfront.net
2. Attacker verifies the distribution is unclaimed
   (curl -I https://cdn.grab.com → connection error or CloudFront default)
3. Attacker creates CloudFront distribution in their AWS account
4. Attacker adds cdn.grab.com as an alternate domain name
5. CloudFront provisions a certificate for cdn.grab.com
6. cdn.grab.com now serves attacker content over valid HTTPS
7. Any application loading assets from cdn.grab.com
   now loads attacker-controlled content

Step 3 costs money. CloudFront is not free. But the attacker controls a CDN subdomain of a major company with a valid certificate. The economics favor the attacker in any targeted scenario.

The System Invariant

The invariant is the same as every subdomain takeover, stated for CloudFront:

Observable in an infrastructure snapshot: the DNS record points to *.cloudfront.net, and the corresponding CloudFront distribution exists in the account's resource inventory. If the distribution does not exist, it is a violation.

This is detectable without making a live HTTP request to the endpoint. The snapshot contains the DNS records and the CloudFront distribution inventory. Cross-referencing them is a set membership check.

What Stave Detects

CTL.DNS.DANGLING.002    CRITICAL  initial_access
  "DNS CNAME Must Not Point to Unclaimed CloudFront Distribution"

  Fires when: a DNS CNAME record points to *.cloudfront.net
  and no CloudFront distribution in the account inventory
  has a matching alternate domain name or distribution domain.

The control evaluates two fields from the snapshot:

DNS records, any CNAME ending in .cloudfront.net
CloudFront distribution inventory, the list of distributions and their alternate domain names

If a CNAME target has no matching distribution in the account, the control fires. No live HTTP request. No CloudFront API call. Just a cross-reference between two lists in the snapshot.

Running the Grab scenario:

VERDICT: COVERED

CTL.DNS.DANGLING.002    CRITICAL  initial_access
  cdn.grab.com → *.cloudfront.net
  No CloudFront distribution found with alternate domain cdn.grab.com
  or matching distribution domain in account inventory.

Compound chains:
  shadow_api_exposure     confidence: 1.00

The Difference from S3 Subdomain Takeover

S3 subdomain takeover works when a DNS record points to bucket-name.s3-website-region.amazonaws.com and the bucket does not exist. The attacker creates the bucket with the matching name.

CloudFront subdomain takeover works when a DNS record points to a CloudFront distribution domain and the distribution does not exist. The attacker creates a new distribution and adds the victim's subdomain as an alternate domain name.

The detection is slightly different:

S3: check if the bucket named in the CNAME endpoint exists in the account
CloudFront: check if any distribution in the account has the subdomain as an alternate domain name

Both are cross-reference checks in the snapshot. Neither requires a live request.

CTL.S3.DANGLING.ORIGIN.001 covers S3. CTL.DNS.DANGLING.002 covers CloudFront. The same snapshot assessment catches both.

Remediation

Option A: Delete the DNS record.

The CDN subdomain is no longer needed. Remove the CNAME.

# Route53 — remove the dangling CNAME
aws route53 change-resource-record-sets \
  --hosted-zone-id ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "DELETE",
      "ResourceRecordSet": {
        "Name": "cdn.example.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {"Value": "d1234abcd.cloudfront.net"}
        ]
      }
    }]
  }'

Option B: Recreate the distribution.

The CDN subdomain is still needed. Create a new CloudFront distribution, add the subdomain as an alternate domain name, provision the certificate, and restore the origin configuration.

Process fix: delete the distribution last.

When decommissioning CDN infrastructure, the order matters:

1. Remove the DNS CNAME record
2. Wait for DNS TTL to expire
3. Delete the CloudFront distribution

Deleting the distribution before removing the DNS record leaves a window, potentially days if the TTL is long where the subdomain points to nothing and is claimable.

Checklist

For any AWS account using CloudFront for CDN delivery:

Every DNS CNAME pointing to *.cloudfront.net has a corresponding distribution in the account with a matching alternate domain name
CloudFront distribution decommissioning procedure: DNS record removed before distribution deleted
CTL.DNS.DANGLING.002 runs against DNS snapshot on each infrastructure change
CloudFront distribution inventory audited against DNS records periodically
Alternate domain names on all distributions match active DNS records

The distribution you deleted is still in your DNS. Until you remove that CNAME, the subdomain is available.

The Grab cdn.grab.com CloudFront subdomain takeover was reported by @todayisnew and triaged by Grab's security team as valid within hours of submission. Stave detects unclaimed CloudFront distributions via CTL.DNS.DANGLING.002, evaluated from local infrastructure snapshots without AWS credentials or live HTTP requests.

Your Deprecated Services Are Your Weakest Doors

Bala Paranj — Fri, 25 Sep 2026 12:16:00 +0000

IaC tools don't track AWS service deprecation. Terraform will deploy a resource on a frozen service forever. So deprecation tracking must be a
verifiable property in your CI/CD pipeline.

AWS deprecated 20+ services and features on June 30, 2026. One of them (Simple AD) provides authentication to IAM Identity Center. Another (Bedrock Agents Classic) runs AI agent workloads with 14 distinct security controls. A third (SageMaker Role Manager) is the tool AWS recommends for scoping IAM roles which is the tool we'd tell you to use in a remediation guide.

How many of these are still running in your accounts right now?

Terraform, CloudFormation and CDK doesn't know. They'll deploy resources on deprecated services anytime without a warning.

The deprecation nobody noticed

The June 30, 2026 AWS Service Availability update lists ~25 services entering maintenance, sunset, or end-of-support. The announcement is a blog post. There's no API that returns "this service is deprecated." No tag on the resource. No CloudTrail event.

The services that matter for security:

Simple AD: no MFA support, no trust relationships with your authentication plane on a frozen directory
Bedrock Agents Classic: 14 security controls, frozen, no new patches
SageMaker Role Manager: the scoping tool itself is deprecated. The roles it created stay overprivileged longer
IoT Device Defender Detect: your IoT monitoring just stopped evolving
SageMaker Model Monitor: your model drift detection is frozen

Why IaC doesn't help

Blog post published → someone reads it (maybe)
Ticket created → someone files a migration task (maybe)
Ticket prioritized → it sits behind feature work (always)
Meanwhile, terraform apply keeps deploying resources on the deprecated service without a warning
New team member joins, doesn't know about the deprecation, creates more resources on the deprecated service
18 months later: the service is still running, accumulating permissions, receiving no security patches

The IaC tool's job is to make the current configuration converge to the declared state. It has no concept of "this declared state is going away."

Deprecation as shadow IT

A deprecated service in maintenance mode is the worst kind of shadow IT:

Sanctioned (AWS still runs it)
Visible (it's in the console)
Costs money (you're paying for it)
Silently stops receiving security improvements

Nobody thinks of it as shadow IT because it's official. But from the attacker's perspective, it's a service that won't get security patches, won't benefit from AWS's evolving defaults, and sits in the account with permissions nobody reviews because "it's going away."

Making deprecation a verifiable property

The Stave approach:

A control fires on every scan when a resource is deployed on a deprecated service
The finding doesn't get lost in a backlog. It's a property that fails verification until the state changes
It runs in CI/CD: stave ci gate blocks deployment of new resources on deprecated services
It runs continuously: stave apply catches existing resources that haven't been migrated
The remediation text links directly to the AWS migration guide

The practitioner sees the finding every pipeline run. They can choose to tackle it when they can. But it never disappears from the output until the migration is done. It's a built-in reminder, not a ticket.

Section 5 — Temporal risk: a new dimension

Most security tools measure spatial risk: "this configuration is bad right now." Deprecation introduces temporal risk: "this configuration is getting worse over time."

A Simple AD directory providing authentication today has the same security properties it had yesterday. But it's one day closer to the point where
AWS stops patching it. The risk accumulates.

Stave is the only tool that knows the difference between "this configuration is valid" and "this configuration is valid for now." The deprecation timeline isn't metadata. It's a security property with a deadline.

The compound: spatial + temporal

The strongest finding: a resource that's simultaneously near a compound breach path AND running on a deprecated service.

Example: A Simple AD directory (deprecated, no MFA support) providing authentication to IAM Identity Center, where session duration is 12 hours. Spatial risk: the authentication chain is near a compound finding. Temporal risk: the directory service stops getting security improvements. Each dimension alone is a finding. Together they describe a resource that's getting weaker over time while already close to a breach path.

Your deprecated services are your weakest doors. Because they're the doors that stop getting locks.

Quick Facts:

25+ services in the June 2026 deprecation wave
14 Bedrock Agents Classic controls affected
5 Simple AD controls affected
4 IoT Device Defender Detect controls affected
2 + 1 chain for SageMaker Role Manager
2 for SageMaker Model Monitor
Zero IaC tools provide deprecation warnings
Zero AWS APIs return "this service is deprecated"

DEV Community: Bala Paranj

What SCPs Can't Verify, Snapshots Can

The request context is incomplete

The workaround is a governance band-aid

The snapshot contains the truth

Why this gap is structural, not accidental

The pattern generalizes

The gap between prevention and verification

An AWS library stored SQS payloads in S3 without encryption for 4 years and nobody's tooling caught it

Why this matters

What Stave detects

Missing encryption at rest

Missing KMS customer-managed key

Duration tracking

Compound risk: unencrypted + data classification

The deeper problem: application-created buckets

The timeline problem

What this means for HIPAA programs

"Our auditor wants proof of S3 compliance, what do we give them?" Automating HIPAA S3 evidence for your auditor

The Reddit Question

What Auditors Want

How Stave Produces Evidence

CI Pipeline Integration

How this relates to existing compliance mods

Your Lambda Has Admin on S3 and Doesn't Know It

What s3:* Grants

The System Invariant

The Stave Control

Why CEL is Not Enough

The Z3 Witness Model

The CI Gate

The Remediation

The Prevention Lesson

Checklist

The $1.5B Wildcard: When company-frontend-* Matches Production

The compound finding — undetectable supply chain

Why this is the harder case

The fix is one character

I Ran a Security Scanner Against Mastodon, Discourse, and Chatwoot's AWS Defaults. Here's What I Found.

The Methodology

Finding #1: Mastodon Defaults to public-read

Finding #2: Discourse Does the Same Thing, But Through Admin Settings

Finding #3: Chatwoot Gets One Thing Right

The 15 Findings Every Rails-on-S3 Deployer Shares

Critical

High

Medium

Low

Why This Happens: The Rails-AWS Gap

How Stave Works

What You Should Do

The Scorecard

Methodology Notes

Your Deny Policy Blocks Six Privesc Paths. There Are Nine.

Compute-launch vector

The Z3 setup

Three findings on the writeup config

Finding 1: deny coverage gap

Finding 2: PassRole reaches an admin-equivalent role

Finding 3: the compound chain

The remediated config and the residual

The architectural fix the deny list doesn't make

What pattern-matching tools miss

Checklist

Why `Resource: bucket/${tenant}/*` is Not Enough

The Layer Boundary

The System Invariant

The Stave Control

Why CEL is Not Enough

The Z3 Witness Model

Why This Pattern Hides

The Remediation

The Prevention Lesson

Checklist

Your S3 bucket is encrypted at rest. It is not encrypted in transit by default.

The configuration that fails

In transit

Why this hides

The system invariant

What Stave detects

What `s3:*` Grants

The $1.5B Wildcard: When `company-frontend-*` Matches Production