CVE finding discrepancy between emba-f17-cve-bin-tool and cve-bin-tool itself

[jni2000]

Hi community

I understand that emba scan normally can find more CVEs than using the cve-bin-tool itself, and this is true in most of my scan tests. However, in a few of my tests, running cve-bin-tool alone found a bunch of CVEs while running emba against the same software did not find any CVE at all, what could the reasons of this situation?

Best regards

[m-1-k-3]

Hi @jni2000,

I would say "two tools give different results". Nevertheless, it would be very interesting to learn and improve EMBA. So, if you can share such testcases I will take a look if we can improve EMBA.

Thanks

[jni2000]

Hi @m-1-k-3 ,

Thanks for responding. I did a bit in-depth investigation of the CVEs found by running the cve-bin-tool alone and found that all the CVEs reported are located in the pom.xml files. I guess this might be the missing parts in emba. Is there a configuration such as profile setting to include them into scan ?

I felt that a more comprehensive solution to cover the CVE detection is to do the followings

1. run an additional cve-bin-tool against the target software
2. run the existing cve-bin-tool scan against the ebma generated SBOM
3. aggregate the CVEs

If you can provide any technical instructions on how to do the aggregation, I'd be happy to help implementing the above if you agree.

Best

James

[m-1-k-3]

additionally, I tested syft for verification:

NAME             VERSION  TYPE            
httpspi-servlet  4.0.3    java-archive    
jaxws-rt         4.0.3    java-archive    
policy           4.0.3    java-archive    
rt               4.0.3    java-archive    
rt-fi            4.0.3    java-archive    
servlet          4.0.3    java-archive  

[m-1-k-3]

Please give it a test in #1769

[jni2000]

Please give it a test in #1769

Thanks, will do.

[jni2000]

Hi @m-1-k-3,

I tested your fix with several packages and the results all look positive. However, I did notice a few additional cases where EMBA’s scan reported fewer CVEs than a standalone run of cve-bin-tool. This time, the discrepancies seem related to libraries such as zlib.so and similar components.

To validate my assumption (will cve-bin-tool generate the same CVE findings when scanning the software package and the SBOM of the software package?), I ran further tests and confirmed that cve-bin-tool can yield different CVE results when scanning the software directly versus scanning the SBOM generated from that same software. In my tests, running cve-bin-tool on the actual software package produced more findings than running it on the SBOM created by cve-bin-tool for that same package.

Given this behavior, I’d like to suggest an enhancement to strengthen EMBA’s CVE coverage. Before the F17 aggregation step, EMBA could:

1. Run cve-bin-tool directly on the software package,
2. Run cve-bin-tool again on the SBOM generated by EMBA, and
3. Merge the two sets of findings.

This would ensure that EMBA’s results always form a superset of cve-bin-tool’s output, regardless of whether the CVEs are surfaced during direct scanning or from the SBOM.

Let me know your thoughts.

[m-1-k-3]

If some components are missing please open dedicated issues per component with a testcase (binary) which we do not detect. With this we should be able to implement a fix for it. I don't think we need to do a run with another tool as it complicates the post-processing massively and the benefits are not that big.