Our security team just handed me a report showing JFrog Xray failed to detect CVE-2023-29469 (a high-severity flaw in a specific Go library we use) in a container image that was scanned and passed in our Artifactory registry two weeks ago. We have Xray configured with the default security policies and it's supposed to be scanning on push. This wasn't some obscure, newly published vulnerability; it had a published date well before our scan.
Now I'm in the position of having to validate their finding, figure out why Xray missed it, and present a remediation path to both engineering and security. My immediate questions are:
* Is this a configuration issue on our end, or a known gap in Xray's vulnerability database?
* What is the actual process for validating and troubleshooting a missed CVE like this with JFrog support? I need concrete steps, not a generic "open a ticket."
* How do others handle verification? Do you run a parallel scan with an alternative tool (like Trivy or Grype) as a sanity check, and if so, how do you operationalize that without duplicating effort?
Our current setup is a Kubernetes deployment pipeline using Artifactory as the image registry, with Xray integration. The relevant part of our `jfrog-pipelines` YAML for the scan step looks like this:
```yaml
- name: xray_scan
type: xrayScan
configuration:
scanResourceType: "image"
scanResourceName: "{{buildInfoId}}"
failBuild: true
severity: "High, Medium"
```
I've already done the preliminary checks: the component (the exact Go package and version) is definitively in the image, and the CVE is listed on the NVD. The security team used a simple `trivy image` command to find it.
Before I engage JFrog, I want to gather data. I'm looking for others who have been through this and can provide insight on:
* The typical root causes (e.g., database sync lag, misconfigured watch, component fingerprinting failure).
* Whether you've had to supplement Xray with another scanner for critical workloads.
* How you've structured your policies and watches to minimize these gaps. Are we relying too much on default settings?
* The efficacy of JFrog's response when you report a false negative. Did they update their database promptly, or was it a protracted process?
The immediate concern is triaging our existing deployed images, but the larger issue is a loss of confidence in the tool we've built our container security gates around. I need to rebuild that with either concrete fixes or a revised architecture.
Measure twice, migrate once.
First, validate the security team's finding concretely. Pull the exact image digest they scanned (not just the tag) and run a manual scan in the Artifactory UI, checking the scan log for errors. Then, run a CLI command like `jfrog xray curl -XPOST -H "Content-Type: application/json" -d '{"component_ids": ["docker://@"]}' api/v1/scan` to see the raw components Xray detected. You need to confirm the vulnerable Go library version was actually present in that specific image layer; sometimes the discrepancy is a difference in the artifact being examined.
Your question about a parallel scan is critical. We run Trivy as a secondary check in our CI pipeline, but only on images that Xray flags as clean for high/critical CVEs. It's a lightweight conditional step. The operational overhead is minimal if you script it to only produce a report on divergence, which you then treat as a pipeline failure requiring investigation. This isn't about duplication; it's about having a verification layer for exactly this scenario.
Opening a ticket with JFrog support requires specific data: the exact image digest, the Xray scan ID or timestamp, the CVE ID, and the output from your component analysis showing the library present. Without that, you'll get generic responses. I've found that gaps sometimes occur in the specific vulnerability database feed Xray consumes for a given ecosystem, and support can confirm if there was a lag or omission. Start there, but your immediate remediation path is to manually block that image digest in Artifactory and trigger a rebuild with a patched library.
Thanks for laying out those verification steps, that's really helpful. I'd be a bit cautious about treating a parallel scan failure as an automatic pipeline blocker though, at least at first. In a team I was with, we started that way and it created a lot of noise from false positives or versioning mismatches between tools. We ended up routing those divergence reports to a dedicated security channel for triage instead, so it didn't immediately block developers.
The idea of scripting it to only produce a report on divergence is smart. Did your team ever run into cases where the tools disagreed on the *severity* of the same CVE, not just its presence? That always seemed to cause extra debate for us.
still learning