2、供应链威胁建模：STRIDE模型在ADAS供应链中的应用、资产识别、威胁场景分析
好，咱们进入第二个话题。供应链威胁建模。
说实话，很多团队做ADAS安全，只盯着自家产品。ECU是自己的，代码是自己的，觉得安全可控。但你想过没有——你用的那颗雷达芯片，来自第三方的供应商；你集成的那个感知算法，是某个初创公司提供的；甚至你产线上烧录的固件，都可能经过外包工厂的手。
这些环节，每一个都是攻击面。我见过不止一个项目，因为供应链上的一个漏洞，导致整个系统被攻破。所以，威胁建模必须延伸到供应链。
2.1 为什么是STRIDE？
STRIDE模型，微软提出的，六个维度：Spoofing（欺骗）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。
为什么选它？因为STRIDE覆盖了供应链中最常见的攻击类型。我个人习惯，做供应链安全分析时，直接拿STRIDE当checklist，挨个过一遍，基本不会漏。
举个例子，你采购的摄像头模组，如果供应商没有做固件签名，攻击者可以替换固件——这就是Tampering。如果供应商的OTA升级通道没有加密，攻击者可以窃取升级包——这就是Information Disclosure。你看，STRIDE每个字母都能对应到具体场景。
核心观点：STRIDE不是万能的，但在ADAS供应链这个场景下，它足够实用。你不需要复杂的理论，只需要一张表，把每个资产、每个威胁类型填进去，威胁场景就清晰了。
2.2 资产识别：先搞清楚你要保护什么
做威胁建模之前，第一步永远是资产识别。没有资产清单，你都不知道该防什么。
ADAS供应链中的资产，我一般分成三类：
- 硬件资产：传感器（摄像头、雷达、激光雷达）、域控制器、执行器（刹车、转向）、通信模块（V2X、T-Box）。
- 软件资产：感知算法、融合算法、决策规划、控制算法、操作系统、中间件、OTA客户端。
- 数据资产：标定参数、高精地图、用户隐私数据、车辆VIN、密钥证书。
嗯，这里要注意。很多团队只关注硬件和软件，忽略了数据资产。我在项目中遇到过，某供应商提供的标定参数文件没有加密，攻击者拿到后可以伪造传感器数据，导致AEB误触发。这就是数据资产保护不到位。
我的建议：资产识别时，拉上采购、研发、质量三个部门一起做。采购知道供应商交付了什么，研发知道哪些是核心代码，质量知道测试数据有多重要。三方一碰，资产清单就全了。
2.3 威胁场景分析：STRIDE逐项拆解
资产清单有了，接下来就是威胁场景分析。我习惯用STRIDE的六个维度，每个维度列出可能的威胁场景。
下面这张表，是我做项目时常用的模板，你可以直接拿来用：
| STRIDE维度 | 威胁场景描述 | 典型攻击路径 | 影响等级 |
|---|---|---|---|
| Spoofing | 攻击者伪造传感器数据或身份 | 伪造CAN报文、伪造GPS信号、伪造V2X消息 | 高 |
| Tampering | 攻击者篡改供应链中的代码或配置 | 篡改固件、修改标定参数、替换算法模型 | 高 |
| Repudiation | 供应商否认其交付物存在漏洞 | 缺乏日志审计、无数字签名、无版本追溯 | 中 |
| Information Disclosure | 敏感数据在供应链传输中被泄露 | 窃取标定文件、截获OTA升级包、泄露密钥 | 高 |
| Denial of Service | 攻击者使供应链关键节点失效 | 攻击OTA服务器、阻塞诊断接口、耗尽ECU资源 | 中 |
| Elevation of Privilege | 攻击者通过供应链漏洞获得更高权限 | 利用供应商调试接口提权、利用未授权API | 高 |
你看，每个维度都能找到对应的场景。我建议你拿着这张表，对照自己的供应链，一个一个问：这个场景可能发生吗？如果发生，后果是什么？
避坑指南：我曾经犯过一个错误——只关注了“高”影响等级的威胁，忽略了“中”等级的。结果有一次，某个供应商的OTA服务器被DoS攻击，导致所有车辆无法升级，整整停摆了三天。所以，别小看任何威胁等级。
2.4 实战案例：一个雷达供应链的威胁建模
光讲理论没意思，我拿一个真实案例给你拆解。
某Tier 1供应商提供毫米波雷达，用于AEB功能。我们做威胁建模时，资产清单包括：雷达硬件、雷达固件、标定参数、CAN通信报文。
用STRIDE逐项分析：
- Spoofing：攻击者可以通过CAN总线伪造雷达目标报文，让车辆误以为前方有障碍物。解决方案：CAN报文加CRC和消息认证码。
- Tampering：供应商的固件更新包没有签名，攻击者可以替换固件。解决方案：要求供应商提供签名固件，并在ECU端验签。
- Repudiation：供应商交付的固件版本与测试报告不一致，但无法追溯。解决方案：建立SBOM（软件物料清单），每个版本都有哈希值记录。
- Information Disclosure：标定参数通过明文邮件传输，被第三方截获。解决方案：使用加密通道传输，参数文件本身也加密存储。
- Denial of Service：攻击者向雷达发送大量无效CAN报文，导致雷达处理超时。解决方案：CAN总线增加速率限制和过滤机制。
- Elevation of Privilege：雷达的调试串口未禁用，攻击者可以进入调试模式修改配置。解决方案：量产时禁用调试接口，或增加物理访问控制。
你看，每个威胁场景都有对应的缓解措施。这就是STRIDE的价值——它帮你系统性地找出问题，而不是靠拍脑袋。
个人经验：做完威胁建模后，一定要输出一份《供应链威胁清单》，分发给所有相关供应商。我曾经要求一家供应商整改固件签名问题，对方一开始觉得没必要，直到我拿出威胁场景分析报告，他们才意识到严重性。说白了，数据说话最有力。
2.5 小结
供应链威胁建模，说白了就是“先识别资产，再分析威胁，最后定措施”。STRIDE模型给了你一个框架，但真正落地，需要你结合自己的供应链特点。
嗯，我建议你从最简单的开始——拿一张纸，左边写资产，右边写STRIDE六个维度，挨个过一遍。你会发现，很多之前没注意到的风险，一下子就暴露了。
下一章，我们会讲如何把这些威胁场景转化为具体的安全需求。到时候，你会看到威胁建模的最终价值——不是发现问题，而是解决问题。