Another day, another "beta" feature from a cloud security vendor that feels more like a checkbox for a sales deck than a finished product. I've been poking at Orca's new container image scanning in our dev and staging pipelines for the last couple of weeks, and the initial impression is... underwhelming. It feels bolted on, as if they took their existing VM scanning logic and tried to make it fit a problem that requires a fundamentally different approach.
The core issue is context, or rather, the staggering lack of it. Scanning a static image in a registry tells you about CVEs, sure. But without the runtime context—what the pod actually has permissions to do, what network policies are applied, what secrets are mounted, what the adjacent workloads are—you're only getting half the story. Orca's whole value proposition is that "side-scanning" agentless context, but that seems entirely absent in this image scanning module. It's generating a list of vulnerabilities with generic severities, completely detached from whether the vulnerable library is even loaded in a running container, or if the exploit path is network-accessible. This is the same noise generator we've had for years.
The integration feels clunky. You point it at your registries (ECR, GCR, etc.), and it pulls and scans. But the feedback loop is broken. In a CI pipeline, I need a fast, deterministic pass/fail based on my organization's policy (e.g., fail on critical in base layers, warn on high in app layers). What I'm seeing is a slow scan that dumps findings into the main Orca console, commingled with all my cloud alerts. There's no clean way to tie that specific image SHA to a subsequent deployment failure. The API is rudimentary at best.
Here's an example of the policy gap. Let's say my Python app has a high-severity CVE in `libcrypto`. The image scanner flags it. But in runtime, that container is using a distroless base for the final image, and the vulnerable library isn't even present in the running container filesystem. Orca's runtime agentless scanning *should* be able to see that and suppress the alert, but the two systems don't seem to talk. So I'm left with duplicative, conflicting findings.
I want to know if others are seeing the same disconnection. Has anyone managed to wire this into a CI gate effectively, or are we all just collecting another billable data source for the security team to ignore? The potential is there—if they can seamlessly correlate image scan results with the runtime posture they already see, that would be powerful. Right now, it's just another scanner.
-- Cam
Trust but verify.
You're dead on about the context problem. It's the classic "scan everything, alert on everything" strategy that just creates alert fatigue and a giant bill.
What kills me is that these vendors will happily charge you per image scan, but the "actionable intelligence" you get is a spreadsheet of CVEs that may or may not matter. We ran a similar tool last year and it flagged a high-severity bug in a dev dependency that wasn't even in the final container build stage. The scanner didn't understand multi-stage builds, just the repo contents. That's the "bolted on" logic you're seeing.
I've started thinking of this as a cost problem disguised as a security one. My team now spends more time triaging these garbage in/garbage out vuln reports than we would just running a decent opensource CLI scanner in the pipeline and writing our own risk rules. The cloud billing for these "context-free" scans feels like a tax on laziness.