Hi everyone. I'm new to JFrog Xray and still figuring things out. Our team builds a lot of internal libraries and tools that we store in Artifactory. When Xray scans our builds, it obviously can't find vulnerabilities for these internal components since they're not in public databases.
What's the best practice here? Do I just accept that they'll always show as "unknown" in the reports? Or is there a way to manually add metadata or a security summary to these internal packages so Xray can at least track them? I'm worried about security blind spots.
I'm mainly using this for a customer-facing app, so understanding our full risk is important. Any guidance from teams with similar setups would be super helpful! 👋
You're right to worry about blind spots. The "unknown" status creates a false sense of security by diluting your actual risk metrics. You shouldn't just accept it.
There are a few ways to handle internal components. The most direct is to use Xray's ability to create Security Policies and Watches that explicitly mark your internal libraries with a predefined, lower severity. This doesn't scan the libs themselves, but it stops them from polluting your violation reports with unknowns. You essentially create a whitelist policy for your internal repo or a specific pattern. The more rigorous approach is to actually generate SBOMs for your internal libraries as part of their build process and attach them. This lets Xray understand the *dependencies* of your internal libs, which are likely public packages it can scan. That's where your real risk probably lies anyway.
Can you quantify the problem? What percentage of your total components in a typical application scan come back as unknown because they're internal? If it's over 10-15%, your reports are becoming noisy and less actionable.
CostCutter
Totally agree on the percentage point. If you're seeing 10-15% unknowns from internal libs, your risk score is basically useless for prioritization. That noise is a real problem.
I'd add one practical step to the SBOM approach: for internal libraries, make the SBOM generation and push part of your release pipeline's "definition of done." We use CycloneDX and attach it right after the build finishes. This way, Xray can at least scan the transitive *public* dependencies inside your private component. You're right, that's where 99% of the risk usually hides anyway.
The policy/whitelist method is a good stopgap, but treating internal components as "low severity" by default makes me nervous. What if someone accidentally introduces a vulnerable public package as a dependency? The whitelist would hide it.
You've hit on the key risk with blanket policies. Marking internal components as low severity can indeed mask a real vulnerability that's been pulled in transitively.
A middle ground is to use a custom context in your security policies. You can define a rule that marks components from your internal repo as "Not Applicable" for the "Unknown" license or security violation, but still leaves them fully exposed to scanning for all other violation types. That way, you clear the noise of the unknown status without disabling scanning on the public dependencies inside them.
It takes more policy setup, but it targets the noise without creating a blind spot.
- GG