据说，一个应用里有80%的代码不是开发人员写的，而是来自于应用所依赖的第三方组件、库。这些第三方组件或者库如果含有已知安全漏洞，那么应用程序也会遭殃。比如说，《Apache Tomcat CVE-2020-1938，细思极恐》这篇文章里介绍的漏洞，就足以让人感到后背发凉。
可能你听说过甚至用过开源社区OWASP出品的DependencyCheck这款开源工具来扫描软件中的第三方组件（也叫‘依赖’）的安全性，可是今天我们要讲的不是这个工具，而是另一款名字和它非常相似的工具：DependencyTrack，同样也是OWASP出品。
这两个工具就一字之差，DependencyCheck和DependencyTrack，都是做依赖安全检查的，有啥本质区别？简单讲，如果说DependencyCheck是给开发团队使用的工具，那么DependencyTrack更多的是给安全团队使用的工具。企业或者组织中的安全团队可以借助DependencyTrack实现第三方组件的统一安全管理。
各个开发团队使用到的第三方组件（包括第三方组件自己所依赖的其他第三方组件，换句话讲，依赖的依赖）都被汇总到了DependencyTrack这里，所以它可以很方便的帮助安全团队从全局的角度来追踪、管理第三方组件安全。这也正是DependencyTrack本质上区别于DependencyCheck的地方，后者更多是的为单个开发团队所用，为单个应用程序检查第三方组件的安全，仅此而已。
DependencyTrack的功能挺丰富的，识别含有已知安全漏洞的依赖是核心功能，此外还有展示统计信息的Dashboard，提供持续集成插件，可以方便的做漏洞影响分析，等等，更详细的介绍可以看他们的官网：https://dependencytrack.org/
抛开现象看本质，我认为这个工具主要还是为例应对下面这两个最典型的场景：
场景1： 作为一个拥有多个开发团队的企业，如果某天某个第三方组件爆出了安全漏洞，那么如何在最短的时间里确认：
- 我们有这么多开发团队，有没有那个团队在用这个第三方组件？
- 用了这个第三方组件的团队，他们使用的组件的版本是否受此次漏洞影响？
场景2： 作为一个拥有多个开发团队的企业，各个团队当前使用的第三方组件的情况各不相同，从全局风险的角度来看，当前这些被使用的第三方组件的安全状况如何？例如：
- 是否有团队在使用含有已知安全漏洞的组件？
- 是否某个被使用的第三方组件已经过时？
- 是否某个或某些组件的License不合规或者存在风险？
业界其实并不缺少第三方依赖安全管理工具、平台、服务之类的，但做的好的基本都是商业收费服务，OWASP DependencyTrack大概是这些工具的“平替（平价替代）”吧，其实严格来讲应该是“免替（免费替代，我随便乱造的词）”。
以上是关于DependencyTrack的纯理论介绍，那么这个工具怎么搭建？怎么使用？有没有什么坑？这些内容我在下篇文章里为大家进行分享。