在全组织范围内启用 GitHub Secret Protection 之前，请先进行试点，以在少量仓库上验证该解决方案。试点有助于您完善推行策略、识别工作流调整，并向利益相关者展示安全价值。本文将帮助您选择最合适的试点仓库。
成功的试点需要进行战略性的仓库选择。您选择的仓库决定了展示价值的速度、收集可操作反馈的效率，以及为全组织采用做好准备的程度。
选择标准
成功的试点需要进行战略性的仓库选择。您选择的仓库决定了展示价值的速度、收集可操作反馈的效率，以及为全组织采用做好准备的程度。
选择仓库时，请考虑以下标准。
活跃的开发与团队参与
您的试点需要能够及时反馈 Secret Protection 如何融入日常开发工作的仓库。
- 选择具有定期提交和拉取请求的仓库。活跃的仓库能够快速产生反馈，并展示 Secret Protection 如何适用于真实的开发工作流。
- 选择会参与试点的团队。积极响应的维护者会更快识别工作流调整，并帮助完善您的推行策略。
- 使用仓库属性系统地按团队、关键性或其他自定义属性识别仓库。见组织中仓库的自定义属性管理。
已知的密钥泄露
选择在密钥风险评估中被标记的仓库。这些仓库是理想的试点候选，因为它们通过展示需要修复的密钥而立即体现价值。
优先考虑包含生产凭证、基础设施配置或与关键服务集成的仓库。这些高价值目标能够展示 Secret Protection 的安全价值。
技术多样性
您的试点应验证 Secret Protection 能否在您的编程语言和工具链中正常工作。
- 包括使用不同编程语言和框架的仓库。这可验证 Secret Protection 在整个代码库中的覆盖范围。
- 选择具有 CI/CD 流水线的仓库，以便提前识别潜在的部署影响。了解这些交互可防止在更大范围推行时出现意外。
组织代表性
成功的试点需要组织各部门的认同与支持。
- 从不同团队或业务单元选择仓库。多元化的反馈能够揭示单一团队无法发现的模式。
- 至少包含一个受领导层关注的仓库。高层可见性有助于保持试点动力，并促进未来的预算讨论。
初期应避免的仓库
并非所有仓库都适合作为试点候选。
- 低活跃或已归档的仓库：无法获得及时的工作流反馈。
- 实验性或个人仓库：这些仓库并不反映生产环境的模式。
- 拥有复杂自定义工具的仓库：不常见的工作流可能会使反馈变得复杂。
- 对变更容忍度为零的关键任务仓库：最好在验证解决方案之后再添加这些仓库。
按组织划分的试点规模
确定符合这些标准的仓库后，需要决定试点的规模。合适的试点规模应在收集足够反馈与避免团队负担过重之间取得平衡。
| 组织规模 | 仓库数量 | 建议 |
|---|---|---|
| 小型（开发者少于 100 人） | 3‑5 个仓库 | 从最关键的项目开始。 |
| 中型（开发者 100‑500 人） | 5‑10 个仓库 | 从不同团队中选择仓库，包含高活跃度和中等活跃度的混合。 |
| 大型（开发者 500 人以上） | 10‑20 个仓库 | 确保在组织内有广泛的代表性。可考虑分阶段、分波次添加仓库的方式。 |
启用试点前
请采取以下步骤，为您的试点奠定成功基础。
- 确认仓库所有者同意参与。不愿配合的团队会产生负面反馈，这并不反映真实的产品问题。
- 在每个试点团队中确定倡导者。倡导者负责解答问题并保持反馈的流动。
- 记录基线指标，如提交频率和贡献者数量。这些基线有助于衡量试点的影响。
延伸阅读
- 识别需要保护的密钥仓库 在 GitHub Advanced Security 产品指南中
后续步骤
既然您已选择试点仓库，请查看定价并配置 GitHub Secret Protection。参见定价与启用 GitHub Secret Protection。