Our security team has begun a formal evaluation of Orca Security for our containerized workloads, which are substantial. We maintain a primary Azure Container Registry containing approximately 1,700 distinct images, with significant layer reuse. The initial full scan, which we were advised to perform for a baseline, took upwards of 27 hours to complete. Subsequent incremental scans are better but still introduce a latency of 3-5 hours before vulnerabilities appear in the dashboard, which is problematic for our CI/CD pipelines that push dozens of image revisions daily.
Based on my analysis as an integration architect, I suspect the bottleneck is not purely computational but architectural, relating to data synchronization and API design. I have several hypotheses regarding the constraints:
* **Sequential Image Pull and Analysis:** If Orca's scanner is designed to pull and analyze images sequentially from a registry, rather than employing a concurrent, worker-based model with dynamic scaling, the linear time complexity would explain the poor performance. The scanner might be bound by I/O and network latency rather than CPU.
* **Layer Deduplication Inefficiency:** While ACR uses layer deduplication, the security scan must still process each manifest. If Orca is not efficiently caching and referencing scan results for shared layers across *different* image repositories (e.g., `myapp/api:1.0` and `myapp/worker:1.0` might share a base layer), it is performing redundant work.
* **API Throttling and Back-Pressure:** The Orca agent or cloud connector might be implementing conservative API call rate limits against the registry's REST API to avoid being throttled, creating an artificial bottleneck. Similarly, the ingestion pipeline into Orca's own data lake for correlation might have batch-oriented intervals.
* **Event-Driven Gap:** The process appears to be a scheduled batch job rather than event-driven. There is no immediate webhook or event from our registry (like `PUSH_ARTIFACT`) that triggers a targeted scan on the new image alone. This forces reliance on slow, full-sync cycles.
Has anyone performed a deep-dive or received architectural clarifications from Orca on this? Specifically:
1. What is the exact concurrency model for pulling images from a registry during a registry scan?
2. How are shared image layers across different repositories handled to prevent redundant CVE database lookups and analysis?
3. Is there a supported method to trigger an immediate, single-image scan via an API call or webhook upon a new push, to bypass the wait for the next scheduled sweep?
I am attempting to map their service's integration points to see if we can build a middleware wrapper to mitigate the delay, but without understanding the internal data flow, it's challenging. The latency creates a significant data consistency issue between our actual registry state and Orca's security findings.
-- Ivan
Single source of truth is a myth.