文章总结： 文章介绍了DependencyTrack这一开源软件成分分析工具，它能够识别项目中的直接依赖和传递依赖，并监控这些组件是否包含已知安全漏洞。通过实际案例演示了如何使用该工具分析项目风险，区分直接依赖和传递依赖的安全问题，并提供了最佳实践建议，如自动化扫描、分级处理等，帮助开发团队避免因依赖漏洞导致的安全事件。 综合评分： 87 文章分类： 漏洞分析,供应链安全,安全工具,安全建设,漏洞预警

如何用Dependency Track管理直接依赖和传递依赖?

原创

筑梦网安

全栈安全

2025年10月10日 06:56 浙江 标题已修改

你的代码真的安全吗？或许藏着无数你不知道的危险依赖！今天博主就带大家认识一个超级实用的软件成分分析工具——Dependency Track，它就像是软件的”成分检测仪”，能帮我们一眼看穿项目中隐藏的安全风险。

想象一下：你在超市买食品，肯定会看成分表避免有害添加剂吧？软件开发也是如此，但我们往往对自己引入的”成分”——各种开源依赖包——一无所知。岂曾想这正是安全漏洞最喜欢藏身之所！

1. 为什么需要软件成分分析（简称SCA）？

还记得2017年美国最大的征信机构之一的Equifax数据泄露事件吗？攻击者就是利用了一个Apache Struts框架的漏洞，导致1.43亿用户的个人信息泄露（包含姓名、社会保障号、出生日期、地址，以及一些驾驶执照号码等）。最可怕的是，Apache Struts早就发布了漏洞补丁，但Equifax公司根本不知道自己使用了这个有漏洞的组件！

若你对事件详情感兴趣，建议参阅文章：https://www.secrss.com/articles/7313。

这样的悲剧在软件开发中比比皆是。现代应用就像一副乐高积木，我们自己的代码只占一小部分，更多的是各种开源库和框架。研究表明，现代软件中 70%-96% 的代码都来自第三方依赖。

Synopsys：2024年开源安全和风险分析报告

如果你也对Synopsys发布的2024年开源安全和风险分析报告感兴趣，可以参阅往期博文：

解读 | Synopsys发布2024年开源安全和风险分析报告OSSRA

问题在于：如果你不知道自己在用什么，怎么可能保证安全性呢？

2. Dependency Track是什么？

Dependency Track就像是软件的”成分扫描仪”，它能够：

• 自动识别项目中的所有依赖组件（包括直接依赖和传递依赖）
• 持续监控这些组件是否包含已知安全漏洞
• 提供详细的风险评估和修复建议

Dependency Track是由OWASP发起并持续维护的开源软件，具有丰富的生态和强大的周边集成能力。

最重要的是，它区分直接依赖和传递依赖，让我们能精准定位问题源头！

3. 核心概念：直接依赖 vs 传递依赖

让我们用一个做蛋糕的比喻来理解这两个概念：

直接依赖：你做蛋糕时主动选择的原料，比如面粉、鸡蛋、糖。在项目中，这就是你在pom.xml或package.json中明确声明的依赖。

传递依赖：这些原料本身带来的”隐藏成分”。比如面粉中可能含有的添加剂，鸡蛋可能携带的细菌。在项目中，这是你的直接依赖所依赖的其他库，有时也称为间接依赖。

蛋糕的主要原料和它们带来的隐藏成分

在实际项目中，传递依赖往往占所有依赖的70%以上，而且是最容易被忽视的安全盲区！

Dependency Track解析出的组件依赖关系图

4. 实战演示：用Dependency Track分析项目

现在我来演示如何实际操作Dependency Track。我准备了一个常用的Java开源项目hutool作为例子，它包含有漏洞的依赖。

4.1. 步骤一：生成SBOM（软件物料清单）

首先，我们需要生成项目的”成分清单”—SBOM。我使用CycloneDX插件来生成：

# 使用Maven插件生成SBOM
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

生成的bom.json就像食品成分表，列出了所有”原料”：

Java开源项目hutool 5.8.40 SBOM文件

4.2. 步骤二：上传到Dependency Track平台

将bom.json上传到Dependency Track后，系统会自动开始分析：

DependencyTrack上传界面截图

4.3. 步骤三：查看分析结果

分析完成后，Dependency Track提供了清晰的项目仪表盘，直观展示项目健康状况：

