一、SSDLC概述：安全开发流程在ADAS中的落地
1.1 什么是SSDLC？
SSDLC，全称是安全软件开发生命周期。说白了，就是在传统开发流程里，把安全这件事从头管到尾。
我习惯这么跟团队解释：传统开发是先做功能，再补安全；SSDLC是边做功能，边做安全。 你想想看，这就像盖房子——是先打好地基再砌墙，还是等房子盖好了再往墙里塞钢筋？
SSDLC的核心思想其实就一句话：安全左移。把安全活动提前到需求、设计阶段，而不是等到上线前才手忙脚乱地修漏洞。
SSDLC的五个核心阶段：
- 需求阶段 — 定义安全需求，比如「这个功能必须防篡改」
- 设计阶段 — 做威胁建模，画数据流图，找攻击面
- 开发阶段 — 写安全代码，用静态扫描工具检查
- 测试阶段 — 做渗透测试、模糊测试、安全回归
- 运维阶段 — 监控告警、应急响应、持续改进
我在项目中遇到过不少团队，觉得SSDLC就是多了一堆文档和流程。其实不是。它更像是一套安全习惯——就像你开车前会系安全带一样自然。
1.2 为什么ADAS需要SSDLC？
这个问题，我每次给新团队培训都会先问一遍。答案其实很直接：ADAS系统出安全问题，是会死人的。
你想想看，一个手机App有漏洞，最多是数据泄露。但ADAS系统呢？
- 摄像头被欺骗，车辆可能误判障碍物
- CAN总线被注入，刹车可能失效
- OTA升级包被篡改，整个系统可能被劫持
我记得有一次，我们在做某个L2+项目的安全评审。测试团队发现了一个缓冲区溢出漏洞——攻击者可以通过恶意构造的雷达数据包，让ECU直接崩溃。嗯，这要是上路了，后果不敢想。
所以，ADAS需要SSDLC，原因有三：
| 原因 | 具体说明 |
|---|---|
| 功能安全与信息安全交织 | ISO 26262和ISO 21434现在都要求安全开发流程。两者不是替代关系，是互补关系。 |
| 攻击面太大 | ADAS系统有传感器、通信、云端、OTA……每个环节都可能被攻击。 |
| 修复成本极高 | 车端软件不像手机App能随时热更新。一个安全漏洞，可能意味着召回。 |
⚠️ 注意： 我曾经见过一个团队，在项目交付前两周才发现安全测试没做。结果呢？加班加点补漏洞，最后还是带着风险上线了。这就是没有SSDLC的代价。
1.3 SSDLC与传统开发流程的区别
很多人觉得，SSDLC不就是多了一个安全测试环节吗？其实远不止这么简单。
我画个对比你就明白了：
| 对比维度 | 传统开发流程 | SSDLC |
|---|---|---|
| 安全介入时机 | 上线前才做安全测试 | 从需求阶段就开始介入 |
| 安全负责人 | 通常是安全团队的事 | 全员参与，安全是每个人的责任 |
| 文档要求 | 基本没有安全文档 | 威胁模型、安全需求、测试报告……全套 |
| 工具链 | 可能只有静态扫描 | SAST、DAST、IAST、模糊测试、SCA…… |
| 变更管理 | 改代码就改代码 | 变更必须重新评估安全影响 |
说白了，传统开发是「先跑起来再说」，SSDLC是「跑起来之前先看看会不会翻车」。
我举个例子。传统开发里，开发人员写了个CAN报文解析函数，测试人员测了功能正常就过了。但在SSDLC里，开发人员写代码前要先做威胁建模——「如果有人恶意构造一个超长的CAN报文，我的代码会不会崩？」然后写代码时加上边界检查，测试时还要做模糊测试。
💡 我的建议： 刚开始推行SSDLC时，别想着一步到位。我一般建议团队先做两件事：威胁建模和安全测试。这两件事做好了，其他环节慢慢补。贪多嚼不烂，你想想看是不是这个道理？
1.4 避坑指南：我踩过的几个坑
做SSDLC落地这些年，我踩过的坑真不少。分享几个典型的：
- 坑一：把SSDLC当成文档游戏。 我曾经见过一个项目，威胁建模文档写得漂漂亮亮，但代码里该有的漏洞一个不少。为什么？因为文档是安全团队写的，开发团队根本没参与。记住：SSDLC不是写文档，是改变开发习惯。
- 坑二：安全测试只做一次。 有些团队在项目收尾时做一次渗透测试就完事了。但代码是不断迭代的，每次变更都可能引入新漏洞。我建议：每次迭代都做安全回归。
- 坑三：忽视供应链安全。 ADAS系统用了大量第三方库和组件。你代码写得再安全，一个开源库的漏洞就能把你打回原形。所以，软件物料清单（SBOM）一定要做。
一句话总结： SSDLC不是银弹，但它能帮你把安全风险从「碰运气」变成「可管理」。在ADAS这个领域，安全不是加分项，是准入门槛。
好了，第一章就聊到这儿。下一章我们聊聊威胁建模在ADAS中的具体实践——这可是我花了好几年才摸索出来的经验，到时候细说。