使用 GitHub Copilot 减少公司的安全债务

了解功能、赋能开发人员并衡量 Copilot 的影响。

谁可以使用此功能？

GitHub Copilot业务 or GitHub Copilot Enterprise

在本文中

本指南的灵感来自 GitHub 的工程系统成功 playbook (ESSP)，其中推荐了推动工程系统改进的策略和指标。

如果你要启动 Copilot 的推出，我们建议定义目标、相应地规划推出，并向员工明确传达目标。 请参阅“使用 GitHub Copilot 实现公司工程目标”。

1.确定阻碍成功的因素

ESSP 建议的第一步是充分了解阻碍公司取得进步的障碍。 通过了解当前的基线、所需的未来状态以及阻碍进步的障碍，可确保更改具有针对性且有效。

开发团队通常专注于速度和功能，以提供新功能并让应用程序保持平稳运行。 随着时间的推移，小问题可能会累积，例如：

  • 未修复的已知安全漏洞
  • 对存在潜在缺陷的旧软件组件的依赖
  • 解决发现的问题的延迟

这会产生 安全债务，这是一个严重的积压问题。

安全债务具有真正的风险。 问题越久不解决，就会变得越大，成本也越高。 大型安全债务使系统容易受到攻击、暴露敏感数据并削弱客户信任。

挑战在于平衡快速开发与维护安全稳定的软件环境。

2.评估你的选项

下一步是评估并商定解决方案，以解决在第一步中确定的障碍。 在本指南中，我们将重点关注 GitHub Copilot 对已确定目标的影响。 新工具的成功推出还需要对文化和流程进行更改。

使用试点组运行新工具和流程的试用，以收集反馈并衡量成功。 有关在试验期间要使用的训练资源和指标，请参阅 3. 实施更改 和 需要监视的指标 部分。

          <a href="https://github.com/github-copilot/purchase?ref_product=copilot&ref_type=trial&ref_style=button&ref_plan=enterprise" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline">
          <span>注册 Copilot</span> <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-link-external" aria-label="link external icon" role="img"><path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path></svg></a>

Copilot 如何提供帮助

Copilot 将安全注意事项直接集成到开发生命周期中。 这有助于开发人员主动识别和解决潜在漏洞，同时确保项目保持最新。

Copilot 可在整个软件开发生命周期内降低安全漏洞风险。

在开发期间

Copilot 在编写代码的同时对其进行审查。 它利用它对共同安全漏洞的理解来标记可能容易受到剥削的地区。 此实时分析显示可能会在标准开发或初始安全评审期间错过的隐藏漏洞。

当 Copilot 发现问题时，它会建议更改代码以修复漏洞。 这让你能够尽早解决弱点，并防止安全债务积累。

持续维护

Copilot 与 GitHub 的代码扫描功能集成，确保现有代码库安全。 当代码扫描识别到安全警报时，Copilot自动修复 会对其进行分析，并提供有针对性的建议来消除警报。

这些建议的修复可减少研究漏洞并确定如何处理漏洞的时间。 这有助于更有效地解决安全警报，并防止持续的安全债务。

文化考量

除了推出 GitHub Copilot 外，还要解决可能阻碍你实现目标的任何社会或文化因素。

以下示例取自 ESSP 中的“反模式”部分。

  • 团队可能会忽略或推迟安全债务。 这样，低效且易受攻击的系统就可以继续存在。 这可能是由于最后期限驱动的焦点集中在功能上，或缺乏关于安全债务长期影响的教育造成的。
  • Teams 可能会为简单问题 构建过于复杂的解决方案 。 这使得代码难以维护和安全问题更难检测。 这可能是由于希望不必要地证明未来或压力通过复杂性增加价值造成的。

3.在生产中

确定克服障碍的正确方法后，请实施并扩大你确定的解决方案。 若要成功推出新工具或流程，请将所有权分配给推出的每个部分，以透明方式传达目标，提供有效的培训，并衡量结果。

