2. 安全需求分析：安全需求的来源、分类与可验证性检查
各位同学好，我是老张。今天咱们聊聊安全需求分析。说实话，这个环节是整个安全验证工作的地基。地基没打好，后面盖的楼再漂亮也白搭。我在项目里见过太多因为需求没理清，最后验证阶段翻车的案例了。
2.1 安全需求的来源
安全需求从哪来？我总结下来，主要有这么几个渠道：
- 法律法规与行业标准：比如GDPR、ISO 26262、IEC 62304。这些是硬性要求，不满足就不能上市。
- 客户与用户要求：客户在招标书里写的安全条款，或者用户反馈中暴露的隐私担忧。
- 威胁建模与风险评估：通过STRIDE、PASTA等方法分析出来的风险点，转化成具体需求。
- 历史缺陷与事故：我之前处理过一个案例，某款设备因为固件签名校验缺失被远程攻击。后来这个缺陷直接变成了一个强制安全需求。
- 内部安全策略：公司内部的安全基线、编码规范、架构原则。
我的习惯：每次启动新项目，我都会先拉一个“需求来源清单”，把上面这些渠道都过一遍。别嫌麻烦，漏掉一个可能后面要花十倍精力补。
2.2 安全需求的分类
安全需求不是铁板一块。我个人习惯把它们分成三大类：功能安全、信息安全、隐私保护。你想想看，这三者关注的点其实完全不同。
| 类别 | 关注点 | 典型示例 |
|---|---|---|
| 功能安全 | 系统在故障时能否安全运行 | 刹车系统在单点故障下仍能减速 |
| 信息安全 | 防止恶意攻击与未授权访问 | 固件签名校验、安全启动 |
| 隐私保护 | 个人数据的收集、存储与使用合规 | 用户生物特征数据本地处理，不上传云端 |
嗯，这里要注意。这三类需求有时候会互相冲突。比如功能安全要求系统在紧急情况下能快速响应，但信息安全要求每次操作都要鉴权。怎么平衡？这就是架构师和验证工程师要一起解决的问题了。
2.3 需求可验证性检查
这是我最想强调的部分。很多团队写需求写得天花乱坠，到了验证阶段才发现根本没法测。说白了，不可验证的需求就是废纸一张。
我总结了一个“可验证性检查清单”，每次评审需求时我都会拿出来过一遍：
- 是否具体？ 避免“系统应足够安全”这种废话。改成“系统应在100ms内检测到篡改并触发告警”。
- 是否可测量？ 有没有明确的通过/失败标准？比如“加密算法应使用AES-256-GCM”。
- 是否可测试？ 测试环境能不能复现？测试工具是否具备？我曾经遇到一个需求要求“抗量子攻击”，但当时连测试工具都没有，只能先标记为“待定”。
- 是否无歧义？ 不同的人读同一句话，理解应该一致。避免“适当的保护措施”这种模糊表述。
避坑指南：我曾经接手过一个项目，需求里写着“用户数据应被安全存储”。结果开发用了明文存储，说“我觉得挺安全的”。从那以后，我要求所有安全需求必须写明具体算法、密钥长度、存储位置。
2.4 知识体系框架
下面这张图是我自己画的，把安全需求分析的核心逻辑串起来了。你仔细看看，应该能一目了然。
2.5 实战中的注意事项
最后分享几个我在实战中踩过的坑：
- 别把安全需求当成功能需求的附属品。 很多团队把安全需求写在功能需求的“备注”里，结果开发直接忽略。我建议单独建一个安全需求库，和功能需求平级管理。
- 需求评审一定要拉上验证工程师。 为什么？因为只有验证工程师才知道这个需求到底能不能测。我曾经在评审会上直接怼回去：“这个需求你写得很漂亮，但我拿什么工具测？你给我造一个？”
- 需求变更要有追溯机制。 安全需求经常因为架构调整而变更。每次变更都要问一句：对应的验证用例要不要改？测试环境要不要更新？
警告：千万不要在项目后期才做安全需求分析。我见过一个团队，产品都快量产了才想起来做安全评估，结果发现架构层面有根本性缺陷，只能推倒重来。成本损失以百万计。
好了，关于安全需求分析就聊这么多。记住一句话：需求分析阶段多花一小时，验证阶段能省十小时。这是我从无数次加班中总结出来的血泪教训。
公众号:蓝海资料掘金营，微信deep3321