漏洞赏金计划如何提升一位研究人员的网络安全技能

GitHub 于 2026 年 10 月 22 日发布了对漏洞赏金 researcher @r31n 的访谈。他多次研究 GitHub Enterprise Server，提交的报告包含可运行的概念验证（PoC）和清晰复现步骤。AI 正在改变漏洞研究的起点、速度与工作方式，但发现真实安全影响的门槛并未降低。

AI 加速研究，却没有取代验证

@r31n 表示，AI 对其工作的影响超过任何一种安全工具。他会用 AI 熟悉陌生代码、查找调用位置、追踪数据流、理解组件关系，并在确认漏洞后辅助编写 PoC 脚本。不过，AI 的效果取决于提问质量：提供已知上下文并提出具体、狭窄的问题，比笼统询问“是否存在漏洞”更有效。

他的工作方式仍以人工调查为主，辅以小型、专用的脚本；只有重复出现的步骤才会被自动化。工具可以帮助回答特定问题，却也可能把研究者的视线限制在预设模式中。相比之下，对系统机制的好奇心、持续追问和验证能力更经得起技术变化。

从固定漏洞类型转向完整攻击路径

研究方法也在发生变化。@r31n 会先绘制应用结构，关注复杂功能、集成关系、信任边界以及行为异常的部分，再从“数据从哪里进入”和“最终触发了什么敏感操作”出发追踪路径。他关注的不是某个孤立缺陷，而是多个看似轻微的问题能否组合成更严重的攻击链。

例如，单独的开放重定向影响可能有限，但如果系统中的 SSRF 会跟随重定向，且请求目标限定在允许列表域名内，两者组合后便可能成为更大攻击链的一部分。发现这种连接，既需要技术理解，也需要跳出单个漏洞类别的创造力。

适用场景集中在导航、追踪与 PoC 编写

AI 更适合承担辅助性工作，包括：

理解陌生代码库的组件结构和调用关系；
沿着具体变量追踪数据流与信任边界；
在已经理解漏洞原理后生成或整理 PoC；
比较不同角色、权限和交互流程的差异。

幻觉、误报与工具依赖仍是主要限制

AI 的结论不能直接当作事实。幻觉、误报、错误假设和过度自信的答案都会出现，所有发现都需要研究人员亲自复现。研究者还应理解被突破的安全边界、控制措施和实际影响，并能脱离 AI 独立写出报告。AI 应当改善研究质量，而不只是制造更多待审核的报告。

测试 AI 功能仍需传统安全控制

对于 AI 驱动的产品，模型输出异常本身并不足以构成高价值漏洞，关键是攻击者能否借此越权访问数据或获得原本不具备的系统权限。模型护栏不宜成为唯一或主要安全边界，授权检查、最小权限、隔离和输入验证仍然不可缺少。

模型输出也应继续被视为不可信输入。如果它未经控制便进入浏览器、数据库查询、Shell 命令或网络请求，传统漏洞仍可能重新出现，包括 XSS、SQL 注入、命令注入和 SSRF。模型是新的组件，但许多危险的最终执行点并不是新的。

漏洞赏金计划带来的核心能力

对于希望提交首份有效报告的研究者，@r31n 的建议是掌握基础原理，选择一个计划和一个目标持续研究，并通过实际使用、阅读文档、观察请求与响应及检查 API 来建立系统模型。实验环境、课程、公开漏洞分析和已披露报告可以帮助训练直觉，但工具无法代替理解。

真正决定报告质量的，不是使用了多少工具，而是能否解释数据如何流动、信任关系为何成立、限制为何存在，并给出安全团队可以复现的 PoC。漏洞赏金计划由此带来的提升，最终仍落在系统性理解、严谨验证和持续追问上。

资料来源：How bug bounty sharpens one researcher’s security skills（2026-10-22）。