安全报告（Security Report）

适用场景

• 安全评审总结报告
• 漏洞汇总报告
• 合规审计报告
• 修复跟踪报告

核心原则

1. 报告给决策者看
   首页有结论 + 风险等级

2. 每个漏洞有修复建议
   不只报问题

3. 风险分级（CVSS）
   Critical / High / Medium / Low

4. 修复必须验证
   修了不等于修好了

5. 不泄露报告
   安全报告本身是敏感信息

报告结构

# 安全评审报告

## 摘要
- 评审范围：[系统/模块]
- 评审日期：
- 发现总数：X 个
- 风险分布：Critical X / High X / Medium X / Low X
- 结论：[可上线 / 需修复后上线 / 不可上线]

## 发现汇总
| # | 标题 | 严重度 | 状态 | 修复人 |
|---|------|--------|------|--------|
| 1 | IDOR 越权 | High | 已修复 | Dev |
| 2 | XSS 反射 | Medium | 待修复 | Dev |

## 详细发现
[每个漏洞用 vulnerability-report-template]

## 修复跟踪
| # | 漏洞 | 修复方案 | 截止 | 验证 |
|---|------|---------|------|------|
| 1 | IDOR | 加资源归属校验 | 本周 | ✅ |

## 建议
1. [系统级建议]
2. [流程级建议]

CVSS 评分速查

分数	等级	含义
9.0~10.0	Critical	远程无认证利用 / 数据丢失
7.0~8.9	High	认证后利用 / 部分数据
4.0~6.9	Medium	需特定条件
0.1~3.9	Low	信息泄露 / 边缘

配套模板

• templates/security-report-template.md — 完整安全报告模板

质量自检

□ 摘要有结论
□ 风险分级（CVSS）
□ 每个发现有复现步骤
□ 每个发现有修复建议
□ 修复已验证
□ 报告不泄露
□ 给 PM 可读版本

常见坑

1. 只列漏洞不给结论——决策者不知道能不能上线
2. 不分级——所有漏洞看起来一样严重
3. 不验证修复——以为修了实际没修
4. 报告太技术——PM 看不懂
5. 报告泄露——二次风险

与其他 skill 的协作

上游：
  所有其他 security skills → 发现汇总

下游：
  project-manager → 风险决策
  backend/frontend → 修复
  technical-writer → 安全文档