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

关于 Copilot Autofix for code scanning

GitHub Copilot Autofix 是 code scanning 的扩展功能，为用户提供针对性建议，以帮助用户修复 code scanning 警报，从而避免引入新的安全漏洞。 潜在修复由大型语言模型 (LLM) 使用代码库和 code scanning 分析中的数据自动生成。 GitHub Copilot Autofix 可用于 CodeQL 分析，并支持第三方工具 ESLint（第三方支持为 公共预览版，可能会更改）。

Copilot Autofix 会生成与现有源代码相关的潜在修复，并将警报的说明和位置转换为可能修复警报的代码更改。 Copilot Autofix 使用与 OpenAI 中的大型语言模型 GPT-4o 建立网络接口的内部 GitHub Copilot API，这些模型具有足够的生成功能，能够生成代码的修复建议以及有关修复的解释性说明文本。

默认允许使用 Copilot Autofix，并为每个使用 CodeQL 的存储库启用该功能，但可以选择退出并禁用 Copilot Autofix。 若要了解如何在企业、组织和存储库级别禁用 Copilot Autofix，请参阅“禁用 Copilot Autofix 进行代码扫描”。

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

开发人员体验

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

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

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

CodeQL code scanning 支持的语言

Copilot Autofix 支持对 C#、C/C++、Go、Java/Kotlin、Swift、JavaScript/TypeScript、Python 和 Ruby 的默认和安全扩展 CodeQL 查询套件中包含的查询子集生成修复。 有关这些查询套件的详细信息，请参阅“CodeQL 查询套件”。

建议生成流程

为存储库启用 Copilot Autofix 时，识别的 code scanning 警报将输入发送到 LLM。 如果 LLM 可以生成潜在修复，则该修复显示为建议。

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

• SARIF 格式的CodeQL 警报数据。 有关详细信息，请参阅“对代码扫描的 SARIF 支持”。
• 当前版本分支的代码。
  • 每个源位置、接收器位置以及警报消息中引用的或包含在流路径中的任何位置的简短代码片段。
  • 涉及任何这些位置的每个文件约前 10 行。
• CodeQL 查询确定问题的帮助文本。 有关示例，请参阅“CodeQL 查询帮助”。

任何 Copilot Autofix 建议都会在 code scanning 后端生成并存储。 它们显示为建议。 除了在代码库上启用code scanning和创建拉取请求之外，无需用户交互。

生成修复程序的过程不会收集或使用超出上述范围的任何客户数据。 因此，此功能的使用受与 GitHub Advanced Security 相关的现有条款和条件的约束。 此外，严禁将 Copilot Autofix 处理的数据用于 LLM 培训目的。 有关 GitHub Advanced Security 条款和条件的详细信息，请参阅免费版、专业版和团队版文档中的“GitHub 附加产品和功能条款”

建议质量

GitHub 使用自动测试工具持续监视 Copilot Autofix 提供的建议的质量。 这样，我们就可以了解随着模型发展 LLM 更改生成的建议。

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

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

GitHub 如何测试建议

在运行code scanning和存储库对结果代码进行单元测试之前，我们将通过合并所有建议的更改（未编辑）来测试建议的有效性。

1. 建议是否已修复 code scanning 警报？
2. 修复是否引起了任何新的 code scanning 警报？
3. 修复是否引起了 code scanning 可以检测到的任何语法错误？
4. 修复是否更改了任何存储库测试的输出？

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

对其他项目的有效性

测试集包含各种不同类型的项目和警报。 我们预测，对于使用 Copilot Autofix 支持的语言的其他项目的建议也应该遵循类似模式。

• Copilot Autofix 可能会为大多数警报添加代码建议。
• 当开发人员评估建议时，我们期望可以在不编辑的情况下提交大多数修复，或者通过次要更新来反映代码更广泛的上下文。
• 一小部分建议的修复将反映出对代码库或漏洞的重大误解。

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

建议的限制

查看 Copilot Autofix 提供的建议时，在接受更改之前，必须始终考虑 AI 的局限性并根据需要编辑更改。 在启用 Copilot Autofix for code scanning 之前，还应考虑更新存储库的 CI 测试和依赖项管理。 有关详细信息，请参阅“减少建议的限制”。

代码建议的限制

• 人类语言：__ 系统主要使用英语数据，包括发送到系统的提示、数据集中 LLM 看到的代码以及用于内部评估的测试用例。 LLM 生成的建议对于使用其他语言编写和其他字符集的源代码和注释可能成功率较低。
• 语法错误：__ 系统可能建议修复语法不正确的代码更改，因此必须在拉取请求上运行语法检查。
• 位置错误：__ 系统建议的修复可能是语法正确但位置错误的代码，这意味着如果用户接受修复而不编辑位置，其将引起语法错误。
• 语义错误：__ 系统可能会建议语法有效但会更改程序语义的修复。 系统不理解程序员或代码库处理代码的意图。 具有良好的测试覆盖率有助于开发人员验证修复是否不会更改代码库的行为。
• 安全漏洞和误导性修复：__ 系统建议的修复可能无法修正基础安全漏洞和/或引起新的安全漏洞。
• 部分修复：__ 系统建议的修复可能仅部分解决安全漏洞，或仅部分保留预期的代码功能。 系统只能看到代码库中代码的一小部分，因此并非总是产生全局最优或正确的解决方案。

依赖项建议的限制

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

• 新的或更新的依赖项：__ 系统可能会建议添加或更新软件依赖项作为建议修复的一部分。 例如，建议更改 JavaScript 项目的 package.json 文件以从 npm 添加依赖项。
• 不支持或不安全的依赖项：__ 系统不知道支持或保护现有依赖项的哪些版本。
• 捏造的依赖项：__ 系统不完全了解在更广泛的生态系统中发布的依赖项。 这可能会导致建议添加对恶意软件的新依赖项，攻击者可能会将其发布在统计上可能的依赖名称下。

减少建议的限制

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

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

后续步骤

• “关于代码扫描警报”
• “鉴定拉取请求中的代码扫描警报”
• “解决代码扫描警报
• “禁用 Copilot Autofix 进行代码扫描”