# An AWS library stored SQS payloads in S3 without encryption for 4 years and nobody's tooling caught it > Source: > Published: 2026-10-05 12:15:27+00:00 ✓ Human-authored analysis; AI used for formatting and proofreading. In June 2016, a user [reported](https://github.com/awslabs/amazon-sqs-java-extended-client-lib/issues/10) 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. 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. ``` # 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 ``` 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. ``` 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. 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. 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: 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 most damaging aspect of this case is the 4-year gap between discovery and fix. 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. **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](https://github.com/sufield/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`*