背景

在日常安全工作中，我们可能会经常遇到以下两个比较典型的场景：

场景1:如果某天某个第三方组件爆出了安全漏洞，那么如何在最短的时间里确认：

  • 我们有这么多开发组，有没有哪个团队在用这个第三方组件？
  • 用了这个第三方组件的团队，他们使用的组件的版本是否受此次漏洞影响？

场景2：各个团队当前使用的第三方组件的情况各不相同，从全局风险的角度来看，当前这些被使用的第三方组件的安全状况如何？例如：

  • 是否有团队在使用含有已知安全漏洞的组件？
  • 是否某个被使用的第三方组件已经过时？
  • 是否某个或某些组件不合规或者存在风险？

DependencyTrack是什么？

image.png

Dependency-Track是OWASP推出的一个智能供应链组件分析平台，它集成了4种漏洞数据库：NPM Public Advisories、National Vulnerability Database、Sonartype OSS Index和VulnDB，帮助组织识别和减少使用第三方和开源组件的风险。

https://docs.dependencytrack.org/

简单来说，识别含有已知安全漏洞的依赖是核心功能，此外还有展示统计信息的Dashboard，提供持续集成插件，可以方便的做漏洞影响分析等等
image.png

Dependency-Check和Dependency-Track的区别

https://docs.dependencytrack.org/odt-odc-comparison/
可能你听说过甚至用过开源社区OWASP出品的DependencyCheck这款开源工具来扫描软件中的第三方组件（也叫‘依赖’）的安全性，可是今天我们要讲的不是这个工具，而是另一款名字和它非常相似的工具：DependencyTrack，同样也是OWASP出品。

这两个工具就一字之差，DependencyCheck和DependencyTrack，都是做依赖安全检查的，有啥本质区别？简单讲，如果说DependencyCheck是给开发团队使用的工具，那么DependencyTrack更多的是给安全团队使用的工具。企业或者组织中的安全团队可以借助DependencyTrack实现第三方组件的统一安全管理。

各个开发团队使用到的第三方组件（包括第三方组件自己所依赖的其他第三方组件，换句话讲，依赖的依赖）都被汇总到了DependencyTrack这里，所以它可以很方便的帮助安全团队从全局的角度来追踪、管理第三方组件安全。这也正是DependencyTrack本质上区别于DependencyCheck的地方，后者更多是的为单个开发团队所用，为单个应用程序检查第三方组件的安全，仅此而已。

业界其实并不缺少第三方依赖安全管理工具、平台、服务之类的，但做的好的基本都是商业收费服务，OWASP DependencyTrack大概是这些工具的“平替（平价替代）”吧，其实严格来讲应该是“免替

核心生态架构

image.png

从上图信息，结合实际业务场景，我们可以带入以下维度：

  • 发版:对接Jenkins来扫描存在漏洞信息
  • 仓库:maven jar依赖包信息
  • 开发过程：基于soner bug追踪的组件安全跟踪，甚至fortify这样的代码白盒review介入
  • 监控告警：Webhooks->钉钉

工作模式：
工具接收到生成的Software BOM(软件物料清单)，然后检查物料清单中的各个组件(以及当前清单中的版本)在漏洞数据库中是否存在已知安全漏洞的记录，并通过Dashboard展示出来
image.png

  1. SBOM(Software Bill of Material)中文名叫软件物料清单，如果你构建了一个应用程序，使用到了一些第三方组件，那么这个SBOM清单里就有你的应用程序所依赖的所有第三方组件的信息(当然还有第三方组件的第三方组件)，其中最重要的就是组件的标识符(group、name、version)以及PURL数据。有了这些数据，DT才能到漏洞数据库里做搜索。
  2. 有很多工具可以帮我们生成SBOM。我用Gradle做构建工具，所以用的cyclonedx-gradle-plugin，如果你用maven，可以用CycloneDXMavenPlugin

    安装

    curl -LO https://dependencytrack.org/docker-compose.yml
    docker-compose up -d

    使用

集成DevOps流水线

参考

https://cyclonedx.org/tool-center/
https://www.cnblogs.com/sevck/p/13969900.html