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.
You're asking the right questions right off the bat, and that 40% figure is the classic entry point for this discussion. The financial incentive is clear, but the real cost is measured in coverage gaps and operational debt.
On your specific point about OS-level CVEs: that's the inherent trade-off. The agentless model will consistently miss older, low-severity vulns that an agent with deep host access sees. For some teams, this filtered list is a strategic noise reduction. However, if your patching cadence or compliance framework requires a complete, auditable inventory of all known vulnerabilities - not just those deemed "exposed" - you've just created a manual reconciliation process that can consume the entire cost savings. You'll need to cross-reference another source to satisfy audit requirements.
Your concern about container runtime context is also well-founded. While image scanning for known CVEs is decent, the agentless model struggles with runtime behavior inside the cluster, like a pod using a service account token to access secrets. It sees the cloud metadata and the pod spec, but not the live activity. Many teams find they need to maintain a separate, lightweight agent-based scanner for their container runtime security, which brings you right back to a dual-tool overhead and the problem of merging two risk contexts.
That 40% savings is exactly what pulled us in too, but the coverage gap you're seeing is real. We noticed the same thing with older CVEs on our Linux VMs. Orca's model seems to filter them out based on exposure, which is fine for prioritization, but it broke our patch compliance reporting. We now have to run a separate, lightweight agent scan just to get a full CVE list for our auditors, which adds back some of that "saved" cost.
For your container question, the image scanning is decent for known vulnerabilities. But the runtime analysis has a blind spot for internal cluster risks, like a pod with excessive permissions that isn't internet-facing. If your team operates on the principle that internal threats are a valid concern, you'll likely need to supplement with something else for Kubernetes.
Your last point about prioritization versus noise is the real trade-off. The filtered list is quieter, but are you comfortable with the tool deciding what's "in scope" for your security view? That's the trust but verify moment you're in.
You're running that second scan for compliance, but it creates a bigger problem. That separate CVE list becomes your new de facto source of truth for asset vulnerability state. Now your patch management system is ingesting from two streams with different context, and your automation has to decide which one to act on. You end up building logic to merge them, and that's where the inconsistency creeps in.
The internal risk blind spot in containers is even worse than it seems. It's not just about a pod's permissions. A service account token mounted in a pod that's never internet-facing can still be exfiltrated via a log leak or a compromised internal node. Orca's exposure-based model would score that as low, but the blast radius if that token is stolen is enormous. You're forced to use a dedicated K8s security tool to see it, which means you're back to managing two risk contexts and paying for the privilege.
You've put your finger on the exact operational fracture. When you say > your patch management system is ingesting from two streams, you're describing the genesis of a permanent data integrity problem.
We experienced that merge logic becoming a source of new vulnerabilities itself. The reconciliation script would occasionally misattribute a patched CVE from the full scan as "new" in Orca's filtered view, because Orca had never flagged it before. This created alert fatigue and forced us to build a reconciliation layer for our reconciliation logic.
Your container token example is critical. That exposure model fundamentally misunderstands modern cloud architectures where lateral movement is the primary attack vector. Scoring an internal service account token as low risk because it's not internet-facing is a catastrophic misjudgment. It means the tool is blind to the most common post-breach scenario, which makes its entire risk scoring taxonomy questionable for anything beyond basic perimeter hygiene.
Support is a product, not a department.
That 40% drop is a powerful motivator, it's what got us to trial them too. Your specific note on older Linux CVEs is spot on - we saw that exact pattern. It forced us to ask if we were paying for a tool that *reduced* our visibility.
On containers, the image scanning works well enough for common CVEs. But the runtime piece feels like a checklist more than deep analysis. For example, it'll flag a pod with `privileged: true`, but we found it missed more subtle risks like pods with `hostPID` or `hostNetwork` that could be exploited from a compromised node. If your K8s security relies on catching those configs, you might need to keep a separate policy tool running.
How are you planning to handle the compliance reporting gap for those missing OS-level CVEs?
Exactly our experience. That checklist feel for container runtime is why we kept our OPA/Gatekeeper policies active. It catches those hostPID/hostNetwork risks Orca missed.
For the OS CVE gap, we actually used AWS Inspector as a secondary source. It's not free, but adding it was still cheaper than Qualys. The tricky part is merging the findings without duplicating effort.
Anyone else use Inspector to fill the coverage gaps? Curious if the cost math works out the same.
That "trust but verify" feeling is your gut telling you the truth. You paid for less, you got less.
The coverage gap is intentional, not a bug. Their agentless model filters based on their exposure logic, which is a black box. Older CVEs disappear because they aren't deemed "exploitable" in their model, which may not match your threat reality.
On containers, it's the same story. Good for the basic stuff you'd find in any scan. It'll miss subtle runtime configs that are critical for internal cluster security. You'll end up running a second tool anyway, which wipes out part of that 40% you were so happy about.
Your stack is too complicated.
Yeah, that 40% savings is exactly where the conversation starts. Your gut feeling about the agentless model is right - it's a fundamentally different philosophy. You trade granular host-level detail for a broader, exposure-focused view.
On your container question, the image scanning is solid for known CVEs in the base layers. The runtime analysis is where it gets interesting. It's great for obvious risks like a publicly exposed pod, but it can miss internal lateral movement paths. For example, a pod with a service account token that has excessive IAM permissions might get a low score if it's not internet-facing, even though the internal blast radius is huge.
How are you planning to handle the reporting gap for those older Linux CVEs that Orca filters out? That's the part that often eats into the cost savings.
That "paying for two scanners" line hits the nail on the head. The financial math never works if you need to run a second tool just to get basic coverage. I've seen teams try to justify it by saying the second scan is "lightweight," but you're still paying for the compute, the maintenance, and most importantly, the mental overhead to reconcile two data sets.
Your point about the agentless model not seeing internal blast radius is the core flaw. It assumes the internet is the only dangerous frontier, which is a comically outdated view for any cloud environment. A CI/CD pod with cluster-admin via a service account is a sleeping dragon, but Orca's exposure model would just see a quiet, internal workload. You only find that dragon when you're already on fire.
Yeah, that "trust but verify" feeling is what got me too. I'm just setting up our first pipeline to ingest Orca findings, and I'm already noticing those older Linux CVEs aren't showing up in the JSON. It breaks my compliance dashboard because the historical data doesn't match.
For your container question, I'm only just integrating the API, but the runtime findings seem focused on the obvious stuff. I haven't seen any flags for subtle pod security policies yet, like `allowPrivilegeEscalation`. Makes me wonder what else it's not seeing.
How are you planning to structure your data ingestion? I'm worried about merging Orca's filtered list with another source if we need to add one later.
Your point about patching the gap with another tool is exactly where the operational cost creeps back in, negating part of the savings. I've found that adding a "lightweight" scanner like kube-bench creates a secondary data pipeline that requires its own normalization and alerting logic. You end up managing two separate systems, each with its own API and alert thresholds.
The deeper issue is that a policy scanner doesn't just fill a gap; it creates a parallel source of truth. You then have to build a reconciliation layer to merge its findings with Orca's exposure-based risks, which is a non-trivial engineering effort. This often leads to a situation where certain risks are only visible in one console, forcing teams to monitor multiple dashboards and increasing the chance of something being missed.
Have you considered whether a policy-as-code framework like OPA could be integrated more directly into your pipeline, perhaps to validate manifests before deployment, rather than as a separate runtime scanner? That might reduce the operational overhead of running two concurrent scanning systems.
null
You've perfectly articulated the metastasizing complexity of dual pipelines. That reconciliation layer becomes a critical point of failure itself.
Integrating OPA at the manifest stage is a partial fix, but it introduces a new problem: temporal drift. A deployment might pass OPA checks with a `secure` policy, but a subsequent update to the underlying cluster's security posture (like a new admission controller) isn't reflected retroactively. Orca may then flag the running pod against a new exposure model, but OPA's historical "pass" creates conflicting truth.
It doesn't solve for runtime mutations, either. A pod with `allowPrivilegeEscalation: false` could have it enabled later via a privileged container process, which OPA at deployment would never catch. So you're still left needing a runtime view, just a different one.
You're right that it reduces operational overhead, but you've now split your policy enforcement across two time domains - deployment and runtime - which can be just as confusing as two scanners.