这是一个关于“按预期工作”的分支保护绕过的故事，允许受保护的凭证泄露。2024 年 2 月 2 日通过 HackerOne 向 GitHub 报告了此安全漏洞，很快被关闭为“按预期工作”。为强化 Chainguard 的安全态势，作者在探索利用控制将 GitHub 视为生产环境的方法时发现了此漏洞。

通过实验测试发现，即使使用通配符分支保护规则*，已存在的分支仍显示为受保护，但新创建的分支不受限制。而 GitHub 的环境功能可限制某些秘密对特定分支或受保护分支的可见性，作者据此创建了一个工作流来泄露在mattmoor-testing环境中创建的秘密NOT_A_SECRET，此工作流成功运行。

在之前的开源项目中，通常会创建长期存在的发布分支并进行保护，若要让发布工作流访问敏感秘密，就会出现安全漏洞。作者起初认为这种攻击的价值不大，但深入思考后发现，通过一些方式可以隐藏分支和工作流，从而规避检测。

作者最初的分支保护配置存在遗漏，现有分支保护显示任何人都可以创建分支，而新分支保护仅管理员可创建。

对于 GitHub 分支保护中的脆弱行为，给出了以下最佳实践：

• 偏好使用存储库规则集（新）而非分支保护（旧），若管理员未明确列入绕过列表，规则集可阻止他们。
• 仅在绝对必要时使用通配符在分支保护中。
• 使用通配符分支保护时，始终限制谁可以创建匹配的分支（例如仅管理员可创建发布分支）。
• 仅在绝对必要时在环境（而非具体分支）中信任分支保护。
• 若发现自己进行了上述操作，考虑要求管理员批准环境访问。
• 更喜欢通过 OIDC 联合使用云服务提供商的秘密存储而非 GitHub 的内置秘密存储，并确保联合规则尽可能严格。

GitHub 将此问题标记为按预期工作，但这促使作者提醒大家注意此类脆弱行为。若想了解 Chainguard 自身产品安全和深度防御原则的内部实践，可访问其信任中心或了解其 Octo STS 项目这里。