安全报告怎么写才专业：渗透测试报告模板与踩坑

文章目录

- 一、报告写不好，技术白做
- 二、报告类型先分清
- 三、专业报告的标准结构（目录模板）
- 四、可直接套用的完整模板
- - 【封面】
  - [【1. 文档说明】](#【1. 文档说明】)
  - [【2. 执行摘要】（最重要的一页）](#【2. 执行摘要】（最重要的一页）)
  - [【3. 测试概述】](#【3. 测试概述】)
  - [【4. 风险统计】](#【4. 风险统计】)
  - [【5. 漏洞详情】（核心章节）](#【5. 漏洞详情】（核心章节）)
  - [【7. 通用安全建议】](#【7. 通用安全建议】)
  - [【8. 附录】](#【8. 附录】)
- [五、写好一条漏洞的「5 要素」](#五、写好一条漏洞的「5 要素」)
- 六、截图与证据规范
- 七、严重等级排序与合并原则
- - [7.1 排序](#7.1 排序)
  - [7.2 何时合并为「一条」](#7.2 何时合并为「一条」)
  - [7.3 何时拆成多条](#7.3 何时拆成多条)
- [八、15 个常见踩坑清单](#八、15 个常见踩坑清单)
- 九、甲方视角：什么样的报告算「专业」？
- [十、渗透报告 vs 其他报告（差异速查）](#十、渗透报告 vs 其他报告（差异速查）)
- 十一、报告交付与复测闭环
- 十二、推荐工具与协作平台
- 十三、动手练习
- 十四、本篇小结
- [附录 A：执行摘要一页纸模板（Word 可复制）](#附录 A：执行摘要一页纸模板（Word 可复制）)
- [附录 B：漏洞工单 JSON 字段（对接 Jira）](#附录 B：漏洞工单 JSON 字段（对接 Jira）)

一、报告写不好，技术白做

很多渗透工程师技术不差，报告却被吐槽：

text 复制代码

「全是截图，看不懂业务影响」  ------ 管理层
「复现步骤不清楚，我们没法修」 ------ 开发
「没有风险等级，不知道先改哪个」------ 运维
「这能当等保/审计材料吗？」    ------ 合规

专业安全报告要同时满足四类读者：

读者	关心什么	报告里对应什么
管理层	风险多大、要不要投钱	执行摘要、风险统计
技术负责人	攻击路径、影响范围	测试方法、漏洞详情
开发/运维	怎么复现、怎么改	复现步骤、修复建议
合规/审计	授权、范围、可追溯	声明、时间线、证据链

一句话标准 ：让不读技术细节的人敢拍板 ，让不看摘要的人能修好漏洞。

二、报告类型先分清

类型	目的	篇幅	典型交付周期
漏洞扫描报告	自动化扫描结果汇总	短～中	1～3 天
渗透测试报告	人工深度测试 + 利用链	中～长	1～4 周
红队评估报告	检测响应能力、TTP 时间线	长	数周～数月
应急响应报告	事件经过、根因、处置	中	事件后 72h～7 天
复测/验证报告	确认漏洞是否修复	短	修复后 1～3 天

本文以 渗透测试报告 为主模板，其他类型在文末附差异说明。

三、专业报告的标准结构（目录模板）

text 复制代码

封面
修订记录
目录

1. 文档说明（范围、授权、免责）
2. 执行摘要（Executive Summary）        ← 管理层只看这章也行
3. 测试概述（目标、方法、工具、时间线）
4. 风险统计与结论（图表 + 优先级）
5. 漏洞详情（按严重等级排序）            ← 开发主要看这章
6. 攻击路径与 Kill Chain 复盘（可选，红队向）
7. 通用安全建议（基线、流程、培训）
8. 附录（工具列表、术语、原始数据索引）

附件（可选）：脱敏截图包、PoC 脚本、PCAP 哈希

页数参考 ：中小项目 15～30 页 （不含附录）；大型红队 50 页+。

四、可直接套用的完整模板

以下 Markdown 结构可复制到 Word / Typora / 报告平台（如 Dradis、Ghostwriter）使用。

【封面】

markdown 复制代码

# XX 公司 XX 系统渗透测试报告

| 项目 | 内容 |
|------|------|
| 委托单位 | XXX 有限公司 |
| 测试单位 | XXX 安全团队 |
| 报告版本 | V1.0 |
| 报告日期 | 2026-XX-XX |
| 密级 | 内部资料 · 严禁外传 |
| 测试类型 | 黑盒 / 灰盒 / 白盒 |

【1. 文档说明】

markdown 复制代码

## 1.1 测试目的
在授权范围内，评估 XX 系统面临的安全风险，发现漏洞并给出修复建议，
为安全加固与合规整改提供依据。

## 1.2 测试范围

| 类型 | 范围 | 不在范围 |
|------|------|----------|
| IP/域名 | 1.2.3.4, api.xxx.com | 第三方 CDN |
| 应用 | 订单系统 v2.3 | 移动端 App |
| 账号 | 测试账号 test01 | 生产管理员账号 |

## 1.3 授权说明
测试已于 2026-XX-XX 取得书面授权（授权书编号：XXX），
测试时间：2026-XX-XX 至 2026-XX-XX，工作日 9:00-18:00。

## 1.4 风险披露与免责
· 测试在约定范围内进行，未授权测试属于违法行为。
· 报告含敏感信息，仅供委托方内部使用。
· 复现步骤仅供修复验证，禁止用于未授权环境。

## 1.5 术语与等级
漏洞等级采用 CVSS 3.1 Base Score：
Critical 9.0-10.0 | High 7.0-8.9 | Medium 4.0-6.9 | Low 0.1-3.9

踩坑：不写授权范围 → 法律风险；范围模糊 → 甲方扯皮「你没测全」。

【2. 执行摘要】（最重要的一页）

markdown 复制代码

## 2.1 总体结论
本次对 XX 系统开展渗透测试，共发现 **有效漏洞 12 个**，
其中 **Critical 1、High 3、Medium 5、Low 3**。
存在 **1 条可从未授权外网获取数据库敏感信息** 的路径，
建议在 **72 小时内** 完成 Critical 漏洞修复。

## 2.2 关键发现（Top 3）

| # | 漏洞 | 等级 | 业务影响（一句话） |
|---|------|------|------------------|
| 1 | 订单 API SQL 注入 | Critical 9.8 | 可拖取 12 万用户订单与手机号 |
| 2 | 管理后台弱口令 | High 8.1 | 可登录后台上传 Webshell |
| 3 | Redis 未授权访问 | High 9.4 | 内网可写 SSH key 拿下服务器 |

## 2.3 攻击路径概览（给管理层看的图）

外网 SQL 注入 → 数据库 PII 泄露（无需账号）
弱口令后台 → 文件上传 → 服务器权限（需内网横向）

## 2.4 修复优先级建议

P0（72h）：VULN-001 SQL 注入
P1（7 天）：VULN-002、VULN-003
P2（30 天）：Medium 批量修复

## 2.5 积极方面（可选，体现客观）
· 核心支付接口已启用 WAF，常规扫描 payload 被拦截
· 生产数据库未对公网暴露

踩坑：摘要写满技术术语 → 老板看不懂；只写坏消息 → 像恐吓，加 1～2 条正面观察更可信。

【3. 测试概述】

markdown 复制代码

## 3.1 测试方法
参照 PTES、OWASP Testing Guide，结合 CVSS 3.1 评级。

| 阶段 | 活动 | 主要工具 |
|------|------|----------|
| 信息收集 | 子域、端口、指纹 | subfinder, nmap, httpx |
| 漏洞发现 | 手工 + 自动化 | Burp, nuclei, sqlmap |
| 漏洞利用 | 授权范围内验证 | 手工, Metasploit |
| 后渗透 | 横向/提权（范围内） | netexec, BloodHound |
| 报告编制 | 整理证据与建议 | --- |

## 3.2 测试账号与环境

| 项目 | 说明 |
|------|------|
| 测试环境 | 预发布 / 生产（注明） |
| 测试账号 | test_pentest / 普通用户权限 |
| 网络位置 | 互联网 / 办公网 VPN |

## 3.3 测试时间线

| 日期 | 活动 |
|------|------|
| D1 | 信息收集、端口扫描 |
| D2-D3 | Web 手工测试、越权 |
| D4 | 漏洞利用与影响验证 |
| D5 | 报告编写与内部 QA |

【4. 风险统计】

markdown 复制代码

## 4.1 漏洞数量分布

[此处插入饼图/柱状图：按 Critical/High/Medium/Low]

## 4.2 漏洞类型分布

| 类型 | 数量 | 占比 |
|------|------|------|
| 注入类 | 3 | 25% |
| 认证/会话 | 2 | 17% |
| 访问控制 | 4 | 33% |
| 配置错误 | 3 | 25% |

## 4.3 与行业基准对比（可选）
OWASP 常见 Web 漏洞中，本次越权占比偏高，建议加强 API 鉴权评审。

【5. 漏洞详情】（核心章节）

每条漏洞用统一模板，便于开发工单系统导入。

漏洞条目模板（复制即用）

markdown 复制代码

---
### VULN-001：订单查询接口 SQL 注入

| 属性 | 内容 |
|------|------|
| 严重等级 | **Critical（9.8）** |
| CVSS 3.1 向量 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L |
| CWE | CWE-89 SQL Injection |
| 受影响 URL | https://api.xxx.com/v1/order?id= |
| 发现日期 | 2026-XX-XX |
| 状态 | 未修复 |

#### 漏洞描述
订单查询接口 `id` 参数未过滤直接拼接 SQL，攻击者可构造恶意参数
读取数据库任意表数据。

#### 业务影响
· 可导出用户订单、手机号、收货地址（约 12 万条）
· 违反《个人信息保护法》数据处理安全要求
· 可能导致监管通报与声誉损失

#### 复现步骤
1. 使用 Burp 代理浏览器访问 `https://api.xxx.com/v1/order?id=1001`
2. 将 `id` 参数改为：`1001 AND 1=1` → 正常返回
3. 改为：`1001 AND 1=2` → 空结果，确认存在注入点
4. 使用 sqlmap 验证（授权环境）：
   ```bash
   sqlmap -u "https://api.xxx.com/v1/order?id=1001" --batch --dbs

可列出数据库名 order_db，表 users、orders

【截图 1：Burp 请求响应对比】

【截图 2：sqlmap 拖库证明（数据打码）】

攻击路径（可选）

外网匿名用户 → SQL 注入 → MySQL 读权限 → PII 泄露

（Kill Chain：投递/利用 → 达成目标）

修复建议

优先级	措施
立即	参数化查询 / Prepared Statement，禁止拼接 SQL
短期	WAF 增加 SQLi 规则；错误信息不返回 SQL 详情
长期	代码审计同类接口；CI 集成 SAST

修复验证方法

使用相同 payload 应返回 400 或参数化后的正常错误，sqlmap 无法注入。

修复后申请复测。

参考链接

· https://owasp.org/www-community/attacks/SQL_Injection

· CWE-89: https://cwe.mitre.org/data/definitions/89.html

复制代码

**编号规则建议**：`VULN-001` 固定递增；严重等级内按分数降序排列。

---

### 【6. 攻击路径复盘】（渗透/红队向，可选）

```markdown
## 6.1 攻击链时间线

| 时间 | 阶段 | 行为 | 是否被检测 |
|------|------|------|------------|
| T+0h | 侦察 | 子域枚举发现 api.xxx.com | 未知 |
| T+2h | 利用 | SQL 注入验证成功 | 否 |
| T+4h | 达成目标 | 导出脱敏样本 10 条 | 否 |

## 6.2 检测响应 Gap（紫队向）
· 无 SQL 异常查询告警
· WAF 未覆盖 `id` 参数 JSON 接口
建议：补充 SIEM 规则 + API 网关日志。

【7. 通用安全建议】

markdown 复制代码

## 7.1 技术层面
· 所有对外 API 强制鉴权与参数校验
· 生产环境禁止调试模式与详细错误栈
· 内网 Redis/MySQL 禁止 0.0.0.0 监听

## 7.2 管理层面
· 建立漏洞修复 SLA（Critical 72h）
· 重大发布前强制安全测试
· 开发人员 OWASP Top 10 培训（每季度）

## 7.3 合规层面
· 补齐个人信息影响评估（如涉及 PII）
· 保留本次测试与修复记录备查

【8. 附录】

markdown 复制代码

## 附录 A：工具与版本
nmap 7.94 · Burp Suite Pro 2024.x · sqlmap 1.8 · nuclei 3.x

## 附录 B：漏洞完整清单

| ID | 标题 | 等级 | CVSS | 状态 |
|----|------|------|------|------|
| VULN-001 | SQL 注入 | Critical | 9.8 | 开放 |
| VULN-002 | 弱口令 | High | 8.1 | 开放 |
| ... | ... | ... | ... | ... |

## 附录 C：复测说明
修复完成后，委托方联系测试方安排复测，复测范围以本报告漏洞清单为准。

五、写好一条漏洞的「5 要素」

开发最常问的五件事，每条漏洞必须能回答：

text 复制代码

1. 在哪？     → URL / 组件 / 版本
2. 多严重？   → CVSS + 业务影响（人话）
3. 怎么复现？ → 步骤 + 截图 + 命令（可复制）
4. 怎么修？   → 立即 / 短期 / 长期，具体到代码层
5. 怎么验？   → 修完后如何确认关闭

缺任何一项，工单就会被打回。

六、截图与证据规范

规范	说明
打码	手机号、身份证、真实密码、Token 必须马赛克
标注	红框标注入点、关键响应字段
完整	含请求方法、URL、状态码、关键 Header
对比	正常 vs 异常各一张，比单张更有说服力
哈希	大文件、PCAP 附 SHA256，报告只写哈希
禁止	全库导出截图、未脱敏 PII、生产管理员明文密码

踩坑：100 张无标注截图堆砌 → 像日志 dump，不像专业报告。

七、严重等级排序与合并原则

7.1 排序

text 复制代码

1. 按 CVSS Base 降序
2. 同分按业务影响：PII > 资金 > 可用性
3. 同分按利用难度：无需认证优先

7.2 何时合并为「一条」

情况	处理
同一根因导致 10 个 URL SQLi	合并 1 条 + 附录列受影响 URL 列表
信息性发现（版本泄露）	可合并为「信息泄露」汇总条
漏洞链 A→B→C	写一条「攻击链」，子步骤标 VULN-001a/b/c

7.3 何时拆成多条

情况	处理
不同 CWE 类型	分开（SQLi vs XSS）
不同组件（Web vs 移动端）	分开
修复负责人不同	分开便于派单

八、15 个常见踩坑清单

#	踩坑	后果	正解
1	无授权书仍写「全面测试」	法律风险	授权范围写进 1.2/1.3
2	只有漏洞列表无摘要	管理层不买单	必有执行摘要
3	CVSS 只写分数无向量	不可审计	写完整 CVSS:3.1/...
4	复现步骤跳步	开发复现不了	逐步到「复制粘贴级」
5	修复建议「加强安全意识」	无法落地	写到代码/配置/规则
6	把扫描器原文粘贴	误报一堆	人工验证后再写入
7	逻辑漏洞不写业务场景	被标 Low 忽视	补充「可转帐/越权删户」
8	测试生产未告知	业务事故	文档注明环境，破坏性操作禁止
9	泄露第三方系统	合同纠纷	严格按 IP/域名范围
10	无版本修订记录	复测对不上号	V1.0/V1.1 修订表
11	英文工具截图无说明	甲方看不懂	关键步骤中文标注
12	无正面观察	像恐吓营销	摘要提 1～2 条已有防护
13	Critical 过多	可信度下降	严格按 CVSS，逻辑漏洞单独论证
14	无复测章节	修完无闭环	附录写复测流程
15	报告发微信群	泄密	加密 PDF + 指定接收人

九、甲方视角：什么样的报告算「专业」？

做过安全负责人的人通常用这张 mental checklist：

text 复制代码

□ 5 分钟内能看懂最大风险
□ 漏洞能直接转成 Jira/禅道 ticket
□ 修复建议不是空话
□ 有授权、范围、时间，审计能过
□ 数据已脱敏，敢给领导看
□ 严重等级有依据（CVSS 向量）
□ 愿意让你来复测（闭环）

乙方口碑往往靠报告质量，不靠漏洞数量吓唬客户。

十、渗透报告 vs 其他报告（差异速查）

章节	渗透测试	漏洞扫描	红队评估	应急响应
执行摘要	✅ 必填	✅	✅ 偏检测 gap	✅ 偏时间线
漏洞详情	✅ 核心	✅ 列表为主	⚠️ 可选	❌
攻击路径	可选	❌	✅ 核心	✅ 核心
MTTD/检测率	❌	❌	✅	✅
工具误报说明	短	✅ 重要	短	❌
根因分析 5 Why	可选	❌	可选	✅

十一、报告交付与复测闭环

text 复制代码

初测报告 V1.0 交付
    ↓
甲方派单修复（按 P0/P1/P2）
    ↓
开发提交修复说明 + 自测记录
    ↓
复测（建议限定漏洞清单范围，非全量重测）
    ↓
复测报告 V1.1：已关闭 / 未关闭 / 引入新问题
    ↓
全部 Critical/High 关闭 → 项目结项

复测条目模板（简版）：

markdown 复制代码

| ID | 初测等级 | 复测结果 | 说明 |
|----|----------|----------|------|
| VULN-001 | Critical | ✅ 已修复 | 参数化查询已上线，sqlmap 失败 |
| VULN-002 | High | ❌ 未修复 | 仍可弱口令登录 admin/123456 |
| VULN-003 | High | ⚠️ 部分修复 | 上传限制扩展名，仍可双写绕过 |

十二、推荐工具与协作平台

工具	用途
Dradis	多人协作写报告、导 Word
Ghostwriter	红队项目与报告管理
SysReptor	现代渗透报告生成
Notion / 语雀	中小团队模板库
Jira / 禅道	漏洞 ticket 同步

个人练习：用 Markdown 写满 3 条漏洞 + 1 份执行摘要，即达入门交付水平。

十三、动手练习

在自有靶场（DVWA / Juice Shop）完成一份 迷你报告：

text 复制代码

要求：
1. 封面 + 授权说明（写「本地靶场」）
2. 执行摘要：≤ 1 页，含 Top 2 发现
3. 至少 2 条完整漏洞（用第五节模板）
4. 每条含 CVSS 向量 + 截图 + 修复建议
5. 附录漏洞清单表

自评：能否把 VULN-001 直接发给朋友复现？能则合格。

十四、本篇小结

text 复制代码

┌─────────────────────────────────────────────────────────────┐
│  专业报告核心记忆                                            │
├─────────────────────────────────────────────────────────────┤
│  结构：说明 → 摘要 → 方法 → 统计 → 漏洞详情 → 建议 → 附录    │
│  摘要给老板看，详情给开发改，授权给合规看                     │
│  每条漏洞：5 要素（在哪/多严重/复现/修复/验证）              │
│  CVSS 写向量，截图要脱敏，修复要可执行                        │
│  初测 + 复测 = 闭环，报告质量决定专业口碑                     │
└─────────────────────────────────────────────────────────────┘

下一篇预告：《网络安全职业规划：从入门到高级安全工程师的路径图》------会写报告之后，下一步往哪走。

附录 A：执行摘要一页纸模板（Word 可复制）

markdown 复制代码

# 执行摘要

**项目名称**：__________  
**测试时间**：__________  
**总体风险**：□ 高 □ 中 □ 低  

**漏洞统计**：Critical __ / High __ / Medium __ / Low __

**最严重问题（一句话）**：
_________________________________________________

**建议 72 小时内完成**：
1. __________  2. __________

**签字确认**（可选）：
测试方：__________  客户方：__________  日期：__________

附录 B：漏洞工单 JSON 字段（对接 Jira）

json 复制代码

{
  "id": "VULN-001",
  "title": "订单 API SQL 注入",
  "severity": "Critical",
  "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L",
  "cvss_score": 9.8,
  "cwe": "CWE-89",
  "affected_url": "https://api.example.com/v1/order",
  "status": "open",
  "remediation_sla": "72h"
}