工程项目渗透报告怎么写

上周帮一家建筑公司审他们的工程渗透测试报告，四十多页，项目写翻到第三页我就想关掉PDF。渗透全是报告漏洞列表、CVSS分数、工程截图，项目写唯独没有“所以呢”。渗透甲方老板看完了大概率只会问一句：“那我要不要换防火墙？报告”——这就是问题所在。

写渗透报告，工程核心就一句话：让不懂安全的项目写人能做出决策，让懂安全的渗透人能复现漏洞。别把报告写成漏洞字典。报告

先讲结论，工程再讲过程

开头直接写“这次测试发现3个高危、项目写2个中危，渗透其中某个OA系统可以被未授权访问，攻击者能直接拿到服务器权限”。三行字说清楚。别从项目背景、测试范围、人员安排开始铺垫——那是给档案室看的，不是给项目经理看的。

我见过一份报告，花了整整两页描述测试方法遵循了OWASP标准，结果最严重的问题是一个默认口令的SQL注入。谁在乎你用了什么标准？甲方只想知道“我的工地大门是不是没锁”。

漏洞描述要“有血有肉”

每个漏洞别只贴个“SQL注入，高危，CVSS 8.6”就完事。写清楚三件事：怎么发现的、能造成什么实际影响、怎么修。

比如：“测试人员发现登录接口存在时间盲注，用sqlmap跑了一个小时就拖出了用户表，里面包含管理员密码的MD5值（弱口令，可直接破解）。攻击者利用这个漏洞可以登录后台，修改楼宇自控系统的温度设定——简单说，夏天能把整栋楼的空调关了。”这种描述，连物业经理都能看懂严重性。

复现步骤比截图重要

截图当然要有，但别截个HTTP请求包就完事。写清楚“点击哪个按钮、输入什么参数、看到什么响应”。我遇到过最离谱的事：开发人员拿着报告来找我，说“这个漏洞我复现不了”，结果是他漏看了报告里一行小字——“需在登录状态下发送特定Cookie”。

好的复现步骤应该像菜谱，照着做一定能炒出那道菜。别写“构造恶意请求”，要写“在Burp Suite中拦截请求，将参数ID改为1' AND SLEEP(5)--，发送后观察响应时间是否超过5秒”。

风险等级别瞎定

很多报告把“低危”写成“高危”，为了显得自己发现了大问题。有一次测试某工地监控系统，发现一个反射型XSS，明明需要诱导管理员点击恶意链接才能触发，报告里却标了个“高危”。甲方吓得连夜找供应商，结果发现根本没法利用——因为系统只在内网跑，且没有浏览器交互场景。

定级要结合业务场景。一个暴露在公网的弱口令是“严重”，一个仅内网可访问的CSRF是“中低危”。别拿CVSS分数当圣旨，它只是参考。

修复建议要“能落地”

别写“加强输入验证”这种废话。要写“在Login.php第47行，对username参数添加htmlspecialchars()过滤，同时使用参数化查询”。最好给出代码示例，哪怕只是伪代码。甲方开发人员不是安全专家，你写“建议使用WAF”他可能真去买个WAF，结果根本问题没解决。

有个技巧：每个高危漏洞的修复建议里，写一句“如果短期无法修复，可先通过防火墙限制来源IP访问该接口作为临时缓解措施”。给条活路，别把人逼死。

最后，别忽略“好的方面”

报告里加一小节“做得好的地方”。比如“项目使用了较新的K8s版本，且RBAC权限划分合理，未发现越权风险”。这不是客套话，是帮甲方留住预算——如果报告全是负面，老板可能砍掉整个安全预算，说“反正也防不住”。正面反馈让报告更可信，也让后续合作有空间。

写报告就像跟朋友讲你发现的问题——直接、具体、有建议，别绕弯子。你写的是给人看的文档，不是给漏洞库投稿。