图片Github Dependabot 是一个github的工具，他可以帮助你检测你的repo，在您的项目所依赖的上游软件包或应用程序发布新版本后，它会在您的 GitHub 仓库自动创建一个 PR 来更新依赖文件，并说明依赖更新内容，用户自己选择是否 merge 该 PR， 并且做一些工作保证你repo的安全性。
你听说过Dependabot吗？如果没有，只要问问你周围的任何开发人员，他们可能会对它如何彻底改变检查和更新软件项目中过时的依赖项的繁琐任务赞不绝口。
Dependabot 不仅会为您完成检查，还会提供修改建议，只需单击一下即可完成修改。尽管 Dependabot 仅限于 GitHub 托管的项目，但它为持续提供商提供类似功能设定了新标准。这种“管理”任务的自动化已成为一种常态，使开发人员能够比以往更快地集成和部署他们的工作。持续集成和部署工作流已成为软件工程的基石，将DevOps运动推向了行业的前沿。
但安全公司Checkmarx最近的一份公告揭示了一个令人担忧的事件。攻击者最近试图通过冒充该工具来利用与 Dependabot 相关的信任。通过模仿 Dependabot 提出的建议（以拉取请求的形式），这些攻击者试图欺骗开发人员接受更改，让他们忽视了可能存在安全威胁。
虽然 Dependabot 体现了软件维护任务自动化的进步，但这一事件也凸显了 CI/CD 管道中存在的更广泛的复杂性和安全隐患。这些管道是非常重要的，它将软件开发工具和平台与软件创建和部署的内部流程联系起来。了解这种联系是解决我们面临的安全挑战的关键。
CI/CD 管道：将外部世界与内部世界连接起来
持续集成 （CI） 和部署 （CD） 工作流彻底改变了软件开发流程，使开发人员能够无缝合并其工作并将其部署到生产环境中。这些工作流程确保代码经过自动安全扫描、严格测试并遵守编码标准，从而实现更高效、更可靠的开发过程。它们已成为创新的催化剂，使团队能够专注于构建和增强他们的产品，同时保证质量和安全性。
为了说明这个概念，想象一下建造一个拼图。CI 充当问题检查器，在继续前进之前验证每个新拼图是否正确合适。另一方面，CD 更进一步，自动将每个经过验证的拼图放入最终拼图中，无需等待整个拼图完成。这种加速的过程可以加快功能交付速度，并最终加快整个产品开发时间。
但是，这些 CI/CD 工作流也会将外部环境与内部开发环境连接起来，从而产生潜在风险。例如，考虑开发人员通过 CI/CD 管道将第三方库集成到其项目中的场景。如果开发人员未能彻底审查库，或者管道缺乏适当的安全检查，恶意代码可能会在不知不觉中合并到项目中，从而损害其完整性。近年来，诸如域名仿冒和依赖混淆等攻击有所增加，这些攻击旨在利用对开源软件的依赖来谋取经济利益。
自动化集成工作流的兴起通过降低成本和增加攻击的潜在收益，改变了攻击者的经济状况。攻击者可以攻击流行的中心软件包存储库，例如 PyPi，它托管数千个软件包，每天提供数百万次下载。庞大的运营规模使得攻击者可以偶尔碰碰运气，即使成功的机会很小。
另一个示例是在 CI/CD 管道中使用外部 API。开发人员通常需要为这些 API 提供有效的凭据，以便实现自动部署或与外部服务集成。但是，如果这些凭据未得到安全管理，或者它们无意中暴露在日志或项目中，则攻击者可能会利用它们来获得对敏感资源的未经授权的访问或操纵管道的行为。
CI/CD 泄露通常源于最初的密钥泄露或开发人员成为特定攻击的目标。然而，与其将这些违规行为归咎于开发人员，不如认识到问题在于这些管道固有的安全性。这凸显了一个更大的问题：通常情况下，CI/CD 管道并非是安全的。
问题：通常情况下，CI/CD 管道并不安全
尽管实施安全设计工作流的想法正变得越来越流行，但 CI/CD 平台仍有很长的路要走。GitHub Actions、GitLab CI/CD 和 CircleCI 等平台最初在设计时考虑到了灵活性，通常优先考虑易用性而不是强大的安全措施。因此，缺乏默认保护措施来防止潜在问题的出现。
一个明显的例子是，开发人员暴露密码等敏感信息是多么容易。开发人员通常在运行时引入机密，并依赖于在 CI 提供程序本身中存储机密的能力。虽然这种做法本身不是问题，但它至少引发了两个安全问题：首先，托管机密的 CI 提供商成为敏感信息的保险库，并成为攻击者的有吸引力的目标。就在 2023 年初，CircleCI 的系统遭到破坏，迫使用户在公司系统遭到破坏后更换所有的密钥信息。
其次，机密经常会通过 CI/CD 管道本身泄露并被忽视。例如，如果将密钥与另一个字符串（例如 URL）连接起来，然后记录下来，则 CI 检查机制将不起作用，硬编码的敏感信息也是如此，结果就是 CI 日志经常暴露明文密码。同样，在软件工件中发现硬编码的密码并不少见，这是持续集成工作流配置错误的结果。
CI/CD 提供商已经采取措施增强安全性，例如 GitHub Dependabot 安全检查。但大多数时候，宽松的默认值和复杂的权限模型仍然是很大的限制。为了保护 CI/CD 管道并防止代码泄露，开发人员应采取其他措施来强化其管道免受攻击。一个关键方面是确保保护开发人员的凭据。另一种方法是通过警报触发器采取主动的安全方法。
保护 CI/CD 和软件供应链
为了有效地保护 CI/CD 管道，必须将它们视为高优先级、潜在的外部连接环境。关键是最佳实践的组合：
- 限制访问并最小化权限：根据需要而不是便利性授予访问权限。对所有DevOps团队成员的广泛访问增加了帐户被盗的风险，从而为攻击者提供了广泛的系统访问权限。限制对关键控制、配置或敏感数据的访问。
- 强制实施多重身份验证 （MFA）：至关重要的是，始终使用多重身份验证 （MFA） 登录 CI/CD 平台。MFA 增加了一个重要的安全层，使未经授权的用户即使凭据泄露也更难获得访问权限。
- 利用 OpenID Connect （OIDC）：使用 OIDC 将工作负载安全地连接到外部系统，例如用于部署。该协议为身份验证和跨域身份验证提供了一个强大的框架，这在分布式和互连环境中至关重要。
- 使用预先审查的软件依赖项：为开发人员提供安全的、预先审查的软件依赖项非常重要。这种做法可以保证供应链的完整性，并使开发人员不必验证每个包的代码。这确保了供应链的完整性，减轻了开发人员单独验证每个包代码的负担。
- 安全运行时机密：在 CI/CD 平台中安全地存储 API 密钥和凭据等机密需要强大的安全措施，例如强制实施的 MFA 和基于角色的访问控制 （RBAC）。然而，这些并不是万无一失的。机密可能还是会泄漏，额外的安全层（如严格的凭据卫生和对内部和外部威胁的警惕监控）对于全面保护是必要的。
- 实施高级防御系统：将警报系统整合到安全框架中。虽然蜜罐有效但难以扩展，但蜜罐提供了一种可扩展、易于实施的替代方案。这些令牌只需最少的设置，就可以显著增强各种规模的公司跨各种平台（如 SCM 系统、CI/CD 管道和软件工件注册表）的安全性。
- 可利用企业级解决方案：GitGuardian 平台等解决方案提供单一管理平台来监控机密泄露、基础架构即代码错误配置和蜜标触发器等事件，使组织能够大规模检测、修复和预防 CI/CD 事件。这大大减轻了潜在数据泄露的影响。
通过结合这些策略，组织可以全面保护其 CI/CD 管道和软件供应链，适应不断变化的威胁并维护强大的安全协议。
