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

关于 Copilot自动修复的 code scanning

          GitHub Copilot自动修复 这是一个扩展 code scanning ，为用户提供有针对性的建议，帮助他们修复 code scanning 警报，以便他们避免引入新的安全漏洞。 潜在修复由大型语言模型（LLM）通过利用来自代码库和code scanning分析的数据自动生成。 
          GitHub Copilot自动修复 可用于 CodeQL 分析。

注意

无需订阅 GitHub Copilot 即可使用 GitHub Copilot自动修复。 Copilot自动修复可供 GitHub.com 上的所有公共存储库使用，也可供具备 GitHub Code Security 许可证的组织和企业拥有的内部或私有存储库使用。

          Copilot自动修复 生成与现有源代码相关的潜在修正，并将警报的描述和位置转换成可能的代码变更，以修复警报。 
          Copilot自动修复 使用内部 GitHub Copilot API 与 OpenAI 的大型语言模型 GPT-5.1 交互，该模型具有足够的生成能力，可以生成代码的建议修复和这些修复的解释性文本。

          Copilot自动修复 默认允许并在每个使用 CodeQL 的存储库中启用，但您可以选择退出并禁用 Copilot自动修复。 若要了解如何在企业、组织和存储库级别禁用 Copilot自动修复 ，请参阅 [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/disabling-autofix-for-code-scanning)。

在组织的安全概览仪表板中，可以查看在给定时间段为组织中打开和关闭的拉取请求生成的代码建议总数。有关详细信息，请参阅“查看安全洞察”。

开发人员体验

          Code scanning 用户已经可以看到安全警报来分析其拉取请求。 然而，开发人员通常很少接受过安全编码方面的培训，因此修复这些警报需要大量精力。 他们必须先阅读并理解警报位置和说明，然后使用该理解来编辑源代码以修复漏洞。

          Copilot自动修复 通过将有关最佳做法的信息与代码库的详细信息和警报相结合来降低开发人员进入障碍，以便向开发人员建议潜在的修补程序。 开发人员不是从搜索有关漏洞的信息开始，而是从展示其代码库潜在解决方案的代码建议开始。 开发人员评估潜在的修复，以确定其是否为其代码库的最佳解决方案，并确保其保持预期行为。

提交建议的修复或修改的修复后，开发人员应始终验证代码库的持续集成测试 (CI) 是否继续传递，并且警报在合并拉取请求之前显示为已解决。

支持的语言 CodeQLcode scanning

          Copilot自动修复 支持为 C#、C/C++、Go、Java/Kotlin、Swift、JavaScript/TypeScript、Python、Ruby 和 Rust 中默认和安全扩展 CodeQL 查询套件所包含的查询子集生成修复。 有关这些查询套件的详细信息，请参阅 [AUTOTITLE](/code-security/code-scanning/managing-your-code-scanning-configuration/codeql-query-suites#built-in-codeql-query-suites)。

建议生成流程

启用了 Copilot自动修复的存储库中，已识别的 code scanning 警报会向 LLM 发送输入。如果 LLM 可以生成可能的修补程序，则该修补程序显示为建议。

          GitHub 向 LLM 发送来自 code scanning 分析的各种数据。 例如：

* CodeQL SARIF 格式的警报数据。有关详细信息，请参阅“对代码扫描的 SARIF 支持”。

来自分支当前版本的代码。
- 每个源位置、接收器位置以及警报消息中引用的或包含在流路径中的任何位置的简短代码片段。
- 涉及任何这些位置的每个文件约前 10 行。
标识问题的查询的 CodeQL 帮助文本。有关示例，请参阅 CodeQL 查询帮助。

后端中生成的任何 Copilot自动修复建议都会被存储在 code scanning 中。它们显示为建议。除了在代码库上启用 code scanning 和创建拉取请求之外，不需要用户交互。

生成修复程序的过程不会收集或使用超出上述范围的任何客户数据。因此，此功能的使用受与 Advanced Security现有条款和条件相关的约束。此外，由 Copilot自动修复处理的数据绝对不会用于 LLM 训练目的。有关条款和条件的详细信息 Advanced Security ，请参阅 GitHub 附加产品和功能条款。

对Copilot自动修复的限制和非确定性

          Copilot自动修复 对于 code scanning 警报，无法在每种情况下为每个警报生成修补程序。 该功能会尽力运行，无法保证每次都能 100% 成功。

当Copilot自动修复建议可能未生成时

多种因素可以阻止 Copilot自动修复成功生成建议的修复措施。

        _不确定性：_ 基础大型语言模型是一种生成式模型，因此具有不确定性。 这意味着，即使对于相同警报和代码，也可能无法生成可行的建议，或者建议可能会因不同尝试而异。

        _问题复杂性和上下文：_ 某些安全警报（例如需要在复杂的多文件代码库中追踪数据流，或者涉及细微逻辑缺陷），可能会使模型难以解决问题。

        _文件大小：_ 如果受影响的代码位于非常大的文件或存储库中，提供给 LLM 的上下文可能会被截断。 模型需要足够的上下文来了解周围的代码逻辑并安全地应用修补程序；当此上下文有限时，该功能将不会尝试修复。

        _语言和框架覆盖范围：_ 虽然 Copilot自动修复 支持越来越多的语言和 CodeQL 警报，但它并不涵盖每种可能的警报类型或语言。

建议质量

          GitHub 使用自动化测试工具持续监视来自 Copilot自动修复的建议质量。 这使我们能够了解 LLM 生成的建议如何随着模型的发展而变化。

