You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix: use CPE target_sw to populate ecosystem to reduce FP #7139
The NVD has some CVEs such as https://nvd.nist.gov/vuln/detail/CVE-2022-31115, that use the target_sw to specify the runtime (e.g. ruby, java, etc.). This can be used to populate the ecosystem used to reduce false positives in the ODC analysis. See org.owasp.dependencycheck.data.nvd.ecosystem.CveEcosystemMapper.
changed the title [-]feat: use CPE target_sw to populate ecosystem to reduce FP[/-][+]fix: use CPE target_sw to populate ecosystem to reduce FP[/+]on Nov 7, 2024
Hi @jeremylong, I'd like to pick this up if it's still wanted.
Here's my plan:
CveItemOperator.extractEcosystem already maps target_sw to an ecosystem when the database is built, but NvdCveAnalyzer.ecosystemMatchesTargetSoftware only checks target_sw for Node.js dependencies and lets everything else through. I'd move the target_sw mapping into one shared place (adding rust, which isn't mapped yet) and have the analyzer drop a vulnerable software entry when target_sw names a different language runtime than the dependency's ecosystem. *, -, values that map to native (like linux or c/c++) and anything unmapped would keep matching like today, and the Node.js behavior stays the same.
For Java dependencies I'd still let node.js and JavaScript entries match, since webjars ship npm packages inside jars and those CVEs shouldn't disappear. Happy to drop that exception if you see it differently.
Activity
[-]feat: use CPE target_sw to populate ecosystem to reduce FP[/-][+]fix: use CPE target_sw to populate ecosystem to reduce FP[/+]OrangeDog commentedon Nov 13, 2024
This would fix e.g. #3460, #3876, #6851, and allow a general cleanup of bundled suppressions.
Akhil-1527 commentedon Sep 29, 2026
Hi @jeremylong, I'd like to pick this up if it's still wanted.
Here's my plan:
CveItemOperator.extractEcosystemalready mapstarget_swto an ecosystem when the database is built, butNvdCveAnalyzer.ecosystemMatchesTargetSoftwareonly checkstarget_swfor Node.js dependencies and lets everything else through. I'd move thetarget_swmapping into one shared place (addingrust, which isn't mapped yet) and have the analyzer drop a vulnerable software entry whentarget_swnames a different language runtime than the dependency's ecosystem.*,-, values that map to native (likelinuxorc/c++) and anything unmapped would keep matching like today, and the Node.js behavior stays the same.node.jsand JavaScript entries match, since webjars ship npm packages inside jars and those CVEs shouldn't disappear. Happy to drop that exception if you see it differently.cpe:2.3:a:elastic:apm_agent:*:*:*:*:*:python:*:*but was reported on the Java agent) and [FP]: Rust vulnerability CVE-2020-36448 has resurfaced, this time on dependencycache4k-jvm, even with latest (10.0.3) Dependency Check version #6851 (CVE-2020-36448 iscpe:2.3:a:cache_project:cache:*:*:*:*:*:rust:*:*but was reported on cache4k-jvm).I'd leave removing the bundled suppressions this makes redundant to a separate PR, unless you'd rather see it in the same one. Does that sound right?
neilscallywag commentedon Oct 10, 2026
^ Bump, This has been bugging my team for a while as well and takes up a bit of our time doing due diligence. Would be keen to help as well.
Akhil-1527 commentedon Oct 11, 2026
@neilscallywag I've opened #8834 for this. If you can try it on a project that's been hitting these false positives, feedback is welcome.
test: pin down current target_sw ecosystem handling