本指南的灵感来自 GitHub 的工程系统成功 playbook (ESSP)，其中推荐了推动工程系统改进的策略和指标。
如果你要启动 Copilot 的推出，我们建议定义目标、相应地规划推出，并向员工明确传达目标。 请参阅“使用 GitHub Copilot 实现公司工程目标”。
1.确定阻碍成功的因素
ESSP 建议的第一步是充分了解阻碍公司取得进步的障碍。 通过了解当前的基线、所需的未来状态以及阻碍进步的障碍，可确保更改具有针对性且有效。
开发团队通常专注于速度和功能，以提供新功能并让应用程序保持平稳运行。 随着时间的推移，小问题可能会累积，例如：
- 未修复的已知安全漏洞
- 对存在潜在缺陷的旧软件组件的依赖
- 解决发现的问题的延迟
这会产生 安全债务，这是一个严重的积压问题。
安全债务具有真正的风险。 问题越久不解决，就会变得越大，成本也越高。 大型安全债务使系统容易受到攻击、暴露敏感数据并削弱客户信任。
挑战在于平衡快速开发与维护安全稳定的软件环境。
2.评估你的选项
下一步是评估并商定解决方案，以解决在第一步中确定的障碍。 在本指南中，我们将重点关注 GitHub Copilot 对已确定目标的影响。 新工具的成功推出还需要对文化和流程进行更改。
使用试点组运行新工具和流程的试用，以收集反馈并衡量成功。 有关在试验期间要使用的训练资源和指标，请参阅 3. 实施更改 和 需要监视的指标 部分。
<a href="https://github.com/enterprise/contact?ref_product=copilot&ref_type=engagement&ref_style=button" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline">
<span>联系销售人员</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。
分析代码是否存在安全漏洞
根据代码库的大小， Copilot 在编写代码时可能无法分析整个项目。 这是因为上下文约束。 但是，可以要求它分析特定文件，了解不安全的代码做法。
-
在Visual Studio Code中打开要分析的文件。
-
在 副驾驶聊天，询问：
Analyze this code for potential security vulnerabilities and suggest fixes使用
#file聊天变量专门在提示中包含文件的内容。 还可以使用提示文件和自定义说明来指导 Copilot 的响应。 -
副驾驶聊天 分析代码，识别安全漏洞，并建议修复。 -
查看建议的更改，并根据需要应用这些更改。
其他提示示例：
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 警报显示。 按照以下步骤解决警报：
- 在GitHub上打开警报。
- 单击“ 生成修复”。 这会显示在Copilot可以解决警报时。
-
Copilot自动修复 会生成潜在修复方案并在告警中展示代码变更。 可以将此代码更改提交到新分支或现有分支。 - 测试代码。 然后打开拉取请求，将更改移动到主分支。
- 将更改移动到主分支并 code scanning 验证修补程序后，警报会自动关闭。
适用于开发人员的最佳做法
开发人员应该：****
- 定期使用 副驾驶聊天 来分析代码片段中的漏洞。 在提交更改之前，请习惯检查代码是否存在安全问题。
- 使用Copilot自动修复作为code scanning警报。 出现警报时，首先使用Copilot自动修复来快速处置它们。
-
**向 副驾驶聊天** 提供清晰且具体的提示。 请求越详细，Copilot 就能更好地分析代码并建议相关的修复方案。 例如，包括编程语言和关注的特定领域。
Copilot结合现有安全工具**。 使用 Copilot 作为额外的安全分析层，而不是用来替代专用的安全扫描器和安全措施。
开发人员不得：****
- 自动接受 Copilot“安全建议”。 请始终查看并测试建议的代码更改，以确保这些更改适当且有效。
- 完全依赖于Copilot全面性的安全审核。 Copilot 是一个有用的工具，但它不应取代彻底的安全审查和渗透测试。
- 忽略 code scanning 警报。 及时解决所有警报，即使它们看起来很小，以防止安全债务的积累。
- 用作 Copilot 避免学习安全编码做法的借口。 继续向自己和你的团队教育安全最佳做法。
- 假设 Copilot 将捕获每个漏洞。 安全是一个持续的过程，始终有必要保持警惕。
- 使用 Copilot 绕过安全策略。 遵守组织的安全协议。 利用 Copilot 来增强它们，而不是规避它们。
面向开发人员的资源
要监视的指标
若要评估新工具的试用，并确保完整的推出提供一致的改进，请监视结果并在需要时进行调整。 我们建议考虑 质量、速度和开发人员幸福的关键区域，以及这些区域如何结合在一起，为业务成果做出贡献。
下面是一些指标，用于评估 Copilot 对此特定目标的影响。
- 安全债务比率。 使用安全概述查看警报数量是否随时间而下降。
- 修正安全问题的时间。 使用安全概述查看修正安全问题的时间是否随时间推移。
请参阅“评估代码安全风险”。