Just wrapped up a pretty large-scale evaluation of JFrog Xray, scanning a repository of just over 10,000 container images across a mix of internal builds and pulled public images. The headline number that jumped out at me was the **false positive rate: 22%**.
That’s a significant chunk of the flagged vulnerabilities that, upon manual review and cross-referencing with other sources, were not actually applicable to our specific deployment context. Most common culprits:
* **OS package vulnerabilities in stripped/distroless images** – Xray correctly identifies a package version in the base layer, but our final image doesn't include the vulnerable binary or library.
* **"Critical" CVEs in dev-only dependencies** – Tools used at build-time flagged as runtime threats, cluttering the priority view.
* **Version matching hiccups** – Especially noticeable with Node and Python packages where version ranges or post-fix releases aren't perfectly accounted for.
While I appreciate the depth of the scan and the component graph is invaluable, the noise level makes it tough for my security team to trust the automated severity reports. We're now spending a lot of time on triage.
Has anyone else done similar large-scale validation? I'm particularly curious about:
* Your experience with tuning the **Watch policies** and **Ignore Rules** to reduce this. Are you ignoring by component, by specific CVE, or by a whole vulnerability context?
* Are you integrating external data sources or other scanners (like Grype or Trivy) to cross-reference before taking action?
* How does this FPR compare to what you're seeing with other SAST/SCA tools in your pipeline?
The 22% feels high, but maybe that's just the state of container scanning right now. Would love to see some comparison spreadsheets or data from others in the community.
Spreadsheets > marketing slides.
Oof, 22% is rough but painfully familiar. That distroless image problem is a classic - the scanner sees the base layer but can't always track what gets carried through. We've had better luck with scanners that support SBOMs and can do a more accurate dependency graph, but it's never perfect.
The dev dependency noise is the real drain on team energy. Have you looked at any of the policy engines that can filter findings based on context? We use a combo of OPA policies in our pipeline to auto-close stuff that's only in `devDependencies` or `test` scopes. Cuts down the ticket queue dramatically.
What's your triage workflow look like now? Are you feeding anything back into Xray as "ignore" rules?
#k8s