软件供应链的风险之一是秘密泄露。软件供应链中到处都是秘密；开发人员和 CI\CD 管道需要使用机密来访问 SCM、管道、工件注册表、云环境和外部服务。当秘密无处不在时，秘密泄露只是时间问题。
这种风险已得到很好的识别，许多软件供应链框架通过要求秘密扫描和秘密自我过期来解决该风险。
那么，作为一名安全从业者，如果设置了这些护栏，可能会出现什么问题呢？
本周，在研究秘密扫描工具时，我发现了一个答案。这个答案很简单：由于秘密扫描器搜索秘密模式，因此当秘密格式发生变化时，检测可能会失败。这正是 GitHub 推出新安全功能时所发生的情况 – 细粒度标记。这个测试版功能是 GitHub 降低机密泄露风险的方法之一；限制个人访问令牌的权限还可以限制这些秘密被泄露的风险。
事实证明，新令牌的格式有点不同，而旧令牌的格式类似于：
ghp_123456789012345678901234567890123456
新的令牌格式如下：
github_pat_123456789012345678901234567890123456789012345678901234567890…
秘密的前缀和长度都不同。
事实上，一些秘密扫描仪无法检测到新格式；
为了进行实验，我创建了一个带有 Dockerfile 的存储库，其中包含秘密和运行 Trivy 操作的工作流程。这是 Dockerfile 在实验开始时的样子：
以下是 GitHub Secret Scanner 的快照，它检测新格式化的机密：
正如我们所看到的，GitHub 的秘密扫描器检测到了秘密，但代码扫描部分中没有出现警报。
为了验证工具设置是否正确，我现在将向 Dockerfile 添加一个经典密钥（见下文）并再次运行扫描。现在我们收到代码扫描警报（仅针对经典秘密！）
另一方面，Github 的扫描仪现在检测到两个秘密：
我已经为 Trivy 提出了安全问题； Trivy 的团队回应称，这不是漏洞，也不是安全问题。剩下要做的就是提出一个问题。
这个实验引起了很多关注；
- 为什么 GitHub 用户会怀疑令牌格式会因新功能而被修改？
- 鉴于秘密应该看起来像随机字符串，为什么 GitHub 用户还要关心秘密的格式呢？
- GitHub 是否应该负责向其客户通报此类更改？
- 这个秘密检测失败是 GitHub 细粒度秘密的漏洞，还是 Trivy 的漏洞，或者，正如 Aqua Security 所认为的那样，根本不是一个漏洞？
- Trivy 背后的公司 Aqua Security 是否应该负责更新它？
- 由于 Trivy 是一个开源项目，按原样提供，如果机密从 Trivy 保护的管道中泄露，任何人都会承担责任吗？会是谁呢？ GitHub？水族安全？ Trivy 用户？
- 关于信任为保护软件供应链而安装的安全工具，这个实验告诉我们什么？
我将保留这些问题。
不过，有一件事是明确的：保护软件供应链非常复杂，我们需要一个高度专业的社区才能持久地成功完成这项任务。
这篇文章是由 Avi Waxman，Scribe Security 实习生
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
