Every scanner checks what exists. Nobody checks what's missing

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3862804) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Bala Paranj Posted on Apr 28 Every scanner checks what exists. Nobody checks what's missing #aws #cloud #devops #security When cloud resources are deleted, the references to them persist — in IAM policies, event triggers, compute configs, and trust relationships. These orphaned references create exploitable gaps that no per-resource scanner can detect. The finding doesn't live on any single resource. It lives in the space between what's referenced and what exists. The assumption every scanner makes Cloud security scanners work by iterating over resources. For each S3 bucket, check its configuration. For each IAM role, check its policies. For each security group, check its rules. The resource exists. The scanner examines it. The finding describes what's wrong with it. This is a reasonable architecture. It covers the vast majority of cloud security risks. Misconfigured resources — public buckets, overprivileged roles, open security groups — are the bread and butter of cloud security posture management. But every scanner built on this architecture shares a blind spot: when a resource is deleted, it disappears from the scan. The scanner has nothing to examine. The resource is gone. The references to it are not. What deletion leaves behind Cloud infrastructure is a graph of interconnected references. An IAM policy doesn't exist in isolation — it references S3 buckets, KMS keys, Lambda functions, and SQS queues by ARN. An EventBridge rule references a Lambda function as its target. A CloudWatch alarm references an SNS topic as its notification action. An ECS task definition references an ECR image by tag and a Secrets Manager secret by ARN. When any of these referenced resources is deleted, the reference persists. The IAM policy still says "Allow PutObject to arn:aws:s3:::prod-audit-logs." The EventBridge rule still targets the Lambda function. The CloudWatch alarm still notifies the SNS topic. The ECS task definition still pulls the image. The resource is gone. The references are not. And depending on the resource type, those references may be actively exploitable. Three classes of orphaned references Not every orphaned reference is equally dangerous. The risk depends on what the reference does and whether the deleted resource's identity is reclaimable. Class 1: Reclaimable names with active permissions S3 bucket names are globally unique across all AWS accounts. When a bucket is deleted, its name becomes available for registration by anyone, anywhere. An IAM policy that grants PutObject to that bucket name is now granting write access to whoever claims it next. This is the most dangerous class. The organization's systems are actively trying to send data — audit logs, backups, application output — to a resource name that an attacker can claim. The attacker registers the bucket, configures it to accept writes, and data starts flowing. The Lambda function writing audit logs doesn't error. The S3 client library doesn't warn. The write succeeds. It goes to the wrong place. A healthcare organization's HIPAA audit logs — the very records required to prove compliance — could be delivered to an attacker's bucket. The organization continues…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.