hutool 5.8.40版本的项目风险看板

5. 重点来了：区分直接依赖和传递依赖的风险

这是我们今天最重要的部分！Dependency Track的优秀之处在于它能清晰区分不同来源的风险。

在我的示例项目中，发现了3个致命漏洞： 其中漏洞CVE-2020-9493 为远程代码执行漏洞。

查看漏洞组件的依赖关系图

问题定位过程：

1. 首先看到漏洞影响的是 hutool-log 5.8.40
2. 检查依赖关系发现：这是hutool项目直接依赖的hutool-all 带来的
3. 但hutool-all 本身没问题，是它依赖的hutool-log有漏洞

Dependency Track的依赖树显示功能让这个关系一目了然：

hutool项目
└── hutool-all (直接依赖) [5.8.40]
    └── hutool-log (传递依赖) [5.8.40] ⚠️ 存在漏洞

修复决策：

因为问题是传递依赖带来的，我有两种解决方案：

1. 升级直接依赖：将hutool-all升级到6.x版本，它使用了安全的hutool-log
2. 排除传递依赖：在依赖声明中明确排除有问题的组件

我选择了方案一，因为升级hutool-all是更彻底的解决方案。

6. 真实案例：我们是如何避免一次潜在的数据泄露的

我们会定期使用Dependency Track扫描所有项目。有一次，在一个即将上线的系统中，Dependency Track发出了严重警报：

一个看似无害的工具库带来了log4j 1.x版本，存在远程代码执行漏洞！

关键是：这个库是通过三层传递依赖引入的：

主项目 → 数据访问层 → 缓存工具 → 日志工具 → log4j 1.x

没有Dependency Track，我们根本不可能发现这个深藏不露的”定时炸弹”。通过提前发现并修复，我们避免了一次可能导致用户数据泄露的安全事件。

7. 最佳实践建议

根据我的实验经验，提供以下建议：

1. 自动化扫描：将Dependency Track集成到CI/CD流程中，每次构建自动扫描
2. 分级处理：优先处理直接依赖带来的风险，然后是传递依赖
3. 责任到人：设置策略自动将漏洞分配给相应组件的负责人
4. 持续监控：即使当时没有漏洞，新漏洞可能随时被披露

CI/CD流程集成Dependency Track

8. 总结

Dependency Track就像是给软件做的”全面体检”，能够：

• ✅ 识别所有依赖成分（直接+传递）
• ✅ 发现已知安全漏洞
• ✅ 提供清晰的修复路径
• ✅ 防止”Equifax式”的安全灾难

在这个软件定义一切的时代，主动管理软件成分不再是可选项，而是必备的安全实践。无论你是开发人员、安全工程师还是技术负责人，都应该立即开始使用Dependency Track这样的工具。

行动号召：

今天就开始吧！从你当前的项目入手，生成第一份SBOM，看看你的软件”成分表”里到底藏着什么惊喜（或惊吓）。

最后一问：

你有没有遇到什么意想不到的”隐藏成分”？你又是如何管理传递依赖的？记得在评论区分享你的想法哦！

推荐阅读：

• 软件物料清单SBOM详解
• 软件物料清单SBOM都没有，何谈软件供应链安全？
• CycloneDX：全栈软件供应链安全国际标准解读及优势分析
• SBOM主流格式SPDX介绍
• 使用主流开发语言的项目如何一键生成SBOM文件？

关注我，带你看懂技术本质！用最接地气的”人话”拆解硬核知识，让复杂概念变得简单易懂 🔥

添加好友邀请进技术交流群

每周更新：

• 💡 技术原理图解：一图胜千言，直观呈现技术架构
• 🛠️ 实战案例解析：结合真实项目经验，分享避坑指南
• 🤖 前沿技术追踪：第一时间解读AI、区块链等新兴领域

适合人群：

• ✅ 技术小白想系统入门
• ✅ 开发者想提升技术深度
• ✅ 产品经理需要技术洞察
• ✅ 所有对科技充满好奇的人

在这里你能获得：

• ✨ 复杂技术简单化
• ✨ 抽象概念具象化
• ✨ 理论知识实用化
• ✨ 学习路径清晰化

点击关注，开启你的技术认知升级之旅！ 🚀

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：全栈安全 筑梦网安《如何用Dependency Track管理直接依赖和传递依赖?》