Why an Empty Result in Cloud Infrastructure Scanners is Not Safe
Lessons learned from fixing data-shape bugs in Infrawise where silence does not mean security.
Stock photo for illustration only, not from the actual event
- Cloud infrastructure scanners often force a two-state boolean field to carry three states.
- S3 permission rejections cause tools to output default false values instead of actual AWS reads.
- AI coding assistants interpret empty tool outputs as verified safety, creating hidden risks.
- The fix requires introducing a null state and explicit dataHealth tracking blocks.
An infrastructure audit running across a cloud account might finish, close the ticket, and appear completely clean. However, the report often omits critical failures, such as a missing IAM role permission for s3:GetEncryptionConfiguration which caused fourteen S3 buckets to return AccessDenied errors during a release cycle in Infrawise.
The scanning tool caught the rejection, wrote encrypted: false, and moved on without flagging a real issue. Some of those fourteen buckets were encrypted while others were not, but the report could not tell the difference because the printed value was a default fallback assigned upon read failure rather than data read directly from AWS.
Stock photo for illustration only, not from the actual event
This challenge is fundamentally a data-shape bug present in almost every infrastructure scanner: a boolean field with two states being asked to carry three. The S3 extractor issues four API calls per bucket using Promise.allSettled so a single rejection does not crash the rest. Unfortunately, downstream analyzers receive versioned: false and issue recommendations for buckets whose states were never actually read.
The code fix introduces a third state to handle unread observations properly:
const versioned = versionResult.status === 'fulfilled' ? versionResult.value.Status === 'Enabled' : null;Analyzers then test explicitly for the observation rather than falsiness:
if (node.versioned === false) { /* finding */ }Null values simply fall through, generating no finding because there is nothing to report other than an unread state.
Generic error-catching wrappers fail here because certain API exceptions carry specific business meanings, such as ServerSideEncryptionConfigurationNotFoundError. Collapsing all rejections into null values trades false positives for dangerous false negatives, requiring engineers to inspect documented API behaviors call by call.
This pattern surfaces anywhere a scanner interacts with external APIs, including capped listings, synthesized nodes with missing configuration attributes, and partial service extractions where throwing away an entire service is too costly. To combat this, extractor statuses are categorized into four distinct values: ok, failed, partial, and disabled.
While human engineers waste only a few minutes shrugging off phantom findings in the console, the paradigm shifts entirely when AI coding assistants enter the pipeline via MCP. When an AI receives an empty JSON array due to a failed S3 read, it does not infer a failure; it confidently assumes all buckets are encrypted and writes infrastructure policies based on that hazardous assumption.
To solve this, tool responses now carry a dataHealth block containing explicit source lists and error statuses, ensuring that nodes originating from degraded sources remain distinct from clean infrastructure data.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment