1. 供应链安全概述
聊供应链安全之前，我先问大家一个问题：你写的代码，真的都是你写的吗？
别急着回答。我早年做移动端开发时，也觉得自己挺厉害的——框架用得好，第三方库用得溜。直到有一次，我负责的应用被安全团队拦了下来，说我们集成的某个开源库存在后门。我当时第一反应是：不可能吧？这个库我用了两年了。
嗯，后来查证的结果让我后背发凉。那个库的维护者账号被攻破，攻击者在代码里悄悄塞了一段逻辑——专门窃取用户输入的银行卡信息。而我们，浑然不觉。
这就是供应链安全要解决的问题。
什么是软件供应链
软件供应链，说白了就是你的软件从开发到交付，中间经过的所有环节和参与者。
你想想看，一个现代应用是怎么诞生的？
- 你从 GitHub 拉了个开源框架
- 用 npm 或 Maven 装了十几个依赖
- 调用了几个第三方 API
- 用了云厂商的 SDK
- 最后通过 CI/CD 流水线打包发布
这中间每一个环节，都是供应链的一部分。任何一个节点被污染，最终产物都不安全。
核心观点：软件供应链 = 代码 + 依赖 + 工具 + 流程 + 人。缺一不可，一环失守，全线崩溃。
供应链攻击的典型场景
说到供应链攻击，绕不开 SolarWinds 事件。这是我见过最经典的案例，也是让我彻底改变安全观念的转折点。
SolarWinds 事件回顾
2020 年，攻击者入侵了 SolarWinds 的构建系统，在 Orion 产品的更新包中植入了后门。这个后门藏得有多深？它伪装成正常的 XML 配置文件，混在合法的数字签名里。SolarWinds 自己都不知道，还把带毒的更新推送给了 18,000 多家客户。
受害者名单里包括美国财政部、国土安全部、甚至五角大楼。我当时的客户正好也在用 Orion，排查了整整两周才确认没中招。那两周，我几乎没睡过一个整觉。
| 攻击阶段 | 具体行为 | 危害等级 |
|---|---|---|
| 入侵构建环境 | 窃取签名证书，篡改源码 | 极高 |
| 植入后门 | 在合法更新包中藏入恶意代码 | 极高 |
| 分发带毒更新 | 通过官方渠道推送给客户 | 极高 |
| 横向移动 | 从受害客户内网窃取更多数据 | 极高 |
为什么会这么严重？因为攻击者利用了「信任链」。客户信任 SolarWinds 的数字签名，所以自动安装了更新。而攻击者恰恰利用了这份信任。
注意：SolarWinds 事件告诉我们一个残酷的事实——你信任的第三方，可能自己都不知道已经被攻破了。信任不能替代验证。
其他常见攻击场景
除了 SolarWinds 这种国家级攻击，日常开发中更常见的是这些：
- 依赖混淆攻击：攻击者把恶意包上传到公共仓库，包名和你们内部私有包一模一样。构建工具优先拉到了恶意版本。我见过一个团队因此泄露了数据库连接串。
- 恶意 npm 包：攻击者发布名字相近的包（typosquatting），比如把
lodash改成lodahs。手滑一次，全线崩溃。 - compromised CI/CD：攻击者拿到你的 Jenkins 或 GitHub Actions 权限，在构建脚本里插代码。你每次发布，都在帮攻击者打工。
- 第三方 SDK 后门：特别是广告 SDK、统计 SDK，它们权限大、更新频繁，很容易成为突破口。
为什么移动端需要关注供应链安全
你可能觉得，供应链攻击是后端的事，移动端能有多大风险？
说实话，我以前也这么想。直到我亲手处理过几个移动端的供应链安全事件，才意识到问题有多严重。
移动端的特殊性
移动端有几个「先天不足」：
- 依赖更重：一个典型的 Android 应用，依赖的第三方库少说几十个，多的上百个。每个库都有自己的依赖，形成一张巨大的依赖树。你根本不知道树底下藏着什么。
- 更新滞后：后端服务可以随时热修复，但移动应用发版要走应用商店审核。发现供应链问题后，修复周期至少几天到几周。这期间用户的数据可能一直在泄露。
- 逆向容易：移动应用包（APK/IPA）很容易被反编译。攻击者可以分析你的依赖，找到漏洞，甚至直接篡改包体重新分发。
- 证书绑定缺失：很多移动应用没有做证书绑定（Certificate Pinning），导致中间人攻击可以轻易拦截通信。我在项目中遇到过不止一次，客户的应用连基本的 HTTPS 校验都没做全。
我的建议：移动端供应链安全，要从「依赖管理」和「通信安全」两头抓。依赖管理解决「你用了什么」，通信安全解决「你信了谁」。这两件事做不好，其他安全措施都是白搭。
一个真实的移动端案例
去年我帮一个金融类 App 做安全审计。他们的推送 SDK 来自一家小厂商，集成了两年多一直没问题。结果有一天，那个 SDK 的厂商被黑了，攻击者通过 SDK 更新推送了恶意代码——可以读取短信验证码。
你想想，金融 App + 短信验证码 + 恶意 SDK，这组合有多致命？幸好发现得早，没有造成实际损失。但这件事让我彻底明白：移动端的供应链攻击，离我们一点都不远。
本章知识体系
下面这张图，是我梳理的供应链安全核心逻辑。你可以把它当作本章的「地图」：
从这张图你能看到，供应链安全不是单一的技术点，而是一条完整的链条。从你引入第一个开源依赖开始，到最终用户安装你的 App，中间每一个环节都可能成为攻击面。
我个人习惯把供应链安全分成三层来看：
- 入口层：你引入了什么？谁写的？有没有被篡改过？
- 传输层：代码在构建、分发过程中，有没有被中间人动手脚？
- 运行时层：最终运行的代码，和你写的是不是同一份？
这三层，每一层都有对应的攻击手法，也都有对应的防御策略。后面的章节，我会逐一展开。
一个小建议：如果你现在还不知道自己项目里用了哪些第三方依赖，建议立刻跑一遍 npm audit 或 gradle dependencies。先看清楚自己「吃」了什么，再谈怎么「防」。