4、第三方组件依赖分析：解析项目依赖文件、构建依赖树、识别直接依赖与传递依赖

依赖分析这件事，说白了就是搞清楚你的项目到底用了哪些“外人”写的代码。我见过太多团队，项目跑得好好的，一上线就出问题——最后发现是某个不起眼的第三方库带了漏洞。嗯，今天我们就来聊聊怎么把依赖这摊事理清楚。

4.1 依赖文件长什么样？

不同语言、不同生态，依赖文件的格式千差万别。但核心逻辑都一样：声明“我要用谁”和“用哪个版本”。

Java / Maven 项目：pom.xml

我个人习惯先看 <dependencies> 块。每个 <dependency> 就是一个直接依赖。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>2.7.0</version>
</dependency>

Node.js 项目：package.json

这里分 dependencies 和 devDependencies。生产环境只关心前者。

{
  "dependencies": {
    "express": "^4.18.0",
    "lodash": "4.17.21"
  }
}

Python 项目：requirements.txt

这个最简单，一行一个包名加版本约束。

flask==2.2.0
requests>=2.28.0
我的小技巧： 别只看顶层文件。很多漏洞藏在传递依赖里。我曾经排查过一个 Log4j 漏洞，发现项目根本没直接引用 Log4j，但一个消息队列客户端把它带了进来。

4.2 构建依赖树——把“关系网”画出来

依赖树是什么？就是你的项目依赖了 A，A 又依赖了 B，B 又依赖了 C…… 这棵树越长，风险越大。

Maven 项目：

mvn dependency:tree

输出示例：

[INFO] com.example:my-app:jar:1.0
[INFO] +- org.springframework.boot:spring-boot-starter-web:jar:2.7.0:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter:jar:2.7.0:compile
[INFO] |  |  +- org.springframework.boot:spring-boot:jar:2.7.0:compile
[INFO] |  |  +- org.springframework.boot:spring-boot-autoconfigure:jar:2.7.0:compile
[INFO] |  |  +- org.springframework.boot:spring-boot-starter-logging:jar:2.7.0:compile
[INFO] |  |  |  +- ch.qos.logback:logback-classic:jar:1.2.11:compile
[INFO] |  |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.17.2:compile

Node.js 项目：

npm ls

输出示例：

my-app@1.0.0 /path/to/project
├── express@4.18.0
│   ├── accepts@1.3.8
│   ├── array-flatten@1.1.1
│   └── body-parser@1.20.0
│       └── bytes@3.1.2
└── lodash@4.17.21

Python 项目：

pipdeptree

输出示例：

flask==2.2.0
  - click [required: >=8.0, installed: 8.1.3]
  - itsdangerous [required: >=2.0, installed: 2.1.2]
  - Jinja2 [required: >=3.0, installed: 3.1.2]
    - MarkupSafe [required: >=2.0, installed: 2.1.1]
  - Werkzeug [required: >=2.2.2, installed: 2.2.2]
核心要点： 依赖树里缩进越深的包，越容易被忽略。但漏洞往往就藏在这些“深水区”。

4.3 直接依赖 vs 传递依赖——谁更危险？

直接依赖：你在 pom.xml 或 package.json 里亲手写进去的。

传递依赖：你写的包自己又引用了别的包，你“被动”用上的。

你想想看，直接依赖出了问题，你还能第一时间发现。传递依赖呢？你可能根本不知道它存在。

类型 可控性 风险等级 排查难度
直接依赖 高（你可以主动升级或替换） 中 低
传递依赖 低（受上游包版本约束） 高 高
我曾经踩过的坑： 有一次项目上线前扫描，发现一个高危漏洞在 snakeyaml 上。我翻遍所有直接依赖，都没找到它。最后用 mvn dependency:tree 一查，发现是 spring-boot-starter-web 通过 jackson-databind 间接引用的。当时版本锁死在 1.30，而修复版本是 1.33。我不得不手动在 pom.xml 里加了一条 <dependency> 强制覆盖版本。

4.4 实战：三步搞定依赖分析

  1. 第一步：导出依赖树

    用上面提到的命令，把依赖树导出成文本文件。我习惯保存为 dependencies.txt 或 dependency-tree.log。

  2. 第二步：标记直接依赖

    对照你的项目配置文件，把直接依赖圈出来。剩下的就是传递依赖。

  3. 第三步：交叉比对漏洞库

    用 OWASP Dependency-Check、Snyk 或 GitHub Dependabot 扫描。重点关注那些“不是自己写的但版本很老”的传递依赖。

自动化建议： 我建议把依赖树扫描集成到 CI/CD 流水线里。每次构建都自动跑一遍，有新增的传递依赖就报警。别等到上线前才查，那时候改起来成本太高。

4.5 常见问题与避坑指南

  • 版本冲突怎么办？

    Maven 默认用“最近优先”策略。Node.js 用“扁平化”策略。但不管哪种，都可能引入不兼容版本。我建议用 mvn dependency:tree -Dverbose 查看冲突详情。

  • 传递依赖太多，看不过来？

    别试图全部手动审查。用工具做自动化扫描，只关注有 CVE 编号的漏洞版本。其他版本差异可以暂时忽略。

  • 要不要锁定所有传递依赖版本？

    我个人不推荐。锁死所有版本会让升级变得极其痛苦。我建议只锁定那些有安全风险的传递依赖，其他的让包管理器自动处理。

依赖分析这件事，说白了就是“知己知彼”。你连自己项目里用了哪些第三方代码都不清楚，怎么谈安全？嗯，从今天开始，养成每次构建都看一眼依赖树的习惯吧。

← 上一章 📖 返回目录 下一章 →