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

✓ Human-authored analysis; AI used for formatting and proofreading.

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:

1. 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.

2. 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.

3. 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

1. Audit application-created buckets, not just IaC-managed ones. Libraries create S3 buckets that your infrastructure tools don't see.

2. 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.

3. 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."

4. 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