前言#
個人經驗來看，滲透測試報告分兩類，一類是簡單的報告，簡要彙總漏洞內容，這種報告都是技術性東西，不適合領導看，一類是複雜且正式的報告，可用來做項目彙總及驗收蓋章用的報告。
之前看到這篇文章，寫了如何編寫高質量報告規範，針對國外的滲透測試報告，總結了下內容，附件中還有其他的報告有很多，可以去借鑒借鑒。
簡單報告#
| 名稱 | 描述 |
|---|---|
| 摘要 | 漏洞介紹，提供對問題及其範圍的簡要描述 |
| 影響 | 漏洞危害 |
| 複現步驟 | 複現流程，包括屏幕截圖、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
其他的一些報告參考：更多滲透測試報告