前言#
个人经验来看，渗透测试报告分两类，一类是简单的报告，简要汇总漏洞内容，这种报告都是技术性东西，不适合领导看，一类是复杂且正式的报告，可用来做项目汇总及验收盖章用的报告。
之前看到这篇文章，写了如何编写高质量报告规范，针对国外的渗透测试报告，总结了下内容，附件中还有其他的报告有很多，可以去借鉴借鉴。
简单报告#
| 名称 | 描述 |
|---|---|
| 摘要 | 漏洞介绍，提供对问题及其范围的简要描述 |
| 影响 | 漏洞危害 |
| 复现步骤 | 复现流程，包括屏幕截图、http 请求、poc 或 exp 等 |
| 建议 | 修复建议 |
| 参考资料 | 一般不加 |
漏洞评分及漏洞危害等级一般体现危害等级，分别识信息、低、中、高等。
正式报告#
这篇报告根据securitum-protonmail-security-audit进行总结，比较接地气一点，附件的链接还有很多，有兴趣可以看看
一、总结（工作、渗透）
- 测试范围
- 测试方法（OWASP TOP10、OWASP ASVS）
- 发现的漏洞
在测试过程中，特别强调可能对处理的数据的机密性、完整性或可用性产生负面影响的漏洞。
作为测试的一部分，使用基于手动测试的方法（使用上述方法论）并辅以多种自动化工具进行了测试，其中包括 Burp Suite Professional、DirBuster、ffuf、nmap、Visual Studio Code、semgrep、grep 和 sonarqube。
漏洞在报告的后续部分中详细描述。
== 漏洞风险等级：==
漏洞按照五级评分进行分类，反映了漏洞被利用的概率和其利用所带来的业务风险。以下是每个严重程度级别的简要描述含义。
- 严重
- 高危
- 中危
- 低危
- 信息
漏洞统计：
图形化展示
二、版本修改记录
- 时间
- 版本
- 修改描述
三、漏洞复现过程记录
- 漏洞名称
- 漏洞描述
- 攻击的先决条件
- 技术详情（POC）
- 漏洞位置
- 修复建议
学习到的内容
在写报告的时候，建议使用被动语态，而不使用第一人称。
当你写修复建议的时候，一般可以以建议开头，而不是说有那种强制性按此方法去修复漏洞。
国外的报告和我们的报告一比较，有一个地方不同的是，最终总结的位置不同，国外的喜欢把总结放在开头，我们喜欢放在结尾，有些时候也会放在开头去总结。
在漏洞复现处，国外的很详细，信息类的漏洞也会写出来，漏洞修复建议贴近系统，而不是通用的解决建议。
以攻击者和受害者的角度去复现漏洞场景，别人一眼就可以看懂，相比国内的那些漏洞通报，图都不给你，只给文字和链接说明，要看懂这个漏洞没点功底真的会看不懂。
国外的还会对漏洞进行编号，感觉是按项目名称来编号的，这样可以明确的区分这些漏洞。
编写报告其实没太多技术活，但你要让别人看得懂，写出一份质量高的报告比较难，笔者有过这种经历，一份报告根据客户的意见改了 5-6 遍才满意，报告本身也是流程性的，只要弄出模板根据模板改其他人改就行。有些则是提交 src 的报告，这种报告简单报告就行。
参考：best-practices-for-writing-quality-vulnerability-reports
其他的一些报告参考：更多渗透测试报告