I Gave Claude 12 Years of my Bug Bounty Reports - Here's What I Learned
整体摘要
作者是一名从业 12 年的资深漏洞赏金猎人（2014 年 2 月至 2025 年 11 月）。他无法诚实地凭记忆审视自己的整个职业生涯，于是把提交给 HackerOne 的全部 1500 份报告、涉及 228 个程序，全部交给 AI（Claude）分析：让 AI 对每个错误分类、列出每种结果，并明确要求"不要顾虑我的任何感受"。AI 返回了三条他最不想听到的信息：
- 他最擅长的 bug 类别，几年前就找不到了；
- 他几乎不好意思提交的漏洞，比他在会议上演讲的漏洞出现频繁得多；
- 1500 份报告中，561 份完全没有得到任何回应（重复项、不适用项、参考项全部删除后的数字）。
视频用这份数据复盘了 12 年的规律：付费率从 16% 提升到 75% 靠的不是更难的漏洞而是"筛选"；重复率 12 年几乎不降（约 1/5），因为它是"在人群聚集处狩猎的代价"；CSRF/SQL 注入等一整代漏洞已被框架修复；存储型 XSS 常盛不衰（现占 40%）但投递方式彻底改变；子域名接管以 90% 的信号率登顶而 RCE 仅勉强达平均线；核心结论是——漏洞是否被判定为漏洞，取决于它有多难被反驳，而不是有多难被发现；真正的工作单位不是单个发现，而是整个 campaign（批量活动）；评判周期应以十年而非季度计。
01
实验背景与方法论（如何用 AI 分析 1500 份报告）
00:00 - 02:26
交代 12 年生涯、数据规模（1500 份报告 / 228 个程序 / 2014.2-2025.11）、三条"最不想听到的信息"，以及完全透明的研究方法。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 00:00 | 开场 | 12 年赏金生涯，无法诚实审视自己，这次不再相信记忆 |
| 00:16 | 核心数据 | 1500 份报告、228 个程序、2014.2 - 2025.11，全部交给一台机器（AI） |
| 00:36 | 重点结论 | AI 返回三条最不想听到的信息 |
| 00:40 | 重点结论 | 其一：最擅长的 bug 类别几年前就找不到了 |
| 00:47 | 重点结论 | 其二：几乎不好意思提交的漏洞比演讲过的漏洞频繁得多 |
| 00:51 | 重点结论 | 其三：561/1500 份报告完全没有得到任何回应 |
| 01:06 | 注意事项 | 视频不提及任何公司名称（多数报告受 NDA 保密协议约束、从未公开） |
| 01:26 | 关键步骤 | 方法无魔法：从 HackerOne API 调出完整报告列表（标题、正文、日期、项目、结果） |
| 01:43 | 核心概念 | 分类器完全忽略 HackerOne 自身的弱点标签（标签由分诊人员设置，一半标签作者本人绝不会那样起名），实际读取报告内容而非标签 |
| 02:03 | 注意事项 | 近 20% 样本无法分类，被排除在总百分比之外——"宁愿告诉你真相，也不假装一切完美" |
| 02:10 | 核心概念 | Campaign（批量活动）检测：寻找标题相似的报告，4 个月内至少出现在 3 个不同项目中 |
详细内容
- 动机：回首往事总想起精彩瞬间（幸存者记忆偏差），所以这次用数据代替记忆。
- 方法论要点：
- 数据源：HackerOne API 的完整报告导出。
- 自建分类器：读取每份报告的正文内容，为每份报告分配错误类别。
- 刻意绕过平台自带的弱点标签——那些标签由各项目的分诊人员设置、每个项目命名都不同，且一半标签与报告实质不符。
- 诚实披露误差：约 20% 的样本分类器无法归类，统计时剔除。
02
从 16% 到 75% —— 六年进步的真正原因
02:26 - 04:37
对比 2014 年与 2019 年的数据，说明付费率提升 4.7 倍不是因为学会了更难的漏洞，而是三件事：停止为提交而提交、选择赚钱的漏洞类别、运行批量 campaign。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 02:30 | 背景说明 | 很多人处于"大一阶段"，第一年简直糟透了；互联网上存在一个从未经历过 2014 年的"你"，起源故事都会被磨平 |
| 02:33 | 核心数据 | 2014 年：173 份报告，仅 16% 获得报酬（约 28 份付费）——挥棒 173 次几乎什么也没打中 |
| 02:58 | 核心数据 | 2019 年：112 份报告，75% 获得报酬（约 84 份付费） |
| 03:10 | 重点结论 | 提交量减少三分之一，付费报告数量却是三倍 |
| 03:21 | 重点结论 | "我并没有因此学到更难懂的 bug"——有三件事影响了这个数字 |
| 03:24 | 关键步骤 | 其一：不再为了提交而提交。第二年信号更差、报告更少，收入却翻一番还多——终于在点击提交按钮之前完成了筛选 |
| 03:47 | 关键步骤 | 其二：开始选择真正能赚钱的漏洞类别 |
| 03:56 | 关键步骤 | 其三（最重要）：不再逐个寻找漏洞，而是运行批量 campaign |
| 04:10 | 核心概念 | "与其同时提出 20 个针对 20 个不同目标的想法，不如提出 1 个针对 20 个不同目标的想法" |
| 04:12 | 重点结论 | 花了六年才把付费比例从六分之一提高到三分之四；没人告诉你这需要数年（所有人都说自己只花了六个月——或许属实，但对大多数人并非如此） |
| 04:30 | 重点结论 | 六年里进步的不是黑客技术，而是筛选：选择把时间花在什么上面，更重要的是选择不发送什么 |
详细内容
- 2014 年的策略误区：把找到的所有东西都提交，以为"交易量（volume）才是真正的策略"。
- 三个转变按重要性递增排列，第三个（campaign 思维）是全片反复出现的主题。
- 关键句：进步 = 筛选（filtering），= 决定不发送什么。
03
重复率真相 —— 不是新手的税，是人群的代价
04:37 - 05:41
成为顶级黑客后重复率不降反升；292/1500（约 1/5）为重复，12 年几乎不变。重复是在别人也在攻击的地方狩猎的结构性代价，唯一的降压办法是去没人关注的地方——但那里也有代价。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 04:39 | 重点结论 | 数据中第一件让作者恼火的事：重复报告 |
| 04:41 | 核心数据 | 2014 年：19% 被判定为重复（新手在平台找显而易见的东西） |
| 04:53 | 核心数据 | 去年（成为 HackerOne 排行榜上最有价值的黑客之一后）重复率反而上升到 27% |
| 05:06 | 核心数据 | 全数据集：1500 份中 292 份重复；寄出的所有东西约 1/5 是别人的第一次提交，12 年几乎没变化 |
| 05:17 | 核心概念 | 如果以为重复是"新手要交的税、技术好了就不用交"，那就错了 |
| 05:22 | 重点结论 | 重复不是一时兴起，而是在其他黑客也进行类似攻击的地方狩猎的代价——大家都在同样的地方找相同类型的漏洞 |
| 05:33 | 关键步骤 | 真正降低重复率的唯一办法：去别人没关注的地方 |
| 05:38 | 注意事项 | 去往无人关注的地方也有其代价（后文展开） |
04
死去的漏洞类别 —— 框架杀死了一整代漏洞
05:41 - 07:12
CSRF、SQL 注入、独立信息泄露三类近三年计数为零（不是下降而是完全归零），它们曾占早期提交的 20%。原因是 Rails/Django/React 等框架默认内置了防御。新手找不到"2016 年就能找到的东西"不是能力问题——门在你来之前就关上了。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 05:52 | 核心数据 | 过去三年，CSRF、SQL 注入、独立信息泄露三个类别的计数为零分——不是大幅下降，是完全没有 |
| 06:01 | 核心数据 | 那三类几乎占前三年提交总数的 20%：早期每五个错误就有一个来自一个"对我来说已经不存在的类" |
| 06:14 | 核心概念 | 反射型 XSS 靠生命维持系统续命——它根本不存在了，现在几乎不再去找 |
| 06:23 | 警告/注意 | 常见误读（"很容易读懂但是错的"）：以为"他情况好转了、开始解决更棘手的漏洞" |
| 06:28 | 重点结论 | 真正的意思是：框架解决了这些问题 |
| 06:31 | 核心概念 | Rails、Django、React 等框架默认添加 CSRF 令牌、对查询参数化、输出编码 |
| 06:41 | 重点结论 | 业界在框架层修复了一整代漏洞，相关报告也就不复存在了 |
| 06:57 | 重点结论 | 如果你今天才开始、因找不到别人 2016 年就能找到的东西而沮丧，那说明你做得不错——那扇门在你来之前就已经关上了；后来有其他东西取代了它们 |
详细内容
- 这是"数据中最恼火的事情"的延伸：成就作者职业生涯的漏洞现在已经消失了。
- "最重要的趋势"引子（07:12 前的铺垫）：旧类别死亡的同时，新载体出现。
05
存储型 XSS 常盛不衰 —— 改变的是投递距离
07:12 - 08:51
存储型 XSS 现占全部提交的 40%，看似 12 年做同样的事，实际漏洞名称不变而"配送方式"完全改变：载荷投放点与着陆点之间的距离变大了。盲 XSS 从三年 1 份暴涨到一年 45 份，原因是应用变得足够大、载荷改在后台（内部支持工具等）触发。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 07:12 | 重点结论 | 整个数据集中最重要的趋势：存储型 XSS 现约占全部提交漏洞的 40% |
| 07:23 | 核心概念 | 看似 12 年做同样的事，但没有——漏洞名称保持不变，完全改变的是"配送方式" |
| 07:28 | 示例说明 | 2014 年：在评论框放载荷，下一页加载时触发（亲眼目睹）——这就是比赛 |
| 07:38 | 示例说明 | 2024 年：相同载荷放在某个随机位置，在某人的内部支持工具中触发，三天后出现在一个作者永远不会去看的屏幕上 |
| 07:48 | 关键步骤 | 之所以能做到，是因为开始追踪 XSS（盲 XSS，作者为此单独做过一期视频） |
| 08:01 | 核心数据 | 头三年盲 XSS 报告只有 1 份，而一年之内出现了 45 份 |
| 08:07 | 重点结论 | 不是因为更了解盲 XSS，而是应用程序变得足够大，载荷不再在面前触发、而是在后台的某个地方触发 |
| 08:24 | 核心概念 | 漏洞没变，变的是"载荷投放点与着陆点之间的距离变大了" |
| 08:36 | 背景说明 | 越来越多后端应用变成从未真正升级的遗留系统，在仍在线的旧框架中发现非常古老的错误不足为奇 |
详细内容
- "2014 评论框 → 2024 内部支持工具"是理解"同一漏洞、不同投递"的最佳对照。
- 遗留系统（legacy）是旧漏洞类别的残余生存空间——但作者称之为"完全是另一回事"。
06
信号频率排名 —— 反驳难度决定一切
08:51 - 11:14
按信号率（报告实际被接受/解决的频率）给漏洞类别排名，基准线 63%。子域名接管 90% 遥遥领先（重复仅 5%）；人人向往的 RCE 只有 62%、勉强达平均。RCE 失败不是因为被人抢先（重复率最低之一），而是输掉了"影响是否成立"的辩论。核心结论：判定取决于多难被反驳，而非多难被发现。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 08:46 | 转场提示 | "整段视频中最喜欢的部分，也是大多数人会反对的部分"（预示争议观点） |
| 08:54 | 核心概念 | 按信号频率对每个漏洞类别排名；各项指标的基准线是 63% |
| 09:03 | 核心数据 | 第一名遥遥领先：子域名接管，信号率 90%，重复率仅 5% |
| 09:16 | 核心数据 | RCE（远程命令/代码执行）62%——被众人视为"懒惰的侦察手段"（DNS 查询 + 注册表单）的子域名接管十次九次成功且几乎无人抢先 |
| 09:30 | 重点结论 | RCE 是人人都想写在简历上、能让你登上舞台的东西，却只勉强达到平均水平；存储型 XSS、盲 XSS、甚至无聊的反射型 XSS 都比 RCE 更有效 |
| 09:46 | 核心概念 | RCE 失败并非有人抢先——它的重复率是整个数据集中最低之一 |
| 09:51 | 核心概念 | RCE 失败的真正原因：程序对"影响"的看法存在分歧（沙箱、隔离容器、第三方、超出讨论范围） |
| 10:04 | 重点结论 | 名句："我没有输掉比赛，我输掉了辩论" |
| 10:06 | 重点结论 | 子域名接管无法辩驳：要么是你的，要么不是——没有什么真正有影响力的对话可以进行 |
| 10:14 | 核心概念 | "重复"列能告诉你信号率永远不会告诉你的信息：人群在哪里 |
| 10:19 | 示例说明 | SSRF 和开放重定向像拥挤的停车场：人人对相同参数跑相同自动化，互相竞争；而 RCE 旁边没有人 |
| 10:36 | 核心数据 | 数据集中最奇怪的线——速率限制（Rate Limit）：0% 重复、信号率 41%；别人懒得报告，多数程序也不需要 |
| 10:47 | 重点结论 | 一句话概括：权衡取舍（trade-off）。人迹罕至的地方有时空无一人，是因为那里什么也没有 |
| 10:55 | 重点结论 | 全片核心论点：漏洞是否被判定为漏洞，取决于它有多难被反驳，而不是有多难被发现 |
| 11:01 | 关键步骤 | 实操建议：本月有付费报告时，选有争议的那份；想写地球上其他人都不可能写出的报告，就反其道而行之——但一定要清楚自己在做什么（作者曾花数年做一件事却骗自己在做另一件事） |
详细内容
- 排名速览（信号率 / 重复率）：
- 子域名接管：90% / 5%
- 基准线：63%
- RCE：62% / 最低之一
- 速率限制：41% / 0%
- 存储型 XSS / 盲 XSS / 反射型 XSS：均高于 RCE
- 两类失败的区分：
- 输给速度（duplicate，人群拥挤）——SSRF、开放重定向。
- 输给辩论（影响判定分歧）——RCE。
- 拥挤停车场 vs 空旷场地的权衡：无人竞争往往意味着无人需要。
07
活动聚类与"名称"原语 —— 一个想法吃十年
11:14 - 13:35
按标题相似度聚类后发现 1500 份报告实际只是大约十几个 campaign。以"名称字段"为例展示一个原语的十年演化：2015 姓氏 XSS → 2017 任意名称对象 → 2023 产品目录传播 → 2025 商品名称注入 AI 购物助手。唯一改变的是读取字段的那一端（浏览器渲染 → 语言模型解释）。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 11:14 | 核心概念 | 改变对 1500 份报告思考方式的转折：按标题相似度聚类 |
| 11:22 | 重点结论 | 这些不是 1500 个独立发现，而是大约十几个 campaign（字幕译作"广告系列"） |
| 11:26 | 示例说明 | 最干净的例子：2017 年 2 月，3 天内向 7 家不同公司提交标题几乎相同的报告——"通过公开的项目管理实例（例如 GitHub 或 GitLab）泄露信息"；一个配置错误、一个简单技巧、三天解决 |
| 11:46 | 核心概念 | 洞见："二月并非发现之月"——几个月前已在完全不同的目标上证明了这个漏洞，二月是把它推广到所有赏金计划的"推广之月" |
| 11:55 | 关键步骤 | 每一次状态良好的拉伸都是三步形状：1) 在一个目标上找到原始漏洞；2) 识别出共享该漏洞的应用程序类别；3) 针对所掌握的所有赏金计划进行搜索 |
| 12:13 | 核心概念 | 十年屹立不倒的原始东西："名称字段"（name field） |
| 12:16 | 示例说明 | 2015 年 3 月：利用绩效考核工具中用户的姓氏进行 XSS——就是这样，某人的姓氏 |
| 12:24 | 示例说明 | 2017 年：把同样内容注入任何被视为真实对象的名称中并跟踪到任何地方；六天内针对同一游戏平台 7 起报告——平台只不过是一些有名字的对象（应用名称、软件包名称、联赛名称、剧集名称……任何可插入名称对象的内容） |
| 12:49 | 示例说明 | 2023 年：同样方法命中产品目录——包含载荷的物品名称会传播到后端仪表板，再出现在礼物消息、评论、愿望清单及任何可共享的内容中；单次注入、无法渲染上下文也无妨 |
| 13:07 | 重点结论 | 真正的飞跃：如果一个产品目录有效，那么互联网上所有以产品目录为驱动的网店也都会有它 |
| 13:13 | 示例说明 | 2025 年 6 月：通过商品名称将信息注入人工智能购物助手——同一领域、同一理念、相隔十年 |
| 13:24 | 核心概念 | 唯一改变的是另一端读取实际字段的内容：2015 年只有浏览器才能渲染它，2025 年语言模型将对其进行解释 |
| 13:34 | 核心数据 | 这个想法促成了 33 个项目中 107 份报告的解决，远高于基准线 |
| 13:40 | 重点结论 | 真正有趣的问题从来不是"你是如何发现这个漏洞的"，而是"你是如何知道其他 30 家公司也存在这个漏洞的" |
| 13:48 | 核心概念 | 理解一件事足够透彻，就不会再到处寻找漏洞，而是意识到可重复的模式（名称杀手原语、用户代理技巧、活动形成方式）——这些不该是"记住要尝试的技术"，而应是技能（skill），比如"瞄准目标然后跑动" |
详细内容
- "发现之月 vs 推广之月"是 campaign 思维的精髓：先证明一次，再横向复制。
- 名称原语演化链（建议按此复习）：
- 2015：姓氏 → 绩效考核工具 XSS
- 2017：任意"名称对象"（游戏平台的六天七报）
- 2023：产品目录物品名 → 后端仪表板 / 礼物消息 / 评论 / 愿望清单
- 2025：商品名 → AI 购物助手（payload 的消费者从浏览器变成 LLM）
08
User-Agent 探针实战 —— 一个探针、三个攻击面
13:35 - 16:57
给出完整可移植的 campaign 示例：2024 年 7-11 月，4 个月、10 个程序、11 份报告、只有一个愚蠢的根本原因——某处的旧版 Chrome 渲染了作者控制的 URL。把偶然变成方法的关键是把它当 Oracle（预言机）：任何获取你 URL 的后端都会在请求的 User-Agent 中自报浏览器版本。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 14:13 | 转场提示 | 提供一个完整的 campaign 示例——整个数据集中最具可移植性的内容，本周就可以开始运行 |
| 14:20 | 核心数据 | 2024 年 7 月到 11 月：11 份报告、10 个程序、4 个月、只有一个根本原因——而且原因很"愚蠢"：某个地方的旧版 Chrome 渲染了我实际控制的内容 |
| 14:36 | 核心概念 | 使之成为方法而不是幸运漏洞的，是 Oracle（预言机） |
| 14:38 | 关键步骤 | Oracle 原理：应用程序在任何获取你提供的 URL 的地方，都会在该请求中自报其浏览器版本（User-Agent） |
| 14:45 | 关键步骤 | 操作：把它指向你的监听器（Burp Collaborator 或 Interactsh 交互监听器，字幕译作"SH"），读取 User-Agent，再查找该版本之后发布的版本，就能确切知道对方用的是哪个版本——"这就是技巧，仅此而已" |
| 14:59 | 核心概念 | 一个探针可以接触到三个完全不同的表面（surface） |
| 15:01 | 核心概念 | Surface 1：典型的服务器端无头 Chrome（headless Chrome）。任何带后端、能获取你提供的 URL 的字段（注册时的企业网站、活动目标、产品导入等）都是注入点 |
| 15:16 | 示例说明 | 最清晰的例子是一家支付公司：创建企业账户 → 企业详情步骤 → 输入你控制的网址作为公司网站 → 后端出于检测目的渲染它 |
| 15:28 | 示例说明 | 证据：来自沙箱内部的四行 shell 输出（用户 ID、工作目录、沙箱信息） |
| 15:35 | 关键步骤 | RCE 的实现：把整个实例指向一个存在该 Chromium 版本已知漏洞的 URL——"没有用到什么奇特的装置，我只是在注册表单中输入了网址，就实现了远程代码执行" |
| 15:48 | 致谢 | 特别感谢 Alex Chapman——这项工作最理想的合作伙伴之一，在这些 campaign 中给了很多帮助 |
| 16:04 | 核心概念 | Surface 2：捆绑的桌面应用程序（Electron）。内置自己的浏览器，基本只在发现安全漏洞时才更新；它嵌入和渲染的任何东西（白板、插件浏览器、链接预览）都存在漏洞 |
| 16:28 | 重点结论 | 一半攻击活动发生在这个平台，而那里的结果不是在服务器上执行代码，而是在其他用户的机器上执行代码——导出 XSS 并把页面重定向到你的浏览器/漏洞利用程序，就可以劫持他们的机器 |
| 16:44 | 核心概念 | Surface 3：嵌入式设备浏览器——一款自带小型浏览器的电子阅读器，年代久远到存在已知 CVE |
| 16:52 | 核心数据 | 一次调查、三种服务、四个月内联系十家不同的公司 |
| 16:59 | 核心数据 | 战果：10 个项目——6 个已解决、2 个已关闭（仅供参考）、1 个已关闭（不适用，作者也不知道怎么回事） |
| 17:05 | 示例说明 | 同一天提交给另一家公司的内容完全相同的报告却被分流（triaged）处理：同一个漏洞、同一天、两个程序、结果截然相反 |
| 17:15 | 示例说明 | 另一个问题被判重复，而同一个目标 7 个月后解决了这个问题 |
详细内容
- Campaign 完整骨架（可直接复用）：
- 找到信号：旧版 Chrome 渲染受控 URL（偶然发现）。
- 提炼为 Oracle：UA 自报版本 → 指向 Collaborator/Interactsh → 精确指纹。
- 枚举三类攻击面：服务器端无头 Chrome / Electron 桌面端 / 嵌入式设备浏览器。
- 批量铺开：4 个月、10 个程序、11 份报告。
- 同一漏洞在同一天、不同程序得到完全相反的处置——这是"信号率 63% 基准线"的微观解释：结果不完全由你控制。
09
2025 年的噪音 —— 以十年为单位评判
16:57 - 18:54
2025 年纸面上断崖式下跌（48 份报告、42% 信号率、2015 年以来最差），但其中 11 份来自一次全部被"仅供参考/重复"关闭的全面检查。剔除后与前年持平。Volume 型策略有波动性：遇到漠不关心的程序，同样的方法会显示为糟糕透顶的季度。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 17:28 | 核心数据 | 从纸面看 2025 年断崖式下跌：48 份报告、42% 信号率，是 2015 年以来最糟糕的一年 |
| 17:35 | 重点结论 | 实际情况：48 份中有 11 份来自一次全面检查（秋季六周、一家重型设备制造商、整栋建筑物 11 个暴露的端点，字幕作"散热端点"） |
| 17:47 | 核心数据 | 那次活动的所有问题都以"仅供参考"或"重复"为由关闭，没有一个得到解决——其中大部分实际上是内部已知的问题 |
| 17:57 | 重点结论 | 剔除那一次 campaign，去年与前一年持平：同样的方法、同样的执行、同样的三个步骤 |
| 18:08 | 核心概念 | 唯一的变数是程序方：不需要那个 bug 类，或者内部以某种方式知道了它的存在——"这就是竞选故事的真实版本" |
| 18:19 | 核心概念 | Volume（成交量/数量型）是一种有波动性的策略，并非保证有效 |
| 18:22 | 示例说明 | 扫描功能正常时，收集 10 家公司的 11 份报告看起来非常巧妙；遇到一个漠不关心的程序，就变成 11 份报告一无所获、统计上糟糕透顶的季度 |
| 18:36 | 重点结论 | 还是你、还是同样的方法，只是换了几个星期——无法真正改变游戏规则，只能随波逐流 |
| 18:42 | 重点结论 | 必须以十年为单位、而不是以季度为单位来评判这件事 |
| 18:46 | 重点结论 | 季度大部分是噪音，而噪音在你最想放弃的时候也最大（作者无数次想过放弃） |
详细内容
- 本章是对"campaign 思维"的补丁：即使方法正确，短期统计仍会被单一冷漠程序拖垮。
- 归因清单（结果差时的三种解释）：程序不需要该 bug 类 / 程序内部已知 / 单纯波动。
10
报告篇幅之谜 —— LLM 留下的未解问题
18:54 - 19:40
报告描述中位数从 2014 年约 300 字符涨到如今超 1800（六倍），但信号强度在 2020 年达峰后下降。宽容解释是漏洞更难、需要更多论证；不宽容解释是作者开始用文字"证明发现的合理性"而非"解释发现本身"。作者承认没有答案。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 18:54 | 转场提示 | 最后一件事：这是 LLM 留给作者、至今仍没有答案的问题（字幕将 LLM 误译为"法学硕士"，据上下文应为"大语言模型"，即本视频用于分析报告的 AI） |
| 18:59 | 核心数据 | 报告篇幅增加六倍：2014 年描述中位数约 300 字符，现在已超过 1800 |
| 19:07 | 核心数据 | 信号强度逐年上升，2020 年达到峰值，之后开始下降；现在写得比以前多得多，但不意味着发表（被接受）得更多 |
| 19:17 | 核心概念 | 比较宽容的解释：后期漏洞对更成熟的程序来说更难解决，需要更多工作来解释影响 |
| 19:28 | 核心概念 | 不那么宽容的说法：写作过程中开始用文字证明发现的合理性，而不是解释发现本身 |
| 19:33 | 注意事项 | 作者真的不知道是哪一个，也不想假装已经想明白了 |
详细内容
- 这是全片唯一没有结论的开放问题：篇幅增长与信号率下降的相关性，究竟是漏洞变难还是写作变质，留给观众思考。
11
总结、金钱与新的未解之问
19:40 - 21:23
12 年的最终答案：进步的关键不在学习更难的漏洞，而在了解什么值得投入时间；工作单位是整个 campaign 而非单个发现。总收入 200 万美元，但 685 份报告一分未赚（560 份被拒 + 125 份被接受但无赏金）。金钱不等于数据——报告不记录金额，因此"90% 的子域名接管是否比 62% 的 RCE 更有利可图"成为下一个待解的数字。
关键时间节点
| 时间 | 类型 | 说明 |
|---|---|---|
| 19:40 | 转场提示 | 那么，12 年的时间究竟教会了我什么 |
| 19:43 | 重点结论 | 进步的关键不在于学习更难的漏洞，而在于了解什么才值得投入时间 |
| 19:48 | 重点结论 | 真正的工作单位不是单个发现，而是整个行动（campaign） |
| 19:52 | 重点结论 | 季度业绩不佳并不总是对方法的否定，有时只是个别波动 |
| 19:58 | 核心数据 | 12 年共获 200 万美元赏金；但 1500 份报告中有 685 份一分钱都没赚到 |
| 20:05 | 核心数据 | 细分：560 份直接被拒；125 份虽被某个项目接受但仍一分钱没拿到（其中一些是 VDP 无赏金项目，作者事先知道但仍提交了） |
| 20:22 | 重点结论 | "这部分空白永远不会出现在任何人的个人资料中"——200 万与 685 份零收入来自完全相同的过程，不能只保留一个而放弃另一个 |
| 20:35 | 核心概念 | 金钱并不等同于数据：报告记录了赏金发放日期，但从未记录金额 |
| 20:41 | 重点结论 | 因此还无法回答：成功率 90% 的子域名接管是否真的像成功率 62% 的 RCE 那样有利可图——这是从业 12 年遇到的最有趣的数字 |
| 20:52 | 关键步骤 | 下一步：正在调取支付数据来解答这个问题（想要那期视频可在评论区留言） |
| 21:00 | 收尾 | 回顾 12 年赏金经历；业内少有人能如此深入谈论这个行业；求点赞/点踩与订阅 |
详细内容
- 收入侧统计口径提示：平台档案（profile）只展示成功面；真实过程同时产出 200 万美元与 685 份零收入。
- 新的研究问题：信号率（被接受概率）不等于赏金额（收益期望），需要支付数据才能比较各类别的真实"性价比"。
整体总结
这期视频是一次罕见的"全量数据自我审计"：12 年、1500 份报告、228 个程序，全部喂给 AI 做无情感滤镜的分类与聚类。结论层层递进：
- 技术层：一整代漏洞（CSRF、SQLi、反射型 XSS、独立信息泄露）被框架默认防御杀死；存储型 XSS 以 40% 的占比存活，但投递方式从"眼前触发"变成"后台远距离着陆"，于是盲 XSS / 追踪技术成为新钱。
- 策略层：付费率 16% → 75% 的六年进步来自筛选（不提交什么）+ 赚钱类别选择 + campaign 化批量复制（1 个想法 x 20 个目标）。重复率（约 1/5、12 年不降）是人群聚集处的结构性代价，不是新手的税。
- 评判层：信号率排行颠覆直觉——子域名接管 90% 登顶、RCE 62% 垫底于均值；决定判定的是"多难被反驳"而非"多难被发现"。RCE 输在辩论（沙箱/范围/影响分歧），SSRF/开放重定向输在拥挤。
- 心态层：volume 型策略有波动性，季度统计大部分是噪音，且噪音在最想放弃的时候最大；应以十年为单位评判方法。
- 方法论金句：真正有趣的问题不是"你如何发现这个漏洞"，而是"你如何知道其他 30 家公司也存在这个漏洞"；工作单位是整个行动而非单个发现。