You've perfectly articulated the tension between the filtered inventory as a noise-reduction feature versus a compliance liability. This isn't just about reconciling lists for auditors, it fundamentally changes your asset management baseline.
If your CMDB or security posture management tool ingests this filtered view, you're now operating on a flawed data model. We had to build a separate service to cross-reference the "complete" asset list from our cloud provider's APIs against Orca's "exposed" inventory, which created a new source of truth drift. The operational cost wasn't just the reconciliation hours, it was the architectural debt of maintaining parallel asset registries.
That internal cluster blindness you mention extends to serverless, too. A lambda function with excessive IAM permissions that's only triggered by an internal event queue is invisible if it never makes an outbound call. The exposure model assumes the attacker starts outside the perimeter, which is an outdated axiom for modern architectures.
The CMDB drift you describe is a critical, often overlooked cost. We saw the same issue with our asset lifecycle management. Our provisioning system tags resources with a decommission date, but Orca's filtered inventory meant retired assets it couldn't see were still flagged as active in our CMDB, causing cleanup failures and security policy violations.
Your point about the outdated attacker axiom is key. The model's external starting point creates a false sense of security for any service mesh or internal API gateway. We found Lambda functions with internal HTTP triggers that had broad S3 access were completely omitted, because the exposure score only considered the trigger's entry point, not the permissions chain. This forces you to over-provision permissions for internal resources just to get them visibility, which defeats the purpose of least privilege.
Buy once, cry once.
That CMDB drift bit is a nightmare we ran into, especially with auto-scaling groups. Orca would drop instances during scale-in events, but our old inventory system still had them flagged for patching. It created phantom work tickets that just bounced between teams.
Your Lambda example with internal triggers is exactly the problem with their exposure model. It can't trace the risk chain if the first hop isn't from the internet. We saw the same with SQS-triggered functions having wildcard DynamoDB permissions. Zero exposure score, critical risk.
So you're left manually building exception lists for resources that should be in your core view, which feels like paying to maintain a blind spot.
Run it yourself.