第四章：摘要与执行摘要撰写
如何用一页纸讲清楚核心发现、风险等级、影响范围
说实话，我见过太多固件逆向报告了。有的写得像天书，技术细节堆了三十页，老板翻了两页就扔一边了。有的又太简略，连漏洞怎么触发都没说清楚。
真正好的摘要，就是一页纸的事。你想想看，管理层每天要看多少报告？他们没时间跟你抠细节。他们要的是：出了什么问题？有多严重？我该不该现在拍板修？
这一章，我就跟你聊聊怎么写好这一页纸。我自己的习惯是，先写摘要，再写正文。因为摘要写清楚了，整个报告的逻辑也就顺了。
核心原则：摘要不是正文的缩略版，而是决策的支撑材料。它要回答三个问题——发现了什么、有多危险、影响多大。
4.1 摘要的结构：三段式
我个人习惯把摘要分成三块。每一块都有明确的目的，不多不少。
- 核心发现——你发现了什么？一句话说清楚。
- 风险等级——这个发现有多危险？用标准评级。
- 影响范围——谁会受影响？影响多大？
我曾经在一个项目中，发现了一个UART调试接口未关闭的问题。当时我写了三页纸的分析，结果产品经理直接说：“你就告诉我，这个口子开着，黑客能不能远程搞事情？”嗯，从那以后，我的摘要再也没超过一页。
4.2 核心发现：一句话定乾坤
核心发现要写得像新闻标题。别绕弯子，直接说重点。
错误写法：“在对固件进行逆向分析的过程中，我们发现了一个可能存在的缓冲区溢出漏洞，该漏洞位于网络协议栈的某个处理函数中。”
正确写法：“固件网络协议栈存在缓冲区溢出漏洞，攻击者可远程执行任意代码。”
你看，后者多干脆。管理层不需要知道你是怎么发现的，他们只需要知道结果。
我的小技巧：写完核心发现后，自己读一遍。如果一句话说不清楚，说明你还没想明白。重写。
4.3 风险等级：用标准说话
风险等级不能拍脑袋。我建议用CVSS（通用漏洞评分系统）来定级。这样有据可查，管理层也信服。
| 等级 | CVSS分数 | 说明 |
|---|---|---|
| 严重 | 9.0 - 10.0 | 可远程利用，无需认证，影响所有设备 |
| 高危 | 7.0 - 8.9 | 可远程利用，但需要一定条件 |
| 中危 | 4.0 - 6.9 | 需要本地访问或特定配置 |
| 低危 | 0.1 - 3.9 | 影响有限，利用难度高 |
举个例子。我之前分析过一个智能门锁的固件，发现了一个硬编码的后门账号。CVSS评分9.8，妥妥的严重级别。为什么？因为攻击者不需要任何认证，直接就能远程开锁。这种漏洞，管理层必须立刻决策。
注意：别为了引起重视而虚报风险等级。我见过有人把低危漏洞标成高危，结果被CTO当众质疑。信用一旦丢了，以后你的报告就没人信了。
4.4 影响范围：量化才有说服力
影响范围不能只说“影响很大”。要量化。用数字说话。
错误写法：“该漏洞影响大量设备。”
正确写法：“该漏洞影响固件版本v2.1.0至v2.3.5，涉及约50万台已出货设备，覆盖A、B、C三个产品线。”
你看，后者清清楚楚。管理层一看就知道：哦，50万台，三个产品线，这事得赶紧处理。
我自己的习惯是，在影响范围里再分三块：
- 受影响版本：具体到固件版本号
- 受影响设备：产品型号、数量
- 受影响用户：是否涉及敏感数据、关键业务
4.5 一页纸摘要的模板
下面是我自己一直在用的模板。你可以直接套用。
# 固件安全分析摘要
## 核心发现
[一句话描述，例如：固件网络协议栈存在缓冲区溢出漏洞，攻击者可远程执行任意代码]
## 风险等级
CVSS评分：[分数] | 等级：[严重/高危/中危/低危]
## 影响范围
- 受影响版本：[固件版本号]
- 受影响设备：[产品型号，数量]
- 受影响用户：[描述]
## 建议措施
- 短期：[例如：关闭受影响端口]
- 长期：[例如：发布固件更新]
## 附件
- 详细分析报告（共X页）
- 漏洞复现步骤
这个模板我用了好几年。每次写摘要，我就把内容往里填。填完再读一遍，确保每句话都有信息量，没有废话。
4.6 写给管理层看的技巧
管理层不是技术专家。他们关心的是：成本、时间、风险。所以你的摘要要围绕这三个点来写。
- 成本：修复这个漏洞要花多少钱？不修复会损失多少钱？
- 时间：多久能修好？多久会被攻击者利用？
- 风险：不修的话，最坏情况是什么？
我记得有一次，我给一个IoT设备厂商做安全审计。发现了一个远程代码执行漏洞。我写摘要的时候，特意加了一句：“该漏洞若被利用，攻击者可控制设备发起DDoS攻击，可能导致整个云平台瘫痪。”就这一句话，CEO当场拍板：立刻停止发货，紧急修复。
记住：管理层不怕问题，怕的是不知道问题有多严重。你的摘要，就是帮他们看清问题的放大镜。
4.7 避坑指南
写摘要这么多年，我踩过不少坑。分享几个给你。
- 别写技术细节：“栈溢出发生在memcpy函数中，参数len未做边界检查”——这种话留给正文。摘要里只需要说“存在缓冲区溢出漏洞”。
- 别用模糊词：“可能”、“大概”、“也许”——这些词会让管理层觉得你没把握。要么确定，要么不说。
- 别忽略修复建议：光说问题不说怎么解决，那是耍流氓。管理层要的是方案，不是问题清单。
我曾经有一次，写摘要时忘了写修复建议。结果CTO看完直接问我：“你告诉我这个漏洞很严重，然后呢？我该怎么做？”从那以后，我的摘要里永远有“建议措施”这一块。
4.8 知识体系图
下面这张图，是我自己总结的摘要撰写逻辑。你可以照着这个思路来写。
这张图说白了就是：先找到核心发现，再给它定级，然后说清楚影响范围。三步走完，一页纸摘要就出来了。
4.9 最后说两句
写摘要这件事，说难不难，说简单也不简单。关键是要站在读者的角度想问题。管理层要的是决策依据，不是技术论文。你给他们一页纸，他们就能拍板。你给他们三十页，他们反而不知道该怎么办。
我自己的经验是：每次写完摘要，先放一晚上。第二天再读一遍，看看有没有废话，有没有模糊的地方。如果有，就改。直到每一句话都经得起推敲。
嗯，这一章就到这里。记住：一页纸，三个问题，一个决策。