该测试工具包含一组来自各种公共存储库的 2,300 多个警报，其中突出显示的代码具有测试覆盖率。对这些警报的建议进行了测试，以了解其质量，也就是说，开发人员在将它们提交到代码库之前需要对其进行多少编辑。对于许多测试警报，LLM 生成的建议可以按原样提交，以修复警报，同时继续成功通过所有现有的 CI 测试。

此外，该系统还进行压力测试，以检查任何潜在危害（通常称为红队测试），LLM 上的筛选系统有助于防止向用户显示潜在有害的建议。

GitHub 如何测试建议

在运行 code scanning 和存储库代码的单元测试之前，我们将所有建议的更改合并在一起（不做任何编辑）以测试建议的有效性。

警报是否已通过建议code scanning修复？
修补程序是否引入了任何新 code scanning 警报？
修复是否引入了任何语法错误，这些错误可以被 code scanning 检测到？
修复是否更改了任何存储库测试的输出？

此外，我们还会抽查许多成功的建议，验证其是否修复警报而不会引起新问题。当其中一项或多项检查失败时，我们的手动审查表明，在许多情况下，建议的修复几乎正确，但需要用户能够识别并手动执行的一些细微的修改。

对其他项目的有效性

测试集包含各种不同类型的项目和警报。我们预测使用支持 Copilot自动修复的语言的其他项目的建议应遵循类似的模式。

        Copilot自动修复 可能会向大多数警报添加代码建议。

当开发人员评估这些建议时，我们希望大多数修补程序可以在不进行编辑或进行小幅更新的情况下提交，以反映代码的更广泛上下文。
一小部分建议的修复将反映出对代码库或漏洞的重大误解。

但是，每个项目和代码库都是唯一的，因此开发人员可能需要在提交之前编辑较大比例的建议修复。 Copilot自动修复提供有价值的信息来帮助解决 code scanning 警报，但最终仍负责评估建议的更改并确保代码的安全性和准确性。

注意

受支持语言的修复生成受 LLM 操作容量的约束。此外，在将建议的每个修复添加到拉取请求之前都会对其进行测试。如果没有可用的建议，或者建议的修补程序未通过内部测试，则不会显示任何建议。

建议的限制

在审核来自 Copilot自动修复的建议时，必须始终考虑 AI 的限制，并在接受建议前根据需要修改。在启用Copilot自动修复code scanning之前，还应考虑更新存储库的 CI 测试和依赖项管理。有关详细信息，请参阅减少建议的限制。

代码建议的限制

        _人类语言：_ 系统主要使用英语数据，包括发送到系统的提示、数据集中 LLM 看到的代码以及用于内部评估的测试用例。 LLM 生成的建议对于使用其他语言编写和其他字符集的源代码和注释可能成功率较低。

        _语法错误：_ 系统可能建议修复语法不正确的代码更改，因此必须在拉取请求上运行语法检查。

        _位置错误：_ 系统建议的修复可能是语法正确但位置错误的代码，这意味着如果用户接受修复而不编辑位置，其将引起语法错误。

        _语义错误：_ 系统可能会建议语法有效但会更改程序语义的修复。 系统不理解程序员或代码库处理代码的意图。 具有良好的测试覆盖率有助于开发人员验证修复是否不会更改代码库的行为。

        _安全漏洞和误导性修复：_ 系统建议的修复可能无法修正基础安全漏洞和/或引起新的安全漏洞。

        _部分修复：_ 系统建议的修复可能仅部分解决安全漏洞，或仅部分保留预期的代码功能。 系统只能看到代码库中代码的一小部分，因此并非总是产生全局最优或正确的解决方案。

依赖项建议的限制

有时建议的修复包括代码库依赖项的更改。如果使用依赖项管理系统，系统会自动突出显示任何更改，供开发人员查看。在合并拉取请求之前，始终验证任何依赖项更改是否安全，并维护代码库的预期行为。

        _新的或更新的依赖项：_ 系统可能会建议添加或更新软件依赖项作为建议修复的一部分。 例如，建议更改 JavaScript 项目的 `package.json` 文件以从 npm 添加依赖项。

        _不支持或不安全的依赖项：_ 系统不知道支持或保护现有依赖项的哪些版本。

        _捏造的依赖项：_ 系统不完全了解在更广泛的生态系统中发布的依赖项。 这可能会导致建议添加对恶意软件的新依赖项，攻击者可能会将其发布在统计上可能的依赖名称下。

减少建议的限制

遵循最佳实践是缓解Copilot自动修复建议局限性的最佳方法。例如，使用 CI 测试拉取请求来验证功能要求是否不受影响，并使用依赖项管理解决方案（例如依赖项审查 API 和操作）。有关详细信息，请参阅“关于依赖项评审”。

请务必记住，无论是同事还是自动化工具提出的建议，拉取请求的作者仍需对如何响应审查注释和建议的代码更改负责。开发人员应始终以批判的眼光看待修改代码的建议。如果需要，他们应编辑建议的更改，以确保生成的代码和应用程序正确、安全、满足性能条件，并满足应用程序所有其他功能和非功能要求。

后续步骤

        [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts)

        [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests#working-with-autofix-suggestions-for-alerts-on-a-pull-request)

        [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/resolving-code-scanning-alerts#generating-suggested-fixes-for-code-scanning-alerts)

        [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/disabling-autofix-for-code-scanning)