负责任地使用 Copilot Autofix 进行代码扫描

关于 Copilot Autofix 用于代码扫描

GitHub Copilot Autofix 是代码扫描的扩展功能，向用户提供有针对性的建议，帮助他们修复代码扫描警报，从而避免引入新的安全漏洞。潜在修复由大型语言模型（LLM）自动生成，使用代码库数据以及代码扫描分析结果。GitHub Copilot Autofix 适用于 CodeQL 分析。

注意

使用 GitHub Copilot Autofix 无需 GitHub Copilot 订阅。Copilot Autofix 对 GitHub.com 上的所有公共仓库以及拥有 GitHub 代码安全许可证的组织和企业内部或私有仓库均可使用。

Copilot Autofix 生成的潜在修复与现有源代码相关，并将警报的描述和位置转换为可能修复该警报的代码变更。Copilot Autofix 使用内部 GitHub Copilot API 与来自 OpenAI 的大语言模型 GPT‑5.1 对接，具备足够的生成能力来提供代码修复建议以及对应的解释性文字。

Copilot Autofix 默认已启用，并对所有使用 CodeQL 的仓库开放，但您可以选择退出并禁用 Copilot Autofix。欲了解如何在企业、组织或仓库层面禁用 Copilot Autofix，请参阅禁用代码扫描安全警报的 Copilot Autofix。

在组织的安全概览仪表板中，您可以查看在给定时间段内组织内部的开启和关闭的 Pull Request 上生成的代码建议总数。更多信息请参阅查看安全洞察。

开发者体验

代码扫描用户已经可以看到安全警报并分析他们的 Pull Request。然而，开发者往往缺乏安全编码的培训，修复这些警报需要付出大量精力。他们必须先阅读并理解警报的位置和描述，再根据这些信息编辑源代码以修复漏洞。

Copilot Autofix 通过将最佳实践信息、代码库细节以及警报信息相结合，为开发者提供潜在的修复建议，从而降低了进入门槛。开发者不必先去搜索漏洞信息，而是直接得到一条展示潜在解决方案的代码建议。开发者随后评估该建议，看它是否是针对其代码库的最佳方案，并确保其保持预期行为。

在提交建议的修复或已修改的修复后，开发者应始终确认代码库的持续集成（CI）测试仍然通过，并且警报已标记为已解决，随后再合并其 Pull Request。

CodeQL 代码扫描支持的语言

Copilot Autofix 支持对默认和安全扩展的 CodeQL 查询套件中包含的部分查询生成修复，支持的语言包括 C#、C/C++、Go、Java/Kotlin、Swift、JavaScript/TypeScript、Python、Ruby 和 Rust。有关这些查询套件的更多信息，请参阅CodeQL 查询套件。

建议生成流程

当为仓库启用 Copilot Autofix 时，识别到的代码扫描警报会将输入发送给 LLM。如果 LLM 能生成潜在修复，则该修复会以建议形式展示。

GitHub 向 LLM 发送来自代码扫描分析的多种数据。例如：

以 SARIF 格式的 CodeQL 警报数据。更多信息请参阅代码扫描的 SARIF 支持。
分支当前版本的代码。
- 每个源位置、汇点位置以及警报信息中引用的任何位置周围的短代码片段。
- 涉及上述任意位置的每个文件的前约 10 行。
导致问题的 CodeQL 查询的帮助文本。示例请参阅CodeQL 查询帮助。

任何 Copilot Autofix 建议都会在代码扫描后端生成并存储，然后以建议形式展示。除在代码库上启用代码扫描并创建 Pull Request 之外，无需任何额外的用户交互。

生成修复的过程不会收集或使用超出上述范围的任何客户数据。因此，此功能的使用受高级安全（Advanced Security）现有条款和条件的约束。此外，Copilot Autofix 处理的数据严格不用于 LLM 的训练目的。有关高级安全条款和条件的更多信息，请参阅附加产品和功能的 GitHub 条款。

Copilot Autofix 的局限性与非确定性

Copilot Autofix 并不能在所有情况下为每个警报生成修复。该功能基于最佳努力原则，无法保证 100% 成功。

当可能无法生成 Copilot Autofix 建议时

多种因素可能导致 Copilot Autofix 无法成功生成建议修复。

非确定性：底层的大语言模型是生成模型，具有非确定性。这意味着即使在相同的警报和代码下，也可能无法产生可行的建议，或不同尝试之间的建议会有所差异。
问题复杂性与上下文：某些安全警报需要在复杂的多文件代码库中追踪数据流，或涉及细微的逻辑缺陷，模型可能难以解决。
文件大小：如果受影响的代码位于非常大的文件或仓库中，提供给 LLM 的上下文可能会被截断。模型需要足够的上下文来理解周围代码逻辑并安全地应用修复；当上下文不足时，功能将不会尝试修复。
语言和框架覆盖范围：虽然 Copilot Autofix 支持的语言和 CodeQL 警报列表在不断增长，但它并不覆盖所有可能的警报类型或语言。

