代码审计方法论：从计划到报告的完整闭环

做安全审计这么多年，我最大的感受是——没有方法论的审计，就像闭着眼睛找bug。你可能会碰巧发现几个问题，但永远不知道还有多少漏洞藏在深处。

今天我就把这套方法论掰开揉碎了讲给你听。嗯，都是我在真实项目中摔打出来的经验。

一、审计流程：四步走，步步为营

我习惯把审计流程分成四个阶段：计划 → 收集 → 分析 → 报告。听起来简单？但每一步都有坑。

1. 计划阶段：别急着看代码

很多人拿到项目就开干，这是大忌。你想想看，连目标范围都没搞清楚，怎么审？

• 确定审计目标：是找安全漏洞？还是合规检查？还是代码质量评估？目标不同，侧重点完全不同。
• 划定范围：哪些模块要审？哪些可以跳过？我曾经接手过一个项目，客户说"全审"，结果代码量200万行...后来我学会了先做关键路径分析。
• 收集背景信息：业务逻辑、技术栈、开发团队水平——这些都会影响你的审计策略。
• 制定时间表：别高估自己的速度。我一般按每1000行代码2-4小时来估算，但复杂逻辑要翻倍。

2. 收集阶段：信息就是弹药

这个阶段的目标只有一个——拿到所有你需要的东西。

• 源代码：完整可编译的版本，别只给片段
• 构建脚本：Makefile、CMakeLists.txt、CI/CD配置
• 依赖清单：第三方库的版本号、来源
• 文档：设计文档、API文档、测试报告
• 历史漏洞记录：之前修过什么？怎么修的？

我记得有一次，客户只给了编译后的二进制文件，说"代码丢了"。我当场就拒绝了——没有源码的审计，就是盲人摸象。

3. 分析阶段：核心中的核心

这里我分两条线走：自动化扫描和人工审查。

自动化工具能帮你快速筛掉低 hanging fruit，比如未初始化变量、缓冲区溢出风险。但真正要命的逻辑漏洞，还得靠人眼。

我个人的习惯是：先跑工具，再看结果，最后手动深挖。工具报告里的每个告警，我都会问自己三个问题：

1. 这是真漏洞还是误报？
2. 如果利用，会造成什么后果？
3. 有没有类似的模式在其他地方出现？

4. 报告阶段：让结果说话

审计报告是你的最终交付物。写得不好，前面所有工作都白费。

我见过太多报告，堆满了技术术语，老板看不懂，开发不想看。好的报告应该做到：

• 分层次：给老板看摘要，给开发看细节
• 可复现：每个漏洞都要有清晰的复现步骤
• 有建议：别只说"这里有问题"，要说"建议改成这样"
• 定优先级：哪些必须马上修？哪些可以缓缓？

二、威胁建模：STRIDE 与 DREAD

威胁建模说白了就是站在攻击者的角度想问题。我常用的两个框架：STRIDE 用来找威胁，DREAD 用来排优先级。

STRIDE：六类威胁，一个不漏

威胁类型	含义	C++中的典型场景
Spoofing（欺骗）	冒充他人身份	未校验调用者身份，伪造输入
Tampering（篡改）	修改数据或代码	内存写越界、整数溢出导致数据篡改
Repudiation（抵赖）	否认做过某操作	缺少日志审计，无法追溯操作
Information Disclosure（信息泄露）	敏感数据被窃取	未加密的密码、堆栈信息泄露
Denial of Service（拒绝服务）	系统不可用	无限递归、资源未释放导致崩溃
Elevation of Privilege（权限提升）	获得更高权限	未做权限检查，越权调用接口

我在做嵌入式系统审计时，最常遇到的是Tampering和DoS。为什么呢？因为C++里指针满天飞，一个越界就能让整个系统崩掉。

DREAD：给威胁打分

找到威胁后，你得知道先修哪个。DREAD 就是干这个的：

• Damage（损害程度）：如果被利用，损失多大？
• Reproducibility（可复现性）：攻击者能稳定复现吗？
• Exploitability（利用难度）：需要什么条件？
• Affected Users（影响范围）：多少用户受影响？
• Discoverability（发现难度）：攻击者容易发现吗？

每个维度打1-3分，总分越高越危险。我一般把12分以上的定为"立即修复"，8-11分的"本周内修复"，8分以下的"下次迭代修"。

三、风险评级：别把小事当大事

风险评级不是拍脑袋。我有一套自己的标准：

风险等级	定义	响应时间	示例
严重	可导致远程代码执行、数据泄露	24小时内	堆溢出、use-after-free
高危	可导致局部功能失效、权限提升	1周内	整数溢出、未初始化指针
中危	需要特定条件才能利用	1个月内	资源泄漏、日志信息泄露
低危	影响极小，或利用条件苛刻	下次迭代	代码风格问题、未使用的变量

这里有个坑：别把"低危"当成"不用修"。低危漏洞堆多了，一样会出事。我见过一个系统，因为十几个低危漏洞组合利用，最终实现了提权。

四、审计报告编写：让每一页都有价值

报告怎么写？我总结了一个三段式结构：

1. 执行摘要：1-2页，给管理层看。说清楚发现了多少漏洞、严重程度、总体风险。
2. 技术细节：每个漏洞的详细描述、复现步骤、影响分析、修复建议。
3. 附录：工具输出、代码片段、参考资料。

写技术细节时，我习惯用这个模板：

漏洞ID：VULN-2024-001
漏洞类型：缓冲区溢出
风险等级：严重
影响模块：Network::PacketParser
复现步骤：
  1. 构造一个超过1024字节的UDP包
  2. 发送到目标端口8080
  3. 观察程序崩溃
根因分析：
  memcpy()未校验输入长度，导致栈缓冲区溢出
修复建议：
  使用std::vector代替固定数组，或添加边界检查
参考代码：
  // 修复前
  char buf[1024];
  memcpy(buf, input, input_len);
  
  // 修复后
  std::vector<char> buf(input_len);
  memcpy(buf.data(), input, input_len);

五、知识体系总览

下面这张图，是我对这套方法论的总结。你可以把它当成一个检查清单，每次审计前过一遍：

这套方法论，我用了快十年。从最初的生搬硬套，到现在的融会贯通，最大的体会是——方法只是工具，思考才是核心。你拿着STRIDE清单一个个对，不如真正理解每个威胁背后的攻击意图。

好了，这一章就到这里。记住：没有方法论的审计是碰运气，有方法论的审计是系统工程。下一章，我们深入代码层面，看看C++里那些最常见的漏洞模式。

---

公众号:蓝海资料掘金营，微信deep3321