Query

[Amit Agarwal]

Hi Jeremy, 

First of all , thanks a ton for providing a tool enabling to uncover vulnerable components in use in our softwares.

Our query.

We have a project with 80 dependencies. Of which tool reported 

scanned, 80 

vulnerable dependencies : 10

Vul found : 50

Of this remaining 70 components, some might be projects own custom dll for which there might be no reference in the NVD.

In other cases like Log4j etc, can we assume that there are no vulnerabilities reported in the NVD database?

[Jeremy Long]

Amit,

The problem of library identification is problematic. Mapping any given Jar file to an CPE ID contained in the NVD is not easy. Other tools in this space, such as Victims, use hashes for matching. The mechanism used by dependency-check is to map "evidence" collected from the dependency to attempt to determine if we can find a CPE; whereas the hash mapping can be more accurate - unless you compiled the Jar from source yourself. Additionally, the hash based mechanism requires maintenance of the database - the library you are using may not be being tracked in the hash database. This topic is covered somewhat in the Project Presentation linked to on the project site: http://jeremylong.github.io/DependencyCheck/

Another issue is that dependency-check currently only uses data from the NVD - there are other vulnerability databases (such as the OSVDB); if the vulnerability is published in the OSVDB and it is not in the NVD then dependency-check won't find it (this is true for at least one Freemarker vulnerability).

Trust me in saying that I am working hard to ensure the results of dependency-check are as accurate as possible; there are times when a false positive or negative may crop up. I won't sugar coat that. However, I have heard of "pepsi-challenges" being done against some of the commercial tools in the space and dependency-check did very well. For instance, dependency-check found more (accurately reported) vulnerabilities then the commercial tool - with the exception of one vulnerability that was not in the NVD. Since the commercial tool had this information they were able to identify the vulnerability. I won't name the commercial tool and I will point out that I've heard of other tools identifying more then dependency-check (although I did just fix a couple of bugs that will hopefully close this gap some).

While you have to make the decision regarding this complicated topic for yourself do know that there are also commercial solutions. I know of several organizations using dependency-check as their sole monitoring solution, I know companies use dependency-check and other tools, and I know of people that have used dependency-check to make the case for looking at commercial tools.

Lastly, dependency-check only identifies known, published vulnerabilities. Many 3rd party components contain undiscovered/unpublished vulnerabilities.

Regardless, I hope you continue to use dependency-check and report back any issues or additional concerns you have about the tool.

Best Regards,

Jeremy

--
You received this message because you are subscribed to the Google Groups "Dependency Check" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dependency-che...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Amit Agarwal]

Hi Jeremy, 

Thanks for the reply.

Also , is there any future plan to look for all the possible sources of vulnerability databases like OSVD.