stevespringett
commented
7 years ago I also use dtrack 1.x in production and have the same experience. One major difference between v1 and v3 is that v1 relies solely on dependency-check to provide it CVEs and other relevant vulnerability information. v3 on the other hand contains a full mirror of the NVD regardless of whether or not tracked components have any of the vulnerabilities or not.
One of the primary use cases for this is to be able to look up a CVE and see (on the same page) a list of projects that may be affected by it. This partially works today.
I was leaning towards the idea you had, but hadn't thought it all the way through yet. This would require the ability to perform "scans" not using dependency-check, but rather some simple internal logic that leverages the full mirror of the NVD that v3 has. I think this would be possible in v3. Not sure if it will make it into 3.0.0 or not, or a minor release afterwards. But I think this feature would be really valuable.
I'm using Dependency Track "for real", monitoring several products and hundreds of components.
Sometimes DTrack does not report a vulnerability I know is applicable. The reason is that the "affected version" information in NVD XML sources is incomplete. A frequent example is that only the version in which the vulnerability is found is reported, nothing being said about earlier versions. When the set of the affected versions is nontrivial (happens regularly with e.g.
OpenSSL), it is seldom fully correct in the NVD XML.I see this as a showstopper for many users: the purpose of DTrack is to not miss the vulnerabilities.
But obviously the report cannot be better than the source data it is based upon.
One idea might be to give an option to "report vulnerabilities for all versions" for a given component when the user selects a component version in the application. This way the user will get also non-applicable vulnerabilities, but will never miss the relevant ones (if only the product name is correct).
I do not know how such "feature request" fits in the present vision of DTrack. But otherwise I found that I'm reading the XML diff to be sure that I have not missed something critical, which kind of defeats the purpose of using DTrack.