漏洞文档

凌晨两点，漏洞文档我盯着屏幕上那个标红的漏洞文档CVE-2023-1234，骂了句脏话。漏洞文档这个漏洞在厂商的漏洞文档官方文档里只占了三行字，描述含糊得像在写诗——“某些情况下，漏洞文档系统可能表现出非预期行为。漏洞文档”

“某些情况”是漏洞文档什么情况？“非预期行为”是什么行为？我翻了半天，最后在某个技术论坛的漏洞文档犄角旮旯里，看到一个老哥用三张截图还原了完整的漏洞文档攻击链。他也没写分析，漏洞文档就贴了段Python脚本，漏洞文档末尾加了句“你们自己看吧”。漏洞文档

漏洞文档最大的漏洞文档问题不是缺信息，是漏洞文档缺人味儿。

我见过一份写得极其规范的漏洞文档漏洞报告，字段齐全，CVSS评分算到小数点后两位，影响版本列得清清楚楚。可你读完之后根本不知道这个漏洞到底怎么触发——它把所有关键条件都藏在了“详见附件”四个字后面，而那个附件是个需要特定权限才能访问的SharePoint链接。

这就像给你一把钥匙，却不告诉你门在哪。

还有另一种极端。有些文档写得像小说，开头先讲发现漏洞的心路历程，中间穿插团队协作的感人故事，最后在倒数第二段才告诉你“哦对，那个参数如果传一个超长的字符串，程序会崩”。你翻了三页纸，就为了找那一句技术细节。

我自己的习惯是，写漏洞文档先写“怎么复现”，用最笨最直接的方式。不写“攻击者可利用该漏洞”，直接写“打开这个URL，在参数后面加%00，然后看响应头”。

去年我们团队处理过一个开源组件的漏洞，官方文档里写着“建议升级到最新版本”。但最新版本本身就有兼容性问题，升级之后老系统直接起不来。后来我们在内部文档里补了一句：“如果暂时不能升级，可以用nginx拦截特定路径，实测有效，但会损失部分功能。”这才是人话。

漏洞文档本质上是一种沟通工具，不是给机器读的规范文件。它服务的是那些半夜爬起来处理告警的运维，是那些被客户逼着出报告的乙方，是那些刚入职三天就要接手历史遗留系统的倒霉蛋。

所以我现在写文档，会刻意加一些“脏东西”——比如“这个漏洞在Windows Server 2012上稳定复现，但2016版偶尔会触发，原因不明，怀疑跟内存分配策略有关”。

“原因不明”这四个字，比任何严谨的推测都有用。它告诉后来的人，别在这个方向上浪费时间了，直接绕过去。

文档里也该允许骂人。我见过最有效的内部记录是：“这个模块的代码写得跟屎一样，别碰，直接重写。”底下跟帖的人没人反驳，因为大家都踩过坑。

漏洞文档的终极形态，应该是让一个从没接触过这个系统的人，拿着你的文档，能在半小时内复现问题。不是让他理解原理，不是让他欣赏你的分析思路，就是单纯地把问题弄出来。

至于那些“影响范围”“修复建议”之类的章节，写个大概就行。真正救命的，永远是那段能跑起来的PoC，和那句“别用默认配置”。

天快亮了。我把那份三行的官方文档打印出来，在空白处写满了批注，贴在工位上。旁边同事路过看了一眼，说：“这字儿真丑。”

我说：“但你看得懂。”