第3章：安全验证策略制定
好，咱们进入正题。安全验证策略，说白了就是回答三个问题：测什么？测多深？怎么测？这三个问题搞定了，你的验证工作就有了主心骨。
我见过不少团队，一上来就铺开测，结果测了一堆无关紧要的东西，真正要命的地方反而漏了。嗯，这就是典型的「没有策略」。
3.1 基于风险的验证策略
为什么要基于风险？道理很简单——资源有限，时间更有限。你不可能把每个功能、每行代码都测到天荒地老。所以，把好钢用在刀刃上。
我个人习惯的做法是三步走：
- 识别资产：哪些数据/功能是核心？比如用户密码、支付接口、加密密钥。
- 评估威胁：这些资产可能被谁攻击？用什么手段？
- 定优先级：高风险的先测，低风险的后测，甚至不测。
核心原则：风险越高，验证越深。别在无关紧要的地方浪费精力。
举个例子。我在项目中遇到过一款物联网设备，团队花了大量时间测UI界面，结果固件升级接口没有任何签名校验。攻击者直接上传恶意固件，整批设备变砖。你说这风险优先级怎么定？
这里我画了一张图，帮你理清思路：
小技巧：我习惯用「风险值 = 可能性 × 影响程度」这个公式来量化。虽然粗糙，但比拍脑袋强多了。
3.2 验证级别：单元、集成、系统
验证不是一锤子买卖。你得在不同层面做不同的事。我把它分成三个级别：
| 验证级别 | 关注点 | 典型方法 | 我踩过的坑 |
|---|---|---|---|
| 单元验证 | 单个函数/模块的安全逻辑 | 代码审查、静态分析、单元测试 | 曾经有个加密函数，单元测试全过，但集成后才发现密钥硬编码了 |
| 集成验证 | 模块间交互的安全边界 | 接口测试、数据流分析、契约测试 | 两个模块各自安全，但数据传过去就出问题了 |
| 系统验证 | 整体安全架构与端到端防护 | 渗透测试、红蓝对抗、合规审计 | 系统级测试最容易被忽视，但攻击者往往从这里入手 |
你想想看，单元验证就像检查每个士兵的枪有没有问题。集成验证是看士兵之间能不能配合好。系统验证则是整个部队能不能打赢一场仗。缺了哪一层都不行。
注意：别以为单元验证做得好，系统就安全了。我曾经见过一个项目，每个模块都通过了严格的安全审查，结果集成后因为一个配置文件的权限设置错误，整个系统被攻破。这就是典型的「局部安全≠整体安全」。
3.3 验证方法选择：静态 vs 动态
静态和动态，说白了就是「看代码」和「跑代码」的区别。但什么时候用哪个，这里头有讲究。
静态验证
不运行代码，直接分析源码或二进制。适合早期发现结构性问题。
- 优点：覆盖面广，能发现隐藏路径
- 缺点：误报率高，无法验证运行时行为
- 适用场景：代码规范检查、安全漏洞模式匹配、数据流分析
动态验证
让代码跑起来，观察实际行为。适合发现运行时问题。
- 优点：结果真实，能发现逻辑漏洞
- 缺点：覆盖率有限，依赖测试用例质量
- 适用场景：模糊测试、渗透测试、压力测试
我个人习惯的做法是：先静态后动态，两者互补。静态分析帮我快速扫一遍，找出明显的漏洞。动态测试则针对高风险区域深入挖掘。
经验之谈：对于高风险模块（比如认证、授权、加密），我建议静态和动态都做。对于低风险模块（比如日志记录），静态分析就够了。别一刀切。
举个例子。我在项目中遇到过一段登录代码，静态分析发现它用了MD5哈希密码。嗯，这明显不安全。但动态测试跑起来才发现，更严重的问题在后面——它居然把明文密码写进了日志文件。静态分析没发现这个，因为日志写入是另一个模块的事。你看，这就是为什么两者都要做。
3.4 如何制定你的验证策略
好了，理论说完了。咱们来点实际的。我一般按这个步骤来：
- 画攻击树：列出所有可能的攻击路径
- 标风险等级：给每条路径打分
- 选验证方法：高风险用动态+静态，中风险用静态，低风险用自动化扫描
- 定验证级别：单元测什么，集成测什么，系统测什么
- 写策略文档：把以上内容写清楚，让团队有据可依
避坑指南：我曾经犯过一个错误——策略文档写得太抽象，团队看了不知道怎么执行。后来我改成「针对X模块，使用Y工具，执行Z测试用例」这种具体描述，效果好了很多。
最后说一句。验证策略不是一成不变的。随着项目推进，你会发现新的风险点，原来的策略可能需要调整。别怕改，怕的是不改。
公众号:蓝海资料掘金营，微信deep3321