Every security scanner examines resources that exist. Nobody checks whether the resources your IAM policies reference actually exist. A deleted S3 bucket name referenced in an active policy is a structural hole — the permission is live, the resource is gone, and the name is reclaimable by any attacker. The absence is the evidence.
In Arthur Conan Doyle's Silver Blaze, a prize racehorse is stolen from a guarded stable. Scotland Yard investigates the crime scene, interviews witnesses, examines evidence. They focus on what happened — what they can see, measure, and catalog.
Sherlock Holmes solves the case by noticing what didn't happen.
Is there any point to which you would wish to draw my attention?
To the curious incident of the dog in the night-time.
The dog did nothing in the night-time.
That was the curious incident.
The guard dog should have barked at an intruder entering the stable. It didn't. Therefore the person who took the horse wasn't a stranger. The dog knew them. Every investigator examined the evidence that was present. Holmes noticed the evidence that was absent.
Cloud security scanners examine resources that exist. They check properties, configurations, and permissions on things that are there:
- Is this S3 bucket public? Check the bucket.
- Is this RDS instance encrypted? Check the instance.
- Is this IAM role over-privileged? Check the role.
- Is this security group open? Check the security group.
Every check follows the same pattern: find a resource, read its configuration, evaluate a predicate. The resource exists. The scanner examines it. The finding describes what's wrong with it.
This is Scotland Yard examining the crime scene. Thorough, methodical, and looking at everything that's there.
What scanners don't look at:
An IAM policy says: "Allow PutObject to arn:aws:s3:::prod-audit-logs."
Every scanner checks the policy's permissions. Is it too broad? Does it grant admin access? Does it follow least privilege? They examine the policy — the thing that exists.
Nobody checks whether prod-audit-logs exists.
The bucket was deleted six months ago during a migration. The policy wasn't updated. The permission is active. The resource is gone. The ARN in the policy points at nothing.
This is the dog that didn't bark. The resource should exist. It doesn't. The absence is the evidence.
S3 bucket names are globally unique across all AWS accounts. When a bucket is deleted, its name becomes available for registration by anyone. Any AWS account, anywhere in the world, can create a bucket with that exact name.
The IAM policy still says "Allow PutObject to prod-audit-logs." The Lambda function that writes audit logs still runs every hour. It calls PutObject on prod-audit-logs. If nobody owns that bucket, the write fails silently. If an attacker registers the bucket name, the write succeeds — to the attacker's bucket.
The organization's audit logs — potentially containing PHI, financial records, user activity, or compliance evidence — begin flowing to an attacker-controlled destination. The Lambda function doesn't error. The CloudWatch metrics look normal. The data delivery succeeds. It just goes to the wrong place.
The organization is generating compliance evidence and delivering it to an adversary.
Not every missing resource is equally dangerous. The risk depends on what the policy allows and whether the resource name is reclaimable.
Tier 1: Any dangling reference. An IAM policy references a resource ARN that doesn't exist in the current inventory. The permission is active, the resource is absent. This is a structural hole — the policy's intent no longer matches reality. Maybe the resource was deleted intentionally and the policy cleanup was forgotten. Maybe the resource was renamed. Maybe it never existed (typo in the policy). Regardless, the permission points at nothing. Severity: high.
Tier 2: Write permission to a reclaimable name. The policy grants PutObject, SendMessage, Publish, or other write actions to a resource name that an attacker can claim. This isn't a latent risk. The organization's systems are actively trying to send data to this destination. The attacker claims the name and the data starts arriving. Severity: critical. This is the exfiltration tier.
Tier 3: KMS key reference to a deleted key. The policy grants kms:Decrypt or kms:Encrypt on a key that's been scheduled for deletion or already deleted. KMS key ARNs include random IDs and can't be reclaimed by another account — the risk is operational, not exfiltration. Systems configured to encrypt with a deleted key either fail or fall back to unencrypted writes. The policy maintains the illusion that encryption is active. An auditor reads the policy and sees encryption permissions. The key behind those permissions is gone. Severity: high.
The structural limitation isn't that scanners are poorly built. It's that the finding doesn't live on any single resource.
A per-resource scanner iterates through resources: for each S3 bucket, check its configuration. For each IAM role, check its policies. For each EC2 instance, check its security group.
A ghost reference finding lives in the gap between two inventories: the set of ARNs in IAM policies and the set of resources that actually exist. The finding is the difference between these two sets. No single resource carries it. The bucket doesn't exist to be scanned. The policy exists but looks normal — it has valid JSON, well-formed ARNs, and reasonable permissions. The problem is only visible when you compare the policy's ARNs against the resource inventory and notice an ARN that doesn't resolve.
This is cross-inventory reasoning. The scanner must compare two datasets and notice what's in one but not the other. Per-resource scanners don't do this because their architecture processes one resource at a time. The dog that didn't bark is invisible to any investigator who only examines witnesses who showed up.
The detection requires three inputs:
Input 1: Policy ARN extraction. Parse every Allow statement in every IAM policy (user policies, group policies, role policies, managed and inline). Extract every fully-qualified, non-wildcard ARN. Wildcard ARNs (arn:aws:s3:::prod-*) can't be cross-referenced against the inventory — they match a pattern, not a specific resource.
Input 2: Resource inventory. Every resource the extractor collected: S3 buckets, SQS queues, SNS topics, Lambda functions, KMS keys, DynamoDB tables. Each with its ARN.
Input 3: Cross-reference. For every ARN in a policy, check whether a resource with that ARN exists in the inventory. If it doesn't, the policy references a ghost.
The finding output tells the operator what they need to act:
Finding: CTL.IAM.POLICY.GHOSTREF.002 [CRITICAL]
DEFECT:
IAM policy "AuditLogWriter" grants s3:PutObject
to arn:aws:s3:::prod-audit-logs which does not
exist in the resource inventory. The bucket name
is globally reclaimable.
INFECTION:
The Lambda function "WriteAuditLogs" executes
hourly with this policy's permissions. It calls
PutObject on prod-audit-logs. If an attacker
registers this bucket name, the function's
writes succeed — to the attacker's bucket. The
function sees no errors. The data delivery
appears normal.
FAILURE:
Silent data exfiltration. Audit logs containing
PHI are delivered to an attacker-controlled S3
bucket. The organization continues generating
compliance evidence and delivering it to an
adversary.
DELTA:
Remove arn:aws:s3:::prod-audit-logs from the
AuditLogWriter policy, or recreate the bucket
and verify ownership.
The operator reads this and understands: the policy is pointing at a bucket that doesn't exist, the bucket name can be claimed by anyone, and an active Lambda function is trying to write to it right now. The fix is immediate: either remove the dangling reference from the policy or recreate the bucket.
The ghost reference alone is dangerous. Combined with missing logging, it's invisible.
If CloudTrail data-write logging is enabled, the PutObject calls to the ghost bucket are logged — even when they fail. A security team reviewing CloudTrail can see "PutObject to prod-audit-logs failed with NoSuchBucket" and investigate. The ghost reference is discoverable through log analysis, even without the cross-inventory detection.
But if data-write logging is also disabled, the PutObject calls generate no log entries. The writes fail silently or succeed to an attacker's bucket with no observable signal. The ghost reference is invisible to the scanner AND invisible in the logs.
When the ghost reference finding co-occurs with missing write logging, the compound risk is total: the exfiltration path is open and there is no forensic trail to detect it. This is the compound chain — two independent findings that together produce a risk neither captures alone.
Ghost references aren't created by malice. They are created by mundane operational workflows:
- Team provisions an S3 bucket for audit logs
- IAM policy is written granting Lambda write access to the bucket
- Lambda function runs for months, writing logs
- Team migrates logging to a new architecture — new bucket name, new function
- Old bucket is deleted
- Old Lambda function is deleted
- Old IAM policy is... still there
Step 7 is the failure. Steps 1-6 are normal operations. The migration was successful. The new architecture works. Nobody noticed that the old policy still exists because the old policy isn't attached to anything that's actively used — or is it? Maybe a different Lambda function in a different team's account inherited the old policy through a role that was shared. Maybe a CI/CD pipeline still references the old role. Maybe the policy is attached to a group that 40 developers belong to.
The gap between resource deleted and policy updated grows with organizational complexity. In small teams, one person manages both the resource and the policy. In large organizations, different teams manage infrastructure, IAM, and applications. The resource owner deletes the resource. The IAM team doesn't know the resource was deleted. The policy persists.
Over months and years, the ghost reference count grows. Each one is a structural hole. Most are dormant. The resource type isn't globally reclaimable, or no active system references the ghost. But the write-permission ghosts pointing at reclaimable S3 bucket names are live exfiltration paths waiting for someone to notice.
Holmes didn't just notice the dog didn't bark. He deduced why it didn't bark and that deduction solved the case. The absence wasn't just a curiosity. It was the key evidence that every other investigator missed because they were looking at what was present.
Ghost resource detection works the same way. The absence of a resource behind an active IAM permission isn't a cleanup task. It's evidence of a structural security gap that no amount of per-resource scanning will find. The policy looks correct. The permissions are well-scoped. The JSON is valid. Everything present is fine. What's missing is the problem.
Every scanner on the market examines what's there. The most dangerous findings are in what isn't.
Ghost resource detection — cross-inventory reasoning about IAM policies referencing non-existent resources — is implemented in Stave, an open-source security CLI. Three controls detect dangling ARN references at escalating severity: general ghost references, write-permission exfiltration paths, and orphaned KMS key references. The finding lives in the gap between two inventories. No single resource carries it.