Hey folks! Looking for some real-world advice. We're using AWS ECR and GitHub Packages for our container/artifact registries, not Artifactory. Need solid security scanning but Xray feels like overkill (and locks us into their ecosystem).
What are you all using for scanning that's **registry-agnostic**? My wishlist:
* CLI or API-first for CI/CD pipelines
* Solid vulnerability DB (CVEs)
* Good Kubernetes admission controller story
* Bonus: cost-effective at scale 😉
Currently testing:
* **Trivy** (open source) - simple, but reporting is basic
* **Snyk Container** - deeper insights, but pricey
* **AWS Inspector** - native for ECR, but only covers AWS
Biggest win recently was combining Trivy scanning with a spot instance-based pipeline. Cut scan costs by ~70%! 🎉
Any other tools or combos you love? Especially if they play nice with Terraform-provisioned infra.
#savings
Nice find with the spot instances for Trivy, that's clever! I was in a similar spot with Azure Container Registry.
For your setup, have you looked at **Clair**? It's open source, designed to be registry-agnostic, and the Kubernetes admission controller integration is solid. We run it through **clairctl** in our pipelines. The vulnerability DB is good, though updating it needs some planning.
It can be a bit more hands-on to set up than Trivy, but it ticks your boxes. We pair it with a simple dashboard for reporting. Might be a good middle ground before jumping to Snyk's price tag.
~Isla
The spot instance trick with Trivy is genuinely smart. I'd just caution that the "reporting is basic" problem tends to get more painful at scale, when you're trying to prioritize a few hundred CVE hits across hundreds of images. That's where the pricey tools start to justify their existence.
You might also kick the tires on Grype. It's from Anchore and is similarly CLI-driven, but the vulnerability matching can be a bit more configurable than Trivy's defaults. The trade-off is that you then have to manage that configuration.
Show me the data
You're absolutely right about the reporting pain point scaling non-linearly. We hit that wall at around five hundred active images last year. The operational load from manually triaging Trivy's flat CVE list became unsustainable.
That's precisely why we layered OpenPolicy Agent on top of Grype. Grype's configuration lets us define severity thresholds and package allow-lists, but OPA gives us a unified policy engine to evaluate those scan results against org-wide rules. The policy can then feed into the admission controller, a dashboard, and our CI/CD gates from a single source. It adds complexity, but it's vendor-neutral and avoids the reporting lock-in you get with commercial tools.
The trade-off, as you note, is configuration management. We ended up storing Grype's config and the OPA policies in a dedicated Git repo, treating them as infrastructure-as-code with the same review cycle as everything else.
Boring is beautiful
Oh, Clair has been on my list to check out, thanks for the real-world insight. The registry-agnostic part is exactly what I need.
> updating it needs some planning.
That's good to know. Would you say it's mostly about scheduling the DB updates, or are there other operational hurdles? I'm still pretty new to running my own scanning infra.
The idea of pairing it with a simple dashboard sounds great too. Snyk is just a bit much for my current scale.