I've been evaluating Orca Security for container and cloud security posture management across our multi-cluster Kubernetes environments. While the platform's agentless architecture and side-scanning approach are technically sound for our use case, my primary grievance lies with the post-sales experience. The support response times are consistently subpar, and interactions feel heavily scripted.
For example, when we encountered an issue where Orca was incorrectly flagging a specific, non-vulnerable alpine-based image due to a CVE in a package not present in our final build stage, the support process was frustrating. The initial response took over 72 hours and was a generic template about "ensuring all scans are up to date." Subsequent replies followed a rigid, step-by-step script:
* Request for full scan logs (provided).
* Request for exact image SHA (provided).
* Statement that the "engineering team is reviewing."
* Finally, after a week, acknowledgment of a false positive.
This linear, ticket-based workflow lacks the collaborative troubleshooting common in DevOps tooling. Compare this to opening an issue on a project's GitHub repo, where maintainers and community can immediately engage with the specific code or configuration.
In our CI/CD pipelines, where speed and precision are critical, this delay and lack of nuanced understanding creates a bottleneck. A security tool must integrate seamlessly into the deployment lifecycle, and that includes responsive, knowledgeable support capable of moving beyond pre-written responses. Has anyone else built internal workarounds or escalation paths to deal with this, or found their support responsiveness to improve significantly after certain milestones?
--crusader
Commit early, deploy often, but always rollback-ready.
Ugh, that "engineering team is reviewing" black hole is the worst. I've seen this exact pattern with other security platforms too - the support team often just acts as a low-bandwidth messenger to actual engineering.
It's a real problem when you can't have a quick, collaborative chat about the specific scanning logic. Makes you miss the transparency of open source tooling sometimes, even if it's less polished.
Have you found any workarounds? Like getting a direct line to a solutions engineer post-sale?
data over opinions
Yeah, that "low-bandwidth messenger" part hits home. It makes the whole support fee feel pointless.
Have you actually had any luck getting that direct line? I tried once during a trial with another vendor, and they basically said the assigned SE is only for pre-sales. After you sign, you're back in the general queue. Seems like a broken model.
Still learning.
Direct post-sales access is a contract problem, not a support one. You negotiate for it.
That "SE is pre-sales only" line is standard. The workaround is to specify a named technical account manager (TAM) or escalation engineer in your agreement, with defined SLAs for response. Otherwise you're just paying for a queue.
We had to do this after a similar issue with a vuln scanner. Support can't debug the product; you need someone who builds it. If they won't commit to that, it's a red flag on their internal priorities.
Trust but verify, then don't trust.
That exact scripted workflow is a major pain point. We hit something similar where a scan kept flagging a library we had explicitly patched, and the back and forth over logs and SHAs ate up a whole sprint.
It really does kill the momentum. That GitHub comparison is spot on - the async, transparent discussion there feels like problem solving. A rigid ticket system can feel like you're just feeding a machine.
Have you found the false positive rate stays high, or was that a one off thing for your alpine image?
null
The issue you're describing with the alpine image scan is a classic symptom of a tool that relies heavily on signature matching without contextual awareness of the actual runtime environment. That 72-hour initial response for a false positive is particularly damaging in a CI/CD pipeline, where it can block deployments.
From a data pipeline perspective, this isn't just a support problem, it's a data quality problem. The scanner is producing a high volume of low-signal alerts, and the support team lacks the instrumentation or authority to perform root cause analysis on their own model's output. They become ticket routers, not problem solvers.
We've observed similar patterns in data platforms where monitoring alerts are decoupled from the teams that build the logic. The fix is almost always the same: you need to bypass the generic support channel entirely. As others noted, this means negotiating for dedicated, technical escalation paths in the contract. If they can't offer that, it tells you their internal feedback loop between support and engineering is broken.
data is the product