报告写作更新 2026-11-08
SRC 漏洞报告模板
一份能被收录的报告，核心不是截图数量，而是「链路可复现 + 伤害可判定 + 证据可核验」。这里是模块与写法。
平台驳回最多的不是「洞太小」，而是「看不出伤害」。模板按审核视角组织：先给结论，再给链路，最后给证据与修复。
| 模块 | 写什么 | 为什么这么写 | 常见扣分点 |
|---|---|---|---|
| 标题 | 「资产 + 位置 + 类型 + 后果」，一句话说清。 | 审核第一眼判断是否值得看；标题含糊会被直接降级。 | 不要写「疑似」「可能」，没验证就不要提交。 |
| 影响范围 | 受影响角色、数据范围、是否需要登录、是否可批量。 | 决定定级；同一漏洞对游客与管理员的价值完全不同。 | 只写「影响所有用户」却不给依据，是最常见的夸大。 |
| 危害说明 | 用可验证的业务后果描述，例如「可读取某表的凭据字段，进而接管后台」。 | 把技术现象翻译成业务伤害，审核才判得动。 | 拿示例数据当真实拖库证据，会被要求补充或直接驳回。 |
| 复现步骤 | 编号步骤：入口 → 请求 → 参数 → 响应差异；关键请求附原始报文（脱敏）。 | 可复核是收录的前提；步骤缺一环就无法判定。 | 只放结果截图不放请求报文，等于让别人猜。 |
| 证据 | 请求/响应、时间戳、账号角色、数据样本（脱敏），必要时附视频。 | 证据链要能独立成立，不能依赖口头描述。 | 截图打码过度导致无法核验，也会被退回。 |
| 修复建议 | 给到具体落点：参数化查询、权限校验位置、配置项名称。 | 体现你不是只发现问题，还理解业务实现。 | 写「加强安全意识」这类空话没有价值。 |
标题
- 写什么
- 「资产 + 位置 + 类型 + 后果」，一句话说清。
- 为什么这么写
- 审核第一眼判断是否值得看；标题含糊会被直接降级。
- 常见扣分点
- 不要写「疑似」「可能」，没验证就不要提交。
影响范围
- 写什么
- 受影响角色、数据范围、是否需要登录、是否可批量。
- 为什么这么写
- 决定定级；同一漏洞对游客与管理员的价值完全不同。
- 常见扣分点
- 只写「影响所有用户」却不给依据，是最常见的夸大。
危害说明
- 写什么
- 用可验证的业务后果描述，例如「可读取某表的凭据字段，进而接管后台」。
- 为什么这么写
- 把技术现象翻译成业务伤害，审核才判得动。
- 常见扣分点
- 拿示例数据当真实拖库证据，会被要求补充或直接驳回。
复现步骤
- 写什么
- 编号步骤：入口 → 请求 → 参数 → 响应差异；关键请求附原始报文（脱敏）。
- 为什么这么写
- 可复核是收录的前提；步骤缺一环就无法判定。
- 常见扣分点
- 只放结果截图不放请求报文，等于让别人猜。
证据
- 写什么
- 请求/响应、时间戳、账号角色、数据样本（脱敏），必要时附视频。
- 为什么这么写
- 证据链要能独立成立，不能依赖口头描述。
- 常见扣分点
- 截图打码过度导致无法核验，也会被退回。
修复建议
- 写什么
- 给到具体落点：参数化查询、权限校验位置、配置项名称。
- 为什么这么写
- 体现你不是只发现问题，还理解业务实现。
- 常见扣分点
- 写「加强安全意识」这类空话没有价值。
红线与边界
- ·模板中的示例均为脱敏占位，不针对任何真实站点。
- ·未授权测试他人资产属于违法行为；本模板只适用于 SRC 授权范围与自有资产。
继续往下读