安全研究社区是 GitHub 最宝贵的资产之一。每年，来自世界各地的研究人员都帮助我们发现并修复漏洞，让平台对超过 1.8 亿开发者而言更加安全。我们设立漏洞赏金计划，是因为我们相信与外部研究人员合作是提升安全性的最有效途径之一，对此我们始终坚定不移。

但如同所有漏洞赏金计划一样，我们也在适应不断变化的行业环境。我们希望分享我们所观察到的现状、我们采取的应对措施，以及我们如何看待像 GitHub 这类平台的安全边界。

数量问题

过去一年，全行业的报告提交量显著增长。包括 AI 在内的新工具降低了安全研究的门槛，这在诸多方面带来了积极影响。更多人参与探索攻击面，意味着发现真实安全问题的机会也随之增加。

然而，在有效报告增长的同时，我们也观察到大量未能证明实际安全影响的提交急剧增加。这些提交包括缺乏概念验证的报告、经不起严格推敲的理论攻击场景，以及已涵盖在我们已公布的不符合条件列表中的发现。这一现象并非 GitHub 独有。全行业的相关计划都在应对同样的挑战，部分计划甚至已完全关闭。

我们并不希望走向那样的结局。相反，我们致力于投入资源，持续优化我们的计划。

怎样的提交才算优秀

我们提高了对“完整提交”的认定标准。今后，报告将严格依据以下准则进行评估：

• 具备可运行的概念验证（PoC）并证明实际安全影响。请向我们展示具体影响，而非仅作描述。攻击者究竟能实现什么？我们需要能够展示真实利用过程与具体安全影响的可运行概念验证。请证明可被突破的边界，而非仅指出理论上存在。若报告仅称“这可能导致……”却未能证实其确实发生，则视为不完整。
• 了解项目范围与不予受理的发现。提交前，请查阅我们的项目范围及不予受理的发现列表。涉及已知不予受理类别（如 DMARC/SPF/DKIM 配置、用户枚举、未演示攻击路径的缺失安全标头等）的报告将按“不适用”关闭，这可能会影响您的 HackerOne Signal 和声誉。
• 提交前验证。无论使用何种工具（扫描器、静态分析工具或 AI 助手），提交前都必须验证输出结果。经人工复核的误报可在浪费他人时间前被拦截；未经复核的则只是噪音。

我们欢迎在安全研究中使用 AI。

我们想明确表态：我们完全支持研究人员使用AI工具。AI能够发挥效能倍增器的作用，我们预计它将在安全研究中扮演越来越重要的角色。我们自身的内部安全项目已在全面应用AI，同时也观察到最顶尖的外部研究人员正在采取同样的做法。我们对此表示欢迎。

我们要求的标准始终如一：必须经过验证。那些经过核实、成功复现，并附带有效概念验证（PoC）的AI辅助发现，才是优质的提交。而未经任何验证、原样提交且缺乏复现过程或影响证明的AI输出，则不符合要求。这并非新设立的标准，而是我们一贯应用于漏洞扫描器输出、静态分析工具及其他任何工具的相同准则。提交内容的准确性最终由研究人员本人负责。

我们同时建议研究人员保持报告的简洁性与结构化。一份高质量的报告应包含三个要素：漏洞简要概述、附带支持证据（如截图、HTTP请求、终端输出）的清晰复现步骤，以及阐明攻击者实际可造成何种影响的作用范围说明。仅此而已。冗长拖沓的报告（例如多页的理论推演、重复的背景介绍或AI生成的注水内容）会拖慢漏洞报告初筛的进度，因为真正的漏洞信息往往被淹没其中。报告越清晰直观，我们就能越快采取处置措施。

工具并不重要，真正重要的是工作的质量。

我们经常观察到的一种模式值得单独探讨。许多报告描述了如下场景：用户与攻击者控制的内容（如恶意仓库、精心构造的 Issue、不受信任的代码）进行交互后，遭遇了不良后果。这些报告通常行文严谨、技术观察准确，但却误解了安全边界究竟位于何处。

我们在系统和团队上投入大量资源，致力于在全平台范围内检测与处理恶意内容，涵盖从自动扫描到人工审核的各个环节。尽管如此，GitHub 采用共同责任模型。用户需负责：

• 选择他们信任的代码仓库、议题和代码。GitHub 托管着超过 6 亿个代码仓库。并非所有仓库都是无害的。用户需自行判断要与哪些内容进行交互。
• 在执行或与之交互前审查内容。这适用于代码、脚本、工作流以及任何其他可执行内容。
• 需理解克隆代码仓库即意味着选择信任其中的代码。Git hooks、构建脚本及其他仓库级自动化之所以会执行，是因为用户选择了检出该仓库。
• 安全配置自身环境。令牌管理、凭据存储及本地安全设置均由用户自行负责。

当“攻击”要求受害者主动寻找并与攻击者控制的内容进行交互（克隆恶意仓库、要求 AI 工具分析不可信代码、打开特制文件）时，安全边界在于用户是否决定信任该内容。此类场景通常不构成对 GitHub 安全控制的绕过。

常见示例

为帮助研究人员校准预期，以下列举了我们经常观察到、属于共同责任范畴的典型模式：

这些领域的研究依然极具价值。如果您认为自己发现了我们防御中的盲点（一种能够绕过实际安全控制、影响用户，且无需用户主动信任恶意内容的方法），这正是我们最希望了解的情况。此类发现往往是我们收到的最具影响力的提交。此外，如果您发现违反我们服务条款的内容，请向我们举报。

这对研究人员意味着什么

如果您已持续提交高质量的研究成果，衷心感谢。除因我们清理无效队列而带来的响应提速外，您的提交体验将保持不变。

如果您是漏洞赏金计划的新手，欢迎加入！请花几分钟仔细阅读我们的漏洞范围，查阅非受理列表，并在提交前务必准备好可复现的概念验证（PoC）。我们一贯高度重视并感谢新研究员提交的优质报告。

如果您此前一直侧重于提交数量，我们建议您将重心转向深度挖掘。一份经过充分调研与验证的发现，其价值远超十份推测性报告，无论体现在赏金回报还是个人声誉上皆是如此。在本计划中斩获最高收益的研究员，往往是那些深耕细作的人。

低风险发现奖励方式的调整

并非所有有效的提交都构成实质性的安全风险。部分报告指出了系统加固的机会或文档疏漏，尽管这些发现无法被直接利用，但仍促使我们主动进行了改进。我们对此类贡献表示感谢。

今后，我们将更新此类情况的处理流程。对于未构成显著安全影响但确实促成了代码或文档修复的提交，我们将以 GitHub 周边礼品作为认可，而非发放现金赏金。此举旨在在肯定贡献者价值的同时，将赏金资源集中投入到对平台安全影响最为重大的发现上。

我们更希望研究人员能将时间投入到更深入、高影响力的研究中，并获得相应的报酬，而非一味追求低风险发现的数量。

展望未来

我们致力于将 GitHub 的漏洞赏金计划打造成业内最佳项目之一，以惠及研究人员并保障平台安全。这意味着更快的漏洞评估、更清晰的沟通，以及确保有效发现获得应有的关注与奖励。提高质量标准正是这项投入的一部分。

安全研究人员让每一位依赖 GitHub 的开发者都能拥有更安全的体验。这项工作意义重大，我们绝不会将其视为理所当然。

祝你编码愉快！🚀

作者

正文：Jarom Brown

正文：@jarombrown

高级产品安全工程师（漏洞赏金）