渗透测试报告写不好，客户看完直摇头
老张是某安全公司的技术骨干，上周刚做完一家银行的渗透测试。结果报告交上去没两天，客户反馈：问题描述太模糊，修复建议像在猜谜，根本没法落地。其实这种情况并不少见，很多技术人员技术过硬，但写出来的报告却让人看得云里雾里。
问题一：漏洞描述太技术，业务人员看不懂
比如写“存在SQL注入风险，payload可触发数据库报错”，这话对开发没问题，但管理层和运维可能一脸懵。换成“攻击者可通过登录框输入特殊字符，直接获取用户数据表内容”，是不是清楚多了？报告不是技术笔记，得让不同角色都能理解风险在哪。
问题二：复现步骤不完整，别人没法验证
有些报告只写“访问某个URL即可触发XSS”，但没说用什么浏览器、要不要登录、参数怎么构造。正确的做法是分步写清楚：
1. 使用Chrome登录系统
2. 在搜索框输入 <script>alert(1)</script>
3. 提交后页面弹出提示框
这样别人才能准确复现，也显得你专业靠谱。
问题三：风险等级乱标，高危变中危
有的团队图省事，把所有Web漏洞都标成“高危”。结果真正严重的RCE（远程代码执行）和一个信息泄露并列，客户反而不知道优先修哪个。建议参考CVSS标准打分，结合实际影响说明。比如内网管理系统的SQL注入，虽然利用条件受限，但一旦突破就是全线失守，这种必须强调潜在连锁反应。
问题四：修复建议太笼统，等于没说
写“建议加强输入过滤”这种话，跟没写一样。开发最烦这个。应该具体到函数层面，比如：
<?php
$username = mysqli_real_escape_string($conn, $_POST['username']);
?>问题五：缺少上下文，看不出攻击路径
单一漏洞不可怕，可怕的是组合拳。有份报告曾忽略这一点：只写了“存在弱口令”和“文件上传无限制”，但没说明攻击者可以用弱口令登录后台，再上传木马拿服务器权限。补上这条攻击链后，客户立马升级为紧急处理。
附录模板比正文还长
见过最夸张的报告，正文8页，附录工具输出截图占了50页。客户根本不想翻。建议只保留关键请求响应截图，扫描器原始数据打包另附。重点突出核心问题，别让有效信息被淹没。
做渗透测试，发现问题只是第一步，能把问题说清楚才是真本事。毕竟客户要的不是一份技术秀，而是一份能指导整改的行动指南。