I've been evaluating container security platforms for a multi-region Kubernetes deployment, and Check Point's CloudGuard has been on the shortlist. The recent release notes for Q2 highlighted significant performance improvements for their container registry scanning, specifically claiming a "70% reduction in scan time for large images." Vendor claims like this always warrant a synthetic test, so I set up a controlled benchmark.
My test methodology was straightforward:
* **Environment:** A dedicated Azure D4s v3 instance (4 vCPUs, 16GB RAM) in the same region as the registry.
* **Test Images:** A curated set of five container images, from a slim Alpine-based app (~50 MB) to a monolithic legacy application image with numerous packages (~2.1 GB).
* **Process:** I used the CloudGuard CLI to trigger scans via their API, measuring the time from scan initiation to the final result being available in the console. Each image was scanned three times, with the first result discarded as a cold-start baseline, and the latter two averaged.
* **Comparison Point:** I compared results against scans I ran in late Q1 using the same image set and a comparable instance type.
The raw data from my latest run is below. The "legacy" times are from my notes in January.
| Image Description | Size | Layers | Q1 Avg Scan Time | Q2 Avg Scan Time | Delta |
| :--- | :--- | :--- | :--- | :--- | :--- |
| `nginx:alpine` | 50 MB | 6 | 42 sec | 18 sec | -57% |
| `node:18-slim` | 260 MB | 18 | 118 sec | 49 sec | -58% |
| Custom Python App (Flask, deps) | 890 MB | 32 | 256 sec | 92 sec | -64% |
| Legacy Java App (full JDK, deps) | 1.7 GB | 41 | 412 sec | 135 sec | -67% |
| Monolithic App (Ubuntu, many pkgs) | 2.1 GB | 55 | 538 sec | 149 sec | **-72%** |
The claim holds up under this basic test, especially for larger, more complex images where the improvement exceeds 70%. The most substantial gains appear to be in the analysis phase post-layer pull. However, this introduces my primary question for the community: **where is the bottleneck shifting?**
With scan times now under 150 seconds even for massive images, the total pipeline delay is dominated by other factors. In my CI/CD pipeline, the sequence is:
1. Image build and push to private registry (E.g., ACR).
2. Webhook triggers CloudGuard scan.
3. Wait for scan completion.
4. Gate deployment on policy result.
The scan time is now a smaller portion of the total. The new critical path seems to be the webhook propagation, the initial queuing in CloudGuard, and the policy evaluation overhead if you have complex rules. I've observed a fairly consistent 20-30 second overhead from push to scan start that isn't accounted for in their performance metrics.
Has anyone else conducted similar post-update benchmarks, particularly in high-volume environments (dozens of concurrent image pushes)? I'm interested in whether the scaling behavior under load has improved proportionally, or if the queue management introduces new latency cliffs. Furthermore, are these performance gains uniform across all supported registries (ECR, GCR, ACR, Docker Hub), or is there variance based on registry API latency and geography? The release notes are conspicuously silent on these architectural details.
Show me the benchmarks