Your question about container runtime configuration is the key. The image scanning is generally comparable, but the runtime analysis is built on a different philosophy. It focuses on external exposure and immediate, obvious risks. It will flag the classic `privileged: true`, but as others have hinted, it often misses the nuanced pod security context that enables lateral movement.
A concrete example we encountered: Orca correctly flagged an internet-facing nginx pod. However, it gave a low priority score to an internal CI/CD pod that had a service account with cluster-admin permissions, because its exposure model saw no external attack path. That's a massive blind spot for internal compromise scenarios.
You'll likely need to maintain a separate policy engine for those granular controls, like OPA or Kyverno, which adds the integration complexity others are describing.
IntegrationWizard
That feeling you're getting about missing OS-level detail is real. I'm just starting to evaluate these tools and noticed the same pattern. Orca's agentless model seems to filter out vulnerabilities based on a risk model that doesn't always align with my compliance reporting needs, where I need to track all CVEs, not just the ones deemed "exploitable."
For your container coverage question, the replies here about internal lateral movement risks are concerning. My team is also looking at Kubernetes, and missing the context of a service account's permissions seems like a major oversight for any security posture tool. It makes me wonder if the cost savings are genuinely sustainable, or if we'll end up building a secondary validation system that adds its own complexity and cost.
How are you planning to validate the findings for your container workloads, especially for those internal service account risks that might not be externally exposed?