建议的质量

GitHub 使用自动化测试平台持续监控 Copilot Autofix 建议的质量。这使我们能够了解 LLM 随模型迭代产生的建议如何变化。

该测试平台包含来自大量公共仓库的 2,300 多条警报，这些仓库的相关代码都有测试覆盖率。我们会对这些警报的建议进行测试，以评估其质量——即开发者在将其提交到代码库之前需要进行多少编辑。对于许多测试警报，LLM 生成的建议可以直接提交，从而修复警报并且仍然成功通过所有现有的 CI 测试。

此外，系统会进行压力测试（通常称为红队测试），以检测潜在危害，并通过 LLM 的过滤系统防止向用户展示可能有害的建议。

GitHub 如何测试建议

我们通过在运行代码扫描和仓库单元测试之前，直接合并所有未编辑的建议更改来检验建议的有效性。

代码扫描警报是否已被建议修复？
该修复是否引入了新的代码扫描警报？
该修复是否引入了代码扫描能够检测到的语法错误？
该修复是否改变了任意仓库测试的输出？

此外，我们会抽样检查许多成功的建议，确认它们在不引入新问题的情况下修复了警报。当其中一项或多项检查未通过时，手动分类显示多数情况下提出的修复已基本正确，只需用户进行少量修改即可。

在其他项目上的有效性

测试集涵盖了各类项目和警报。我们预计对使用 Copilot Autofix 支持语言的其他项目，建议的表现会类似。

Copilot Autofix 很可能会为大多数警报提供代码建议。
当开发者评估这些建议时，我们预计多数修复可以在不编辑或仅需少量修改以适应代码整体上下文的情况下直接提交。
少数建议的修复会严重误解代码库或漏洞。

然而，每个项目和代码库都有其独特性，开发者可能需要对更大比例的建议进行编辑后才能提交。Copilot Autofix 提供有价值的信息帮助您解决代码扫描警报，但最终仍由您负责评估所提变更，确保代码的安全性和正确性。

注意

对受支持语言的修复生成受 LLM 运行容量限制。此外，每个建议的修复在加入 Pull Request 之前都会经过内部测试。如果没有可用建议，或建议的修复未通过内部测试，则不会显示任何建议。

建议的局限性

在审查 Copilot Autofix 的建议时，您必须始终考虑 AI 的局限性，并在接受更改之前根据需要编辑这些更改。同时，在为代码扫描启用 Copilot Autofix 之前，建议先更新 CI 测试和依赖管理策略。更多信息请参阅缓解建议局限性的方法。

代码建议的局限性

人类语言：系统主要使用英文数据，包括发送给系统的提示、LLM 数据集中的代码以及内部评估使用的测试用例。对于用其他语言或字符集编写的源代码和注释，LLM 生成的建议成功率可能较低。
语法错误：系统可能会建议语法上不正确的代码更改，因此在 Pull Request 上运行语法检查至关重要。
位置错误：系统可能会建议语法正确但位于错误位置的修复。如果用户在不编辑位置的情况下接受该修复，可能会引入语法错误。
语义错误：系统可能会建议在语法上有效但改变程序语义的修复。系统并不了解程序员或代码库对代码行为的意图。良好的测试覆盖有助于开发者验证修复不会改变代码库的行为。
安全漏洞与误导性修复：系统可能会建议未能消除根本安全漏洞，甚至引入新的安全漏洞的修复。
部分修复：系统可能会建议仅部分解决安全漏洞或仅部分保留预期代码功能的修复。系统仅看到代码库的一小部分，并不总能产生全局最优或完全正确的解决方案。

依赖建议的局限性

有时建议的修复会包含对代码库依赖项的更改。如果您使用依赖管理系统，任何更改都会自动高亮供开发者审查。在合并 Pull Request 之前，请始终确认所有依赖项更改是安全的并且保持代码库的预期行为。

新依赖或已更新的依赖：系统可能会在建议修复时提出添加或更新软件依赖的方案。例如，建议修改 JavaScript 项目的 package.json 文件以添加 npm 依赖。
不受支持或不安全的依赖：系统并不了解现有依赖的哪些版本是受支持或安全的。
虚构的依赖：系统对整个生态系统中已发布的依赖了解不完整，这可能导致它建议添加一个恶意软件的依赖，该恶意软件发布者使用了统计上可能的依赖名称。

缓解建议局限性的方法

缓解 Copilot Autofix 建议局限性的最佳方式是遵循最佳实践，例如使用 Pull Request 的 CI 测试来验证功能需求未受影响，以及使用依赖审查 API 与 Action 等依赖管理方案。更多信息请参阅关于依赖审查。

请务必记住，Pull Request 的作者仍需对其如何响应审查评论和代码变更（无论是同事还是自动化工具提出的）负责。开发者应始终批判性地审视代码变更建议，并在必要时编辑这些建议，确保最终的代码与应用程序是正确的、安全的，满足性能以及所有其他功能和非功能性需求。

谁可以使用此功能？

本文内容