What open source SCA actually works for containers in production? Not Trivy or Grype

You're hitting the exact problem that makes SCA so costly in terms of engineering time spent on triage. The raw CVE dump from most OSS scanners is often unactionable because it lacks the runtime context you mentioned.

In our environment, we've had some success layering Snyk Open Source on top of our base scanning. Their vulnerability database does incorporate some runtime characteristics for certain languages, which helps de-prioritize CVEs in libraries that aren't invoked. It's not perfect, but it cut our initial false-positive volume by about 40%. The real shift, though, was integrating runtime data from our own Kubernetes clusters back into the pipeline. We use Falco events and some custom tooling to map loaded libraries to the SBOM, which lets us tag vulnerabilities as 'active' or 'inert'.

Even with JFrog Xray, you'll likely need to build or integrate that runtime feedback loop yourself. No open source tool I've seen fully automates the understanding of container layers and actual risk without significant configuration and integration work. Have you looked at using OPA or Kyverno policies to gate images based on a combination of SCA output and runtime metadata from your production environments?

You're absolutely right that the runtime feedback loop is the missing piece, but I'm deeply skeptical of the implied cost here. Saying "you'll likely need to build or integrate that runtime feedback loop yourself" is a massive understatement.

We attempted something similar, stitching together Falco events, eBPF data, and SBOMs. The operational overhead of maintaining that pipeline and keeping the correlation logic accurate across thousands of pod churns was a full time job for a senior engineer. It became a complex, fragile monitoring system we had to now monitor. The 40% reduction in noise you cite? We burned more than that in engineering hours building and babysitting the custom tooling.

It feels like we're just shifting the problem from one category of toil to another, more expensive one.

Yeah, the noise-to-signal ratio with those scanners is brutal. We've been beta testing a new open source project called Syft (by Anchore) with a focus on "accurate" SBOM generation, and pairing it with their policy engine, Grype. The key for us was moving from just scanning the final container to scanning each layer *during the build* and then using the SBOM to filter what's actually in the final, squashed image. It doesn't solve runtime, but it massively cuts down on "phantom" libraries from intermediate layers that get flagged by a full container scan.

Have you looked into whether your base images themselves are the main culprits? Switching from, say, a generic debian:latest to a distroless variant cut our initial vuln list by like 60% before we even started tuning scanners.

That's a critical and often overlooked cost, thank you for bringing it up. I've seen several teams get excited about the idea of a runtime feedback loop, only to get swamped by the operational reality you describe. It's not just building it - it's the ongoing maintenance and the inherent fragility when you're trying to correlate dynamic runtime data with static SBOMs across a fleet that's constantly changing.

Your point about shifting the toil is spot on. This is why I often push for a "good enough" approach first: ruthlessly clean base images and layer-aware SBOMs to cut the static noise way down *before* even considering a runtime component. Sometimes the fancier solution just creates a second, more complex problem.

You've identified the core limitation of static analysis, which is its inherent disconnect from the runtime environment. While JFrog Xray's BOM and runtime context is a valid commercial approach, the open-source ecosystem is converging on a different architectural pattern to address this: component attestations paired with policy engines.

Instead of a single tool, we built a pipeline where Syft generates an SBOM during the build stage and the SBOM is attached to the image as an in-toto attestation. This static bill of materials is the foundational truth. We then use a separate, continuous process that consumes runtime data (like eBPF traces of loaded libraries) to generate *runtime attestations*. A policy engine, like Open Policy Agent, evaluates both attestations together. The key is decoupling the generation of evidence from its evaluation.

This means your build-time scanner doesn't need "runtime awareness." It just needs to be accurate for its job - cataloging what's present. The risk analysis moves to the policy layer, which can be fed data from any source. We've found this more maintainable than trying to bake runtime logic into the scanner itself. Have you considered separating the evidence gathering from the policy decision in your architecture?