关于 bug-bounty-report-writing
为漏洞赏金研究人员提供报告撰写指南，帮助将发现整理为便于审核的证据化报告。内容涵盖结构、影响论证、隐私保护和提交后的沟通。
主要功能
- 01规范漏洞报告结构
- 02撰写可复现步骤
- 03以证据论证实际影响
- 04保护证据中的个人数据
- 05处理提交后的审核沟通
适用场景
- 01整理漏洞发现并提交
- 02准备可复制的复现流程
- 03评估漏洞影响与严重性
- 04回应审核人员的追问
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/bug-bounty-report-writing确认已加载。
详细介绍
漏洞赏金报告撰写
将发现整理成报告，帮助分拣人员快速受理并公平评级。
报告结构
- 标题 — 漏洞类别 + 受影响资产。
Stored XSS in ticket comment field on support.example.com - 严重性和 CVSS — 建议评级及向量字符串
- 摘要 — 用 2–3 句话说明问题、位置和影响
- 复现步骤 — 编号列出，可直接复制粘贴，不作任何假设
- 影响 — 具体说明攻击者能获得什么
- 佐证材料 — HTTP 请求/响应、已遮盖敏感数据的屏幕截图
- 修复建议 — 具体的修复方案
规则
- 每份报告只包含一个漏洞。仅当攻击链中的每个步骤单独都毫无意义时，才将整条攻击链放在一份报告中。
- 必须证明或严谨论证影响，不得臆测。没有攻击路径却声称“可能导致 RCE”，会被下调评级。
- 证据中的个人数据必须遮盖。模糊处理用户 PII；绝不要包含你访问到的其他用户数据——报告该访问问题，并删除数据。
- 粘贴的日志不得包含会破坏 Markdown 格式的内容；请使用围栏代码块。
- 撰写时要考虑到分拣人员是第一次看到该资产。
应避免导致评级下调的常见原因
- 将自我型 XSS 或需要受害者安装软件的 XSS 报告为高危
- 缺少
Content-Security-Policy或响应头过于详细，但未证明存在可利用漏洞 - 声称存在理论上的 IDOR，却未展示两个不同账户受到影响
- 未经人工验证就直接粘贴自动扫描器的输出
提交后
- 在项目规定的 SLA 内回复分拣人员的问题
- 只有在获得实质性新信息后才请求重新审核
- 在项目的披露政策允许之前，不得公开披露
评论
支持 Markdown