search

CycloneDX / cyclonedx-maven-plugin

Creates CycloneDX Software Bill of Materials (SBOM) from Maven projects
https://cyclonedx.org/
Apache License 2.0
287 stars 85 forks source link

inspire from owasp dependency-check to include CPEs in BOM #254

Open redaabdellah21 opened 1 year ago

redaabdellah21 commented 1 year ago

Hi,

i have worked with dependency track and the Cyclonedx maven plugin to list component vulnerabilities in my project. Now i am discovering dependency check, i have found that it is able to generate reports with both PURL and CPE (doesn't always work), is there a way to inspire from them to include CPE in the BOM?

i am making this suggestion because i compared dependency track+cyclonedx and dependency check using same project, and found out that dependency check was able to identify vulnerabilities where dependency track couldn't.

eg: NVD is able to find a vulnerability in component using :cpe:2.3:a:apache:commons_net:1.15:*:*:*:*:*:*:*

SONATYPE INDEX can't find it in same component using : pkg:maven/commons-codec/commons-codec@1.15

stevespringett commented 1 year ago

Dependency-Check is an SCA tool. It gathers evidence of varying degrees of confidence and uses that to identify potential vulnerabilities. CycloneDX is a BOM format and as a BOM format, it expects the identity of a component to be asserted and be truthful. So for CPE to be populated in the Maven plugin and be accurate, we'll need a PURL to CPE mapping, where the GAV is transposed to a PURL (already in place), and the PURL can look up its corresponding CPE (not in place).

A static mapping is really the only way this is achievable, but the approach is likely not sustainable for this project. Commercial SCA vendors are able to derive CPE from the native coordinates or PURL, but have large data science teams in place to maintain this data and ensure its accuracy. The CycloneDX project does not have an independent data science team to perform this function.

The only CycloneDX implementation that I'm aware of that supports generating CPE from a build is the Erlang implementation for Mix (https://github.com/voltone/sbom/blob/master/lib/sbom/cpe.ex), but even that is a simplistic map.

However, keep in mind that supporting CPE from a build will have negative side effects. For example Spring Framework has many modules. If a vulnerability in Spring MVC comes up, but you do not use Spring MVC, that CPE is going to generate false positives because CPE only handles vendor, name, and version. It does not support modules. So there will be negative side effects to supporting CPE which is why the industry to advocating to move away from using them.

Also FYI https://commons.apache.org/proper/commons-net/ and https://commons.apache.org/proper/commons-codec/ are two entirely different projects. Perhaps Dependency-Check identified a false positive in this case?

Also, according to https://github.com/apache/commons-net/releases/tag/NET_1_5_0, Commons Net v1.15 is from 2008, so very old FYI.

redaabdellah21 commented 1 year ago

Thank you @stevespringett for your response. I understand the difficulties related to not having a data science team.

I intentionally copied the CPE and PURL that dependency check found, i suspected that it wasn't the same thing, thank you for confirming that.

prabhu commented 4 months ago

@redaabdellah21 have you considered the case where what Dependency Check found was a false positive? commons-net and commons-codec are not the same packages, so it is likely the CVE in question doesn't affect commons-codec.