用DependencyTrack管理第三方组件安全(一)

据说,一个应用里有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的纯理论介绍,那么这个工具怎么搭建?怎么使用?有没有什么坑?这些内容我在下篇文章里为大家进行分享。