本部分为开发人员提供了示例场景、最佳做法和资源。 使用本部分来规划通信和培训课程，帮助员工以符合你的目标的方式使用 Copilot。

  •         [分析代码是否存在安全漏洞](#analyze-your-code-for-security-vulnerabilities)

  •         [使用 Copilot自动修复 处理 code scanning 警报](#use-copilot-autofix-for-code-scanning-alerts)

  •         [适用于开发人员的最佳做法](#best-practices-for-developers)

  •         [面向开发人员的资源](#resources-for-developers)

分析代码是否存在安全漏洞

具体取决于代码库的大小，Copilot 可能无法在您编写代码时分析整个项目。 这是因为上下文约束。 但是，可以要求它分析特定文件，了解不安全的代码做法。

  1. 在 Visual Studio Code 中打开文件进行分析。

  2. 在 Copilot对话 中，询问：Analyze this code for potential security vulnerabilities and suggest fixes

    使用 #file 聊天变量专门在提示中包含文件的内容。 可以使用提示文件和自定义指令来指导 Copilot 的响应。

  3. Copilot对话 分析代码，识别安全漏洞，并提出修复建议。

  4. 查看建议的更改，并根据需要应用这些更改。

其他提示示例：

  • Are there any security vulnerabilities in my code? If so, can you explain them and suggest fixes?
  • Does this code follow secure code best practices? If not, what specific improvements can I make?
  • What are the potential security risks in this code if it were deployed to production? How can I mitigate them?

使用 Copilot自动修复 处理 code scanning 警报

Copilot自动修复 是 GitHub Code Security 的一部分，它建议对 code scanning 警报进行潜在修复。 它可以在公共存储库和具有 GitHub Code Security 许可证的存储库中使用。

当你在存储库上运行代码扫描时，会以 code scanning 警报的形式引发潜在问题。 按照以下步骤解决警报：

  1. 在 GitHub 上打开警报。
  2. 单击“ 生成修复”。 这会显示当 Copilot 可以解决警报时。
  3. Copilot自动修复 生成可能的解决方案，并在警报中向你展示代码的更改内容。 可以将此代码更改提交到新分支或现有分支。
  4. 测试代码。 然后打开拉取请求，将更改移动到主分支。
  5. 将更改移动到主分支，code scanning 验证修复后，警报会自动关闭。

适用于开发人员的最佳做法

开发人员应该：****

  •         **定期使用Copilot对话分析代码片段中的漏洞**。 在提交更改之前，请习惯检查代码是否存在安全问题。

  •           **使用 Copilot自动修复 处理 code scanning 警报**。 出现警报时，第一步使用 Copilot自动修复 快速处理警报。

  •           **为 Copilot对话 提供清晰具体的提示**。 请求越详细，Copilot 就越能分析代码并提出相关修复建议。 例如，包括编程语言和关注的特定领域。

  •           **将 Copilot 与现有的安全工具组合在一起**。 使用 Copilot 作为额外的安全分析层，而不是作为专用安全扫描程序和做法的替代。

开发人员不得：****

  •         **自动接受 Copilot 的安全建议**。 请始终查看并测试建议的代码更改，以确保这些更改适当且有效。

  •           **仅依靠 Copilot 进行全面的安全审查**。 Copilot 是一个有用的工具，但它不应取代全面的安全审查和渗透测试。

  •         **忽略 code scanning 警告**。 及时解决所有警报，即使它们看起来很小，以防止安全债务的积累。

  •           **将 Copilot 作为借口来逃避学习安全编码规范的做法是不可取的**。 继续向自己和你的团队教育安全最佳做法。

  •           **假设 Copilot 将捕获每个漏洞**。 安全是一个持续的过程，始终有必要保持警惕。

  •           **使用 Copilot 绕过安全策略**。 遵守组织的安全协议。 请将 Copilot 视为一种能够提升而非规避这些功能的工具。

面向开发人员的资源

  •           [在 GitHub 中Copilot聊天](/copilot/using-github-copilot/copilot-chat/asking-github-copilot-questions-in-github)

  •         [AUTOTITLE](/copilot/copilot-chat-cookbook/security-analysis/finding-existing-vulnerabilities-in-code)

  •         [GitHub Skills - 开始使用 GitHub Copilot](https://github.com/skills/getting-started-with-github-copilot)

要监视的指标

若要评估新工具的试用，并确保完整的推出提供一致的改进，请监视结果并在需要时进行调整。 我们建议考虑 质量、速度和开发人员幸福的关键区域，以及这些区域如何结合在一起，为业务成果做出贡献。

下面是一些指标，用于评估 Copilot 对此特定目标的影响。

  •         **安全债务比率**。 使用安全概述查看警报数量是否随时间而下降。

  •         **修正安全问题的时间**。 使用安全概述查看修正安全问题的时间是否随时间推移。

请参阅“评估代码安全风险”。