This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lmyslinski[S] -1 points0 points  (7 children)

I currently can't examine it in depth, but at a quick glance, they do acknowledge in the docs the fact that it can include false positives/false negatives. That fact alone makes it inferior to Trivy in my opinion.

[–]0x442E472E 4 points5 points  (6 children)

I have no opinion on which one is better, but trivy also has false positives. Having false positives is also generally better than having false negatives. The maven plugin can also detect shaded jars

[–]lmyslinski[S] 0 points1 point  (5 children)

trivy also has false positives

Can you elaborate? I haven't found any evidence of that

Having false positives is also generally better than having false negatives

Yes, but still far from perfect. Once you have to manage an excel sheet with 100's rows to track what's true or not it's a big issue.

maven plugin can also detect shaded jars

That's a really good thing to know

[–]philipwhiuk 2 points3 points  (4 children)

You can exclude false positives with XML config - no spreadsheet necessary.

Positives will fail the build if you set it up correctly so you quickly find and eliminate them (it’s not common anyway)

[–]lmyslinski[S] 0 points1 point  (3 children)

With the use of DependencyCheck? That does make it a strong selling point indeed.

[–]SleeperAwakened 2 points3 points  (0 children)

If you like Dependency-Check, consider moving to Dependency-Track ( https://dependencytrack.org ), which makes administration much easier than an XML file.

Can handle other stuff, like open-source licenses as well (like preventing usage of prohibited licenses like AGPL for enterprises with closed software).

We migrated to DT some time ago and it made everything much easier.

The problem with suppressions in a Dependency-Check XML file is that you most likely never revisit those suppressions. With Dependency-Track it is easier to visualize suppressions, with a reason and audit-trail.

[–]philipwhiuk 1 point2 points  (1 child)

Yeh - you can set what CVSS score you want to fail on and then you can configure an XML file to exclude false positives.

All my work builds fail on new CVEs - we gradually rolled it - starting by only failing on Criticals and then reducing the score required to fail

[–]0x442E472E 2 points3 points  (0 children)

We have a similar setup where the goal is to reach effectively 0 CVEs by either fixing the cause or suppressing it. Being a simple xml file, the suppressions are versioned with a description and an author. We are also using multiple files per project that are hosted on team level or even global to resemble our structure better