That reporting failure is the exact pain point I hit with our patch management system. Our Ansible playbooks would fail because they expected a complete asset inventory, which Orca's filtered view doesn't provide.
Your sidecar example is perfect, and it extends to database permissions. We had a reporting container with excessive Postgres access, and like your logging sidecar, it scored low despite being a major lateral movement risk. It's a fundamental mismatch between an exposure-focused model and an identity-focused threat model. You can't fix what you can't see in the report.
Latency is the enemy, but consistency is the goal.
That 40% saving is just the first invoice. The real bill comes later when you have to bolt on a second tool to cover what Orca misses, like those low-sev CVEs in dev environments. You're trading a known cost for an unknown coverage gap.
Their runtime analysis for containers is about cloud adjacency, not cluster security. It'll find a container attached to a public IP, but it won't catch a pod running as root with a wild service account. If your policy needs that internal view, you're already in the hole.
Your stack is too complicated.
That's a solid way to put it. So the risk is you get used to the clean view, stop looking for those internal issues, and then get surprised by a breach that moved laterally. It's a coverage model that works until your threat model includes insider risk or compromised credentials.
How do you even validate that coverage gap before an incident?