An empty result is not an all clear

A recent infrastructure audit revealed that an S3 audit tool missed detecting some buckets as unencrypted, leading to a false sense of security. The tool, which ran across the account, found two issues on S3, but it lacked the necessary permissions to retrieve encryption configurations for 14 buckets. The tool incorrectly assigned encrypted: false to all buckets, including those that were actually encrypted.

This issue, which affected multiple infrastructure scanners, stemmed from a bug in how the tool handled rejected API calls.

When an API call failed, the tool treated it as if the bucket did not exist or had no encryption configuration, even when the call was rejected due to insufficient permissions. This resulted in the tool generating false findings, which appeared identical to real issues and were treated as such by downstream systems. The true unencrypted buckets remained undetected, creating a false negative that could mislead engineers and security teams.

To resolve this issue, the boolean field used to represent encryption status needed to be expanded to include a third state, null, to indicate that the encryption status could not be determined. This change ensured that the analyzer could distinguish between an observation (versioning turned on) and an error (failed to read the bucket configuration). By properly identifying and handling these rejections, the tool could accurately report unencrypted buckets, preventing false negatives and false positives.