渗透测试的价值，最终落在一份报告上。再漂亮的利用，如果写不清”哪里有洞、有多严重、怎么修”，客户和开发都无从下手。这一篇讲报告怎么写，让技术发现变成可执行的整改单。
报告只描述已授权范围内的发现，不泄露可被广泛滥用的完整利用脚本；交付给授权客户并协助修复。
报告的目的
一份好报告要同时满足三方：
- 老板/客户：看懂”我们有多大风险、要不要花钱修”；
- 开发：拿到”具体哪行代码、怎么改”；
- 合规/审计：留下”我们做过安全测试”的证据。
所以报告既要”讲人话”给决策层，又要”给代码”给执行层。
标准结构
1. 封面与基本信息
- 项目名称、客户、测试方；
- 测试时间、范围、授权编号；
- 报告版本、密级。
2. 执行摘要（Executive Summary）
给老板看的”一页纸”：
- 整体安全状况（如”存在 3 个高危、5 个中危”）；
- 最严重风险及业务影响；
- 总体建议（限期修复、加强培训等）。
不要在这里写技术细节，用业务语言。
3. 测试范围与方法
- 目标清单、边界、时间；
- 用的方法/工具（PTES、OWASP WSTG、Nmap、AWVS…）；
- 免责声明（仅授权范围、未测部分）。
4. 漏洞详情（核心，逐条）
每条漏洞一个卡片，包含：
- 标题：如”SQL 注入导致用户数据泄露”；
- 风险等级：严重/高/中/低/信息，附 CVSS 评分；
- 位置：URL、参数、文件行号；
- 描述：漏洞原理（一两段，让非技术也懂）；
- 复现步骤：请求示例、payload（适度，不提供可广泛滥用的完整武器化脚本）；
- 影响：能造成什么后果；
- 修复建议：具体、可操作（如”改用参数化查询，示例代码如下”）；
- 证据：截图、响应片段（脱敏）。
5. 风险汇总表
| 漏洞 | 等级 | 位置 | 状态 |
|---|---|---|---|
| SQL 注入 | 高 | /search?id | 待修复 |
| XSS | 中 | /comment | 待修复 |
6. 附录
- 工具列表、原始数据、参考链接（OWASP、CVE）。
风险等级怎么定
常用 CVSS 评分（0–10）映射到等级，也可按业务影响定性：
- 严重：直接拿服务器/拖库/越权管理员；
- 高：可窃取敏感数据、普通用户提权；
- 中：需一定条件（如配合社工）才能利用；
- 低：信息泄露、配置瑕疵，影响有限；
- 信息：仅建议项，无直接危害。
定级要兼顾”利用难度”和”影响面”，别把所有洞都写”严重”（会失去重点），也别漏判高危。
写作原则
- 对事不对人：说”登录接口缺少速率限制”，不说”开发水平差”；
- 可复现、可验证：给足信息让开发能复现和确认修复；
- 给方案不给麻烦：每条漏洞配修复建议，最好有代码示例；
- 脱敏：截图打码、不泄露无关的用户真实数据；
- 不教犯罪：利用步骤点到为止，不提供可直接大规模滥用的完整利用程序；
- 结论清晰：明确”必须修 / 建议修 / 观察”；
- 语言分层：摘要用人话，详情用术语。
常见新手错误
- 只写”存在 SQL 注入”不写位置和修复 → 开发无法行动；
- 把扫描器原始输出直接粘贴 → 含大量误报，显得不专业；
- 风险等级全填”高危” → 失去优先级；
- 泄露客户真实敏感数据 → 违反保密；
- 没有执行摘要 → 老板看不懂，项目价值被低估。
交付后：协助修复与复测
报告不是终点。专业做法是：
- 向客户讲解报告、答疑；
- 开发修复后做复测（Retest），确认洞真堵上；
- 出复测结论，关闭问题；
- 归档，作为合规证据。
安全是持续过程，一次测试不等于永远安全。
更多实战案例：一份报告长什么样
标准渗透报告通常包含：封面与基本信息（项目名、委托方、测试时间、测试人员）、测试范围与方法（黑盒/白盒、测了哪些资产、用了什么工具）、漏洞汇总表（按风险等级排列，一眼看清轻重缓急）、每个漏洞的详情（标题、风险等级、CVSS 评分、影响、复现步骤、截图证据、修复建议）、整体风险评价与后续建议、附录（原始请求包、工具输出）。给技术看能复现，给老板看能懂业务影响，才是好报告。
更多实战案例：怎么写漏洞详情才专业
一个漏洞详情要让人”照着做就能复现”。写清：触发点（哪个 URL、哪个参数）、前提（需登录、需特定角色）、操作步骤（先访问什么、改什么参数、得到什么结果）、证据（响应截图、返回的关键字段）、影响（能读到什么、能做什么）、修复（具体代码或服务端改法，而非”请加固”）。风险等级要结合”利用难度 × 影响面”判断，不能只看技术酷不酷。
更多实战案例：风险等级怎么定
常用分级：严重（可直接拿服务器/拖库，如 RCE、SQL 注入读全库）、高危（越权、拿普通用户权限、敏感信息泄露）、中危（需一定条件，如反射型 XSS、部分信息泄露）、低危（配置瑕疵、无直接危害）、信息类（仅暴露版本等）。定级要客观，既不要为显得厉害把所有都标严重，也不要为甲方面子压低——准确才有价值。可参考 CVSS 向量打分，让定级有据可依。
常见坑
- 只给漏洞名不给复现：开发无法修复，报告失效。
- 修复建议太虚：“加强安全""完善校验”等于没说，要给具体做法。
- 风险定级情绪化：偏高偏低都误导决策。
- 缺证据截图：口说无凭，甲方难采信。
进阶：报告之外的价值
报告交付不是结束。好的安全服务会跟进修复、做回归验证、提供加固清单，并帮助建立常态化安全流程。把一次测试变成甲方安全能力的提升，才是渗透测试的真正目的。同时严守保密：测试数据和发现的风险绝不能外泄。
小测验
- 问题1：漏洞详情必须包含什么？答案：复现步骤、证据截图、影响、具体修复建议。
- 问题2：定级依据是什么？答案：利用难度 × 影响面，可参考 CVSS 向量。
- 问题3：报告交付后还应做什么？答案：跟进修复、回归验证、帮助建立安全流程。
更多实战案例：风险等级与修复优先级
交付时甲方最关心”先修哪个”。按”可利用性 × 影响”排：能直接 RCE、拖库的排第一；能越权拿普通用户权限、读敏感信息的排第二；需特定条件（如登录、特定角色）的排第三；纯配置瑕疵排最后。同时给出”临时缓解 + 根本修复”两套建议，让甲方在修代码前能先缓解风险。报告不是终点，是甲方安全建设的起点。
常见坑（终补）
- 只给漏洞名不给复现：开发无法修复，报告失效。
- 修复建议太虚：“加强安全”等于没说，要给具体做法。
- 风险定级情绪化：偏高偏低都误导决策。
- 缺证据截图：口说无凭，甲方难采信。
进阶（终补）：报告之外价值
报告交付不是结束。好的安全服务会跟进修复、做回归验证、提供加固清单，并帮助建立常态化安全流程。把一次测试变成甲方安全能力的提升，才是渗透测试真正目的。同时严守保密：测试数据和发现的风险绝不能外泄。
小测验（终补）
- 问题1：漏洞详情必须包含什么？答案：复现步骤、证据截图、影响、具体修复建议。
- 问题2：定级依据是什么？答案：利用难度 × 影响面，可参考 CVSS 向量。
- 问题3：报告交付后还应做什么？答案：跟进修复、回归验证、帮助建立安全流程。
实战要点：让报告被真正采纳
报告被采纳的关键是”可行动”。每个漏洞给：复现（照做即得）、证据（截图）、影响（业务后果）、修复（具体代码或服务配置改法）、优先级（先修哪个）。对老板用一页”风险概览+整体评价”；对开发用详细技术章节。附上回归验证计划，表明你愿意跟进。报告语气客观专业，不夸大不淡化，才能建立信任、推动修复。
易错提醒
别写”请加强安全”这种空话；别把风险全标严重（狼来了没人信）；别漏证据（口说无凭）；别在报告里写”我用工具扫出来的”（显得不专业，要说”经测试确认”）。报告是你的专业名片，质量直接决定甲方对你的信任。
自测
- 漏洞详情必须包含什么？答：复现步骤、证据截图、影响、具体修复建议。
- 定级依据是什么？答：利用难度 × 影响面，可参考 CVSS 向量。
- 报告交付后还应做什么？答：跟进修复、回归验证、帮助建立安全流程。
延伸思考：从一次测试到安全文化
一次好的渗透测试，价值不止于”找到 N 个漏洞”，更在于帮团队建立”安全左移”的文化：在需求、设计、编码阶段就考虑安全，而不是上线后救火。报告里除了漏洞，还应给出流程建议（如代码评审加安全项、上线前安全自检清单、定期红蓝对抗）。安全能力是组织能力，不是一次项目。
一句话自测
- 报告被采纳的关键？答：可行动——有复现、证据、影响、具体修复、优先级。
- 报告交付后还应做什么？答：跟进修复、回归验证、帮助建立安全流程。
这一篇你该记住的
报告是渗透价值的最终交付。结构：封面信息 → 执行摘要（给老板，业务语言）→ 范围方法 → 漏洞详情（标题/等级/CVSS/位置/原理/复现/影响/修复/证据）→ 风险汇总表 → 附录。定级兼顾利用难度与影响面。原则：对事不对人、可复现、给方案、脱敏、不教犯罪。交付后协助修复并复测。
到这篇，渗透测试从协议、信息收集、OWASP 规矩，到各类漏洞、中间件、协议攻击、流程、报告，整条链路都通了。最后还有一篇 Web 安全基础 给纯开发向的读者做个总览式入门。