Dependency-Track：分析开源组件漏洞，帮助组织识别和减少软件供应链中的风险
Dependency-Track：分析开源组件漏洞，帮助组织识别和减少软件供应链中的风险
研发过程中被忽略的开源组件安全
2021年底的Log4j核弹级漏洞刚过去，近期XZ漏洞又被推上热搜。近期准备结合一些工具实践，介绍下关于研发过程中的开源治理，也是近些年被炒的很火的“供应链安全”。
Log4j 是 Apache 的一个开源日志框架，它允许开发者在应用程序中使用日志记录功能。2021年12月31日，Apache软件基金会发布了Log4j的严重安全漏洞（CVE-2021-44228）通知，漏洞可能允许远程攻击者执行代码，影响Log4j 2.x <= 2.14.1 和 Log4j 1.x <= 1.2.17 版本。
回到漏洞爆发那天晚上
研发团队是否在紧急修复漏洞？
- 我们有这么多开发组，有没有哪个团队在用这个第三方组件？
- 用了这个第三方组件的团队，他们使用的组件的版本是否受此次漏洞影响？
- 虽然我的团队没直接用Log4j, 但是我依赖别的团队的服务，他们是否中招了？
安全运营团队是否在紧急排查？
- 各个研发团队，快紧急排查自己用了Log4j没？
- 用的什么版本？
- 哪个项目，哪个版本用了Log4j 2.x <= 2.14.1 和 Log4j 1.x <= 1.2.17 版本
甲方客户是否在问你交付的产品带了漏洞没？
- 前一段采购的你们产品，有这个风险没？
- 怎么证明没有漏洞呢？
- 外包服务商他们是否合规？
日常研发安全运营
从整个组织来看，各个团队当前使用的第三方组件的情况各不相同。从全局风险的角度来看，当前这些被使用的第三方组件的安全状况如何？
- 是否有团队在使用含有已知安全漏洞的组件？
- 是否某个被使用的第三方组件已经过时？
- 是否某个或某些组件不合规或者存在风险？
- 团队是否已经修复了？
- 日常怎么预防？
- 遇到Log4j 和XZ漏洞 ，如何立即做出响应？
对于上述场景，业界其实并不缺少第三方依赖安全管理工具、平台、服务之类的，特别是近些年如雨后春笋般出现，很遗憾好点的都是商业收费的，或者是免费的SAAS简单检测服务。
这里介绍一款免费的，OWASP DependencyTrack，勉强可以拿来试试看。
Dependency-Track：帮助组织识别和减少软件供应链中的风险
?OWASP，全称Open Web Application Security Project，是一个非盈利组织，致力于提升Web应用程序的安全性。它旨在为开发人员、安全专家和组织提供一个开放、透明和合作的平台，以改善Web应用程序的安全性。OWASP的主要目标是通过教育、研究和开发开源工具，提供有关Web应用程序安全的知识和资源。 OWASP发布了一系列的安全项目、工具、文档和指南，帮助开发人员和安全专家识别和解决Web应用程序中的安全漏洞和风险。其中，OWASP Top 10是该组织发布的一份关于Web应用安全风险的清单，旨在帮助开发者和安全专家识别并防范最常见的安全威胁，如SQL注入、跨站脚本攻击（XSS）等。
Dependency-Track是OWASP支持并推出的一个开源的、持续的软件物料清单（SBOM）分析平台。该平台集成了多种漏洞数据库，并提供了一系列功能，帮助组织识别和管理其软件供应链中的安全风险。通过Dependency-Track，用户可以跟踪和分析项目中的组件使用情况，及时发现潜在的安全漏洞，并采取相应措施来减少风险。此外，该平台采用API优先设计，非常适合在持续集成和持续交付（CI/CD）环境中使用。
工作原理
如下图，使用插件对代码项目生成bom.xml，类似pip request requirements，清点出使用的Software BOM(软件物料清单)。Dependency Track通过接收到生成SBOM，然后SBOM中的各个组件(以及当前清单中的版本)在漏洞数据库中是否存在已知安全漏洞的记录，并通过Dashboard展示出来。
111.png
?SBOM是什么？SBOM（Software Bill of Material）翻译之后称为软件物料清单。通俗的解释就是我们用到的所有第三方组件依赖（包括第三方组件自己所依赖的其他第三方组件，换句话讲，依赖的依赖）的信息清单，这些内容包括author、group, licenses, versions and copyright等数据。生成SBOM的工具有几个，其中比较有名的是CycloneDX。一旦我们有了BOM文件，我们就可以手动或通过整合CI/CD中的上传功能将其上传到Dependency-Track。Dependency track相当于一个漏洞库和分析引擎，它基于SBOM，在漏洞库中搜索，这样我们就可以获得比传统组件分析更完整、更复杂的信息。
主要特性
跨团队漏洞趋势统计追踪
在管理第三方组件安全这件事上，开发团队只需要知道当前依赖有没有安全问题，以及有哪些安全问题就足够了，但安全团队还额外掌握更多信息，例如需要了解当前各个开发团队使用的第三方组件的整体安全状态如何（例如有多少第三方组件存在已知安全问题、相关团队占比多少等）。
Dependency-Track提供了Dashboard视图，把所有接入Dependency-Track扫描的团队或者说应用程序所使用到的第三方组件、第三方组件中存在的安全漏洞等信息以可视化的图表方式呈现了出来，很好的满足了安全团队的需求。
在日常安全运营过程中，这些统计数据、趋势分析数据可以作为某种指标，能够告诉安全团队当前第三方组件安全风险是在持续降低还是升高，相关的安全控制措施实施之后，也能通过这些指标来观察措施产生的效果到底如何。
支持多漏洞数据库
- https://docs.dependencytrack.org/analysis-types/known-vulnerabilities/
对于组件漏洞的分析，依赖于丰富的漏洞库，越多越好，单一漏洞数据库，有可能会出现漏报或者误报的情况。Dependency-Track集成了多个漏洞情报来源，以识别具有已知漏洞的组件。平台采用了几种漏洞识别方法，包括:
- NVD，美国国家漏洞数据库
- ~~NPM Public Advisories，NPM出品的关于JS及Node.js包、库的漏洞数据库，这个数据库里可能包含了不在NVD数据库中的漏洞 ~~（PS:最新版本4.10已经废弃）
- Snyk: 著名的商业漏洞服务厂商
- Sonatype OSS Index，Sonatype的漏洞数据库，可以通过组件的Package URLs进行漏洞查找，精确度很高，并且这个漏洞数据库里也包含了一些不在NVD数据库中的漏洞新
- VulnDB，Risk Based Security的漏洞数据库，数据质量可能比NVD更好一些
上面的每个分析器都可以彼此独立地启用或禁用。
研发视角组件列表&提供反向追溯能力
安全团队肯定碰到过这样的情况，某天，某个第三方组件爆出了安全问题，安全团队紧急联系各个开发团队，要求他们立即排查确认是否有用到这个第三方组件，而开发团队其实也难以第一时间给出答案，他们还需要到CI流水线上去翻看扫描报告，或者自己手动排查整个依赖树。一来一去时间可能就浪费了，错过了宝贵的漏洞响应时间。而对于没有使用这个第三方组件的团队而言，这种做法又给他们增加了信息噪音。
在Dependency-Track的帮助下，这个故事可以有另一个结局。Dependency-Track除了记录了各个开发团队的应用程序所使用的各种第三方依赖信息，可以方便的从团队或者应用程序的视角去深挖用到了哪些依赖，它还反过来提供了Component视图，使得我们可以从第三方组件的维度出发，去查看有哪些开发团队用到了某个第三方组件。这个功能简直是安全团队的福音，如此一来，安全团队就可以以最快的速度直接通知对应的团队采取应对措施了。
消息提醒
- https://docs.dependencytrack.org/integrations/notifications/
在日常使用Dependency-Track对依赖进行例行性的安全扫描操作的时候，可能会产生一些漏洞告警信息，另外，每当Dependency-Track主动监控发现某个依赖存在新爆出来的安全漏洞的时候，也会产生告警信息。这些信息都可以通过Dependency-Track提供的消息提醒功能及时的传递给安全团队、开发团队。
需要特别说明的是，从组件进行审计的功能再结合消息提醒功能，就可以实现依赖安全的持续自动化监控和提醒机制。Dependency-Track提供Console、Email、Microsoft Teams、Slack以及Webhook等通知提醒模式，提醒内容也可以定制。
这里只简单介绍主要特性，其实还有更多好玩的，特别是它的生态体系。关注我，下一篇具体介绍它的使用和集成。