Which problem does Dependency-Track solve that Dependabot doesn't solve already?

[AbdelHajou]

Hi all,

I am working on a project where I'm using Dependency-Track a lot. My supervisor asked me a few tricky questions about why I chose for Dependency-Track instead of just using something like Dependabot. I also noticed this GitHub repository uses Dependabot, so my question to you is:
Which problem does Dependency-Track solve that Dependabot doesn't solve already?
If a project uses Dependabot and keeps all dependencies up-to-date, which added value does Dependency-Track bring (apart from license policies and the fancy dashboard)? And is Dependency-Track meant to replace Dependabot, or should they be used alongside each other?

Disclaimer: I'm not asking this question because I don't like Dependency-Track, I would just like to raise some discussion so that I can better justify my choice for Dependency-Track.

[ruckc]

Dependabot helps track things in individual repositories. Depedency-track gives you a top-down view of all the repositories. You can even track commercial software if you get vendors to provide SBOM's.

…

On Fri, Apr 8, 2022, 10:01 Abdel Hajou ***@***.***> wrote: Hi all, I am working on a project where I'm using Dependency-Track a lot. My supervisor asked me a few tricky questions about why I chose for Dependency-Track instead of just using something like Dependabot. I also noticed this GitHub repository uses Dependabot, so my question to you is: *Which problem does Dependency-Track solve that Dependabot doesn't solve already?* If a project uses Dependabot and keeps all dependencies up-to-date, which added value does Dependency-Track bring (apart from license policies and the fancy dashboard)? And is Dependency-Track meant to replace Dependabot, or should they be used alongside each other? Disclaimer: I'm not asking this question because I don't like Dependency-Track, I would just like to raise some discussion so that I can better justify my choice for Dependency-Track. — Reply to this email directly, view it on GitHub <#1519>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK4HYPED65VPJVKC4HBPXDVEA34VANCNFSM5S4UY7QQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msymons]

Further to what @ruckc has said: whilst Dependabot will take care of upgrading a component when an upgrade is available it won't help when there is no fix available. Additionally, it won't help when you have a transitive dependency that has a vulnerability if you are not managing that dependency.

Also, in practice one will often end up "teaching" Dependendabot and (say) allowing only patch and minor upgrades for a particular component where one is not yet ready for a major upgrade (ie, cannot upgrade client for server X until server X is itself upgraded). But such decisions have consequences... one might have no vulnerability exposure today and half a dozen vulnerabilities within a short time. It is Dependency-Track that reveals the consequences!

Thus, an ideal approach is to use BOTH Dependabot (or alternative such as Snyk) AND Dependency-Track.

Dependency-Track will then provide assurance that Dependabot is doing a good job. It will also provide insights that will help you refine your projects so that Dependabot can do an even better job. eg, for Maven, add transitive dependencies to dependencyManagement or exclude them if they are not being used.