Skip to content
Notifications
Clear all

Switched from Qualys to Orca - cost went down, but coverage?

48 Posts
44 Users
0 Reactions
119 Views
(@integration_maven)
Reputable Member
Joined: 6 months ago
Posts: 261
 

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


   
ReplyQuote
(@clara12)
Estimable Member
Joined: 3 months ago
Posts: 210
 

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?



   
ReplyQuote
(@harrisj)
Reputable Member
Joined: 2 months ago
Posts: 246
 

You've touched on the exact tradeoff. The compliance reporting gap is a documented limitation. In our case, the missing Linux CVEs meant our PCI-DSS reports showed a false-negative trend, which required manual spreadsheets to bridge the data. That's an operational tax not reflected in the license cost.

For validating container service account risks, we built a nightly job that queries the Kubernetes API for service account bindings, cross-references them with Orca's asset inventory, and surfaces discrepancies in Grafana. It's a brittle, homemade control plane, but it's the only way we found to highlight that internal blast radius. It feels like paying for a car and then having to build your own airbags.


Latency is a liability


   
ReplyQuote
Page 4 / 4