上周我拿到一份新人的扫描扫描报告，二十多页，漏洞漏洞倒是报告不少，但翻到第三页我就想扔了。扫描不是漏洞因为漏洞多，而是报告因为根本看不懂他在说什么。IP地址、扫描端口号、漏洞漏洞名称，报告全堆在一起，扫描像超市小票。漏洞我问他某台数据库服务器到底能不能被打穿，报告他给我指了第17页的扫描第4行——那里只写着一行CVSS分数：9.8。

写扫描漏洞报告，漏洞第一原则是报告：别让读者做侦探。你的读者可能是运维、研发主管，甚至是老板。他们不关心你用了什么扫描器，不关心你跑了几个插件。他们只想知道三件事：哪里有问题、有多严重、怎么修。

开篇别整虚的，直接写结论。比如：“内网核心交换机的SNMP服务使用默认口令，攻击者可直接读取全部路由表。”就这一句，比任何摘要都管用。我习惯在报告最前面放一个“高危速览”框，三到五条，每条不超过两行字。就像急诊室的分诊台，先告诉护士谁快不行了。

漏洞描述部分，别复制粘贴NVD的官方描述。那玩意儿说的是技术理论，不是你的环境。我见过最蠢的报告，把“Apache HTTP Server 2.4.49存在路径遍历漏洞”原样抄上，但仔细一查，那台服务器压根没开Web服务。你得写“这台服务器运行着旧版Apache，虽然当前没对外提供网页，但它连着内网财务系统，一旦被横向利用，后果很严重”——这才叫结合环境。

风险等级不能只看CVSS。有一次我遇到个中危漏洞，是某台备份服务器上的弱口令。按分数确实不高，但那台机器存着全公司所有数据库的备份文件。我直接标成“高”，并在旁边写了一句：“如果这个口令被猜中，等于拿到了所有生产数据的钥匙。”分数是死的，人是活的。适当主观判断，比机械打分靠谱得多。

修复建议务必给具体操作。别写“建议升级到最新版本”，你得写“将Apache升级至2.4.50及以上版本，具体命令：yum update httpd -y。升级前请确认业务兼容性，建议先在一台测试机验证。”如果暂时无法修复，就写临时缓解措施，比如“在防火墙上限制该端口只允许特定IP访问”。

还有个细节，很多人忽略——时间戳。每个漏洞的发现时间、复测时间、确认修复的时间，都要写清楚。倒不是为别的，而是为了一个月后有人质疑你“这个漏洞怎么没发现”时，你能拿出证据说：“当时测了，没爆，现在爆了，说明是最近才引入的。”做安全这行，保护自己跟保护系统一样重要。

最后，报告里一定要有“已验证”或“未验证”的标记。我吃过亏，有次报了十几个漏洞，结果其中两个是扫描器误报。从那以后，高危漏洞我全部手工验证一遍，并在报告里注明“已通过手工请求确认，响应包中包含/etc/passwd内容”。没验证的，单独列个“待确认”区，别混在一起。

写报告说到底是在讲故事，讲你如何发现系统薄弱点的故事。故事要有开头（漏洞怎么被发现的）、有冲突（有多危险）、有结局（怎么解决）。别写成流水账，也别写成散文。把每个漏洞当作一个病例，既要写症状，也要写病因，更要写处方。这样，你的报告才不会躺在垃圾桶里，而是真正被人拿去做事。