近期，攻击者利用CI/CD和开发工具中的漏洞进行攻击，对开发架构的安全性提出了新的要求。特别是Codecov供应链攻击是对任何在CI/CD环境中存储机密信息的人的警告——无论该环境看起来多么安全。通过入侵数千名开发人员使用的Bash上传组件，Codecov攻击者能够从客户环境中窃取凭证、密钥和API令牌，并且在两个月内未被发现。除此之外，数百个客户的网络也被成功攻击。类似的情况还有针对Jenkins、GitHubAction、云原生容器环境等自动化攻击的攻击，进一步让企业探索和部署针对这些工具的有效防御方法。保护CI/CD管道安全的六个技巧1.不要在CI/CD环境中存储机密信息Codecov供应链攻击之所以如此成功，是因为在攻击者设法溢出的环境变量中硬编码机密信息（包括密码），通过和关键。攻击者使用其中一些凭据来访问公司的私有GitHub存储库，从存储库中窃取的更多数据包括本应保密的数据。虽然包括HashCorp、Twilio、Rapid7和Monday.com在内的多个Codecov客户都披露了供应链攻击的影响，但迄今为止受影响最大的公司是日本电子商务巨头Mercari。超过27000条记录被泄露，包括客户的财务信息、产品信息、商业伙伴信息、公司员工信息、承包商信息和其他实体信息。毫无疑问，这些攻击是由Codecov漏洞引起的，但有人质疑为什么客户财务记录等个人身份信息存储在私人GitHub存储库中。HashiCorp在CI/CD环境中存储GPG私钥时也出现了类似的问题。该密钥用于签署和验证HashiCorp发布的软件。在密钥被撤销之前，攻击者可以滥用密钥来伪造HashiCorp签名的恶意软件版本。一位开发人员甚至表示：“为什么没有人提到Vault的供应商HashiCorp甚至将他们的签名密钥保留为ENV的事实？天哪，这让我对自己的生活感觉好多了。”组织需要重新考虑哪些秘密可以存储在CI/CD工具集、环境变量和私有GitHub存储库中。如果应用程序需要在这些位置存储凭据或令牌，最好将凭据存储在需要最少权限的帐户或资源中。这样，即使相关机密信息在意外攻击中泄露，也可以遏制损失。2.仔细检查自动拉取请求和计划任务CI/CD自动化工具（如GitHubActions）允许开发人员为其代码库创建计划任务，例如自动拒绝和处理传入的拉取请求。但是，如果贡献者恶意发起开源项目的拉取请求怎么办？2021年4月，GitHubActions被攻击者滥用，他们向数百个库发起拉取请求，试图使用GitHub的基础设施进行挖矿。大规模攻击是在2月份报告GitHubActions漏洞之后发生的。即使是最低限度，这些拉取请求也可能滥用GitHub的服务器进行挖掘或执行攻击者的恶意代码。如果项目所有者无意中合并了这些拉取请求，他们可能会将这种恶意代码引入他们自己的库以及更广泛的供应链中。5月，GitLab报告称在他们的平台上发现了类似的挖矿攻击，攻击者在新帐户上滥用空闲时间。由于GitHubActions和GitLab等CI/CD自动化工具的本质是简化关键任务的自动化，因此“把关”成为一个很大的挑战。精心设计的功能很快就会成为安全风险，被恶意行为者滥用。GitHub最近宣布增加一项新功能，以打击滥用其Actions平台进行挖掘的攻击者：“来自首次贡献者的拉取请求需要图书馆合作者手动通过，然后才能执行任何Actions工作流程。当首次贡献者打开拉取时请求，他们会看到一条消息，表明维护者必须先完成他们的工作流程才能执行，”GitHub产品经理ChrisPatterson在一篇博文中说。CI/CD解决方案和DevOps平台的领先供应商可以效仿GitHub的做法，添加一些安全检查来检测恶意行为者对其基础设施的大规模滥用。3.强化并定期审计云原生容器没有什么比标准最佳实践更重要的了，比如确保业务容器得到正确配置并针对常见的攻击向量进行强化。这还包括确保正确配置管道。但是，一些小的配置错误有时很难发现。那么问题来了，基于Docker的环境是否免疫漏洞？这就是为什么您需要对容器进行安全审计以发现漏洞。扫描容器镜像和清单文件以发现常见的安全问题仍然非常有帮助。建议投资一个可以自动化这些事情的可靠的云原生容器安全解决方案。每年公布的安全威胁数量庞大，几乎不可能手动追踪。此外，随着企业部署Kubernetes框架和Docker容器来部署应用，WAF内置的容器安全解决方案可以及早发现并阻止可疑的网络流量。这可以防止更大的漏洞，即使攻击者能够渗透容器并获得初始访问权限。4.集成深度代码扫描，自动检测代码质量在代码进入业务环境前，自动检测代码质量、安全隐患、内存泄漏，从源头有效保护CI/CD流水线。虽然重点似乎主要放在防御网络攻击上，但某些看似无害的漏洞也可能产生大规模影响——例如最近导致全球几个主要站点瘫痪的Fastly事件。GitHub代码扫描或Sonatype的Lift等解决方案可以与现有代码工作流无缝集成，为开发人员免费提供基本保护。组织的最终目标应该是支持开发人员尽其所能，同时努力防止应用程序中出现漏洞或安全风险。但是，这是在开发团队和安全团队之间尽可能减少摩擦的情况下完成的。因此，在开发人员编写代码时实时提醒他们可以节省每个人的时间，同时确保CI/CD管道的整体工作流程从一开始就是安全的。5.尽早修补最新的CI/CD工具漏洞2021年3月，攻击者使用名为z0Miner的挖矿僵尸网络在易受攻击的Jenkins和ElasticSearch服务器上挖矿门罗币。通过针对暴露在Internet上的服务器利用RCE漏洞，攻击者能够感染并接管自动化基础设施以执行他们的恶意操作。同样，在去年，Jenkins服务将被攻击者利用来快速实施DDoS攻击。这是基于可导致UDP反射放大攻击的DoS漏洞。漏洞编号为CVE-2020-2100，将分别影响Jenkinsv2.219和JenkinsLTS2.204.1以下版本。在披露高严重性漏洞时尽快修补自动化工具和管道仍然是保护CI/CD基础设施的关键。6.在应用更新之前验证更新的完整性。应用最新的更新和补丁是个好主意，但是如何确保您收到的更新未被篡改？在SolarWinds供应链攻击事件发生后，这一说法开始受到质疑。在SolarWinds事件中，Orian的IT产品被恶意更新，让攻击者通过它们向18000个客户分发恶意代码。同样，Passwordstate的密码管理功能遭到破坏，向其用户传播了恶意更新。因此，现在盲目地进行产品更新是一个糟糕的主意。在Codecov的案例中，一次简单的健全性检查发现了两个月的违规行为。一位客户在注意到服务器上的Bash上传器校验和与GitHub存储库上的Codecov合法校验和不匹配后通知了Codecov。Codecov随后解决了这个问题。因此，需要对任何更新、补丁和下载进行完整性验证的纵深防御机制排除了复杂供应链攻击的可能性。评论CI/CD流水线安全，不仅需要拓宽攻击面的防御范围，还需要一系列补充的安全意识和规范。从技术角度来看，由于CI/CD本身强大的自动化属性，对防护能力的自动化水平有了新的要求——安全不能以牺牲业务为代价。同时，开源软件带来的供应链攻击也意味着代码也需要被赋予“零信任”。并非所有来自可靠来源的代码都一定是安全的。
