最近，攻击者在利用CI/CD以及开发工具当中的漏洞进行攻击，导致对开发架构的安全性有了新的要求。Codecov供应链攻击尤其对每一个在CI/CD环境中储存机密信息的人发出了警告——无论这个环境看上去有多安全。
通过破解一个被几千名开发者使用的Bash上传组件，Codecov攻击者能够从客户环境中窃取凭证、密钥、以及API token，还能保持两个月中不被发现。在此之上，还成功攻击了数百个客户的网络。类似的情况还有针对像Jenkins、GitHub Action和云原生容器环境等自动化攻击的攻击，这些都进一步让企业去针对这些工具探索并部署有效的防御手段。
六条保护CI/CD管道的建议
1. 不要在CI/CD环境中储存机密信息
Codecov供应链攻击获得极大成功的原因，在于被攻击者设法溢出的环境变量里存在硬编码的机密信息，包括口令、通证和密钥。攻击者利用其中其中的一些凭证接入了企业的私有GitHub库，进一步从库中窃取的数据就包含了应该保密的数据。
尽管说包括HashCorp、Twilio、Rapid7和Monday.com等Codecov的多个客户公开了供应链攻击的影响，到现在为止受影响最大的公司是日本的电商巨头Mercari。超过2.7万条记录被泄露，包括客户的财务信息、商品信息、商业伙伴信息、公司员工信息、承包商信息等多个实体信息。
毫无疑问，这些攻击都是由Codecov的泄露引起的，但也有些人质疑为何像客户财务记录这类的个人识别信息都会储存在私有的GitHub库里。
类似问题也发生在HashiCorp将GPG私钥储存在CI/CD环境当中。该密钥用于签署和验证由HashiCorp发布的软件。在密钥被废除以前，攻击者可以滥用该密钥来伪造一个带有HashiCorp签名的恶意软件发布。一个开发人员甚至表示：“为什么没有人提到Vault的供应商HashiCorp，竟然将他们的签名密钥作为ENV保存的事实?天啊，这让我对自己的人生感到好多了。”
组织需要重新思考哪些秘密信息能够储存在CI/CD工具集、环境变量与私有GitHub库中。如果一个应用需要将凭证或者通证储存到这些位置，最好将凭证存到一个权限要求最小的账户或者资源中。那样，即使相关秘密信息在不可预期的攻击中被泄露了，损害也能被遏制。
2. 仔细检查自动化pull请求与计划任务
像GitHub Actions这类的CI/CD自动化工具能让开发者为他们的代码库建立计划任务，比如自动化否决和处理收到的pull请求。但是，如果一个贡献者对一个有恶意意图的开源项目发起pull请求，又会如何呢?
2021年四月，GitHub Actions遭到攻击者滥用，对几百个库发起pull请求，试图用GitHub的基础设施进行挖矿。该大规模攻击在2月份GitHub Actions的漏洞被报告后发生。
哪怕是最低限度的情况，这些pull请求会滥用GitHub的服务器进行挖矿，或者执行攻击者的恶意代码。如果项目所有者疏忽大意地合并了这些pull请求，就会将这些恶意代码引入自己的库以及更广泛的供应链。五月，GitLab报告在他们的平台发现了一个类似的挖矿攻击，攻击者滥用了新账户的免费时间。
由于像GitHub Actions和GitLab这种CI/CD自动化工具的本质是简化关键任务的自动化能力，“守门”就成了一大挑战。原本设计好的功能可能很快反而成为了一个安全隐患，被恶意人员所滥用。
GitHub最近宣布添加了新功能，以对抗滥用其Actions平台进行挖矿的攻击者：“从首次贡献者发起的pull请求在任何Actions工作流能执行前，都需要库合作者手动通过。当一个首次贡献者打开一个pull请求，他们会看见一条信息告知在他们的工作流执行前，必须由一个维护者通过这个工作流。” GitHub的产品经理Chris Patterson在博客中提到。
CI/CD解决方案和DevOps平台的领军厂商可以追随GitHub的方式，增加一些安全检查，发现他们基础设施中被恶意人员大规模滥用的行为。
3. 加强并周期性审计云原生容器
没有什么比确保业务容器恰当配置并针对通常攻击载体加固等标准最佳实践更重要的了，这还包括了保证管道配置正确。
但是，一些细小的配置错误有时候很难被人发现。然后问题就来了，基于Docker的环境是否会不受漏洞威胁呢?这就是为什么需要经常对自己的容器做安全审计发现脆弱性的原因，扫描容器映象和清单文件以发现常见的安全问题依然很有帮助。
建议可以投资可以自动化处理这些事情的可靠云原生容器安全解决方案。每年公布的大量安全隐患几乎不可能全部由人工进行追踪。
另外，随着企业启用Kubernetes框架以及Docker容器来部署他们的应用，WAF内置的容器安全解决方案可以早期检测并阻断可疑的网络流量。这就可以防止更大的失陷事件，即使攻击者能够渗透入容器并获取最初的接入权限。
4. 集成深度代码扫描以自动化检查代码质量
在代码进入业务环境之前，就被自动化检查代码质量、安全隐患和内存漏出这类的漏洞，就可以有效地从头开始保护CI/CD管道。尽管说关注点看上去主要针对网络攻击的防御，但是某些看上去无害的漏洞同样产生大规模影响——比如最近的搞垮全球多个主要站点的Fastly事件。
GitHub代码扫描或者Sonatype的Lift之类的解决方案能够和现有的代码工作流无缝集成，在对开发者没有任何成本的情况下提供基础的防护。组织最终的目的应该是支援开发者做出他们能做的最好的工作，同时尽量防止应用中漏洞或者安全隐患的出现。不过，这同时还要让开发团队和安全团队之间的摩擦尽可能少。因此，实时在开发者写代码的时候对其告警，能够省下所有人的时间，同时从一开始就确保CI/CD管道整体的工作流安全。
5. 尽早对最新的CI/CD工具漏洞进行补丁修复
2021年三月，攻击者利用名为z0Miner的挖矿僵尸网络在有漏洞的Jenkins和ElasticSearch服务器上进行门罗币挖矿。通过对暴露在互联网的服务器利用RCE漏洞，攻击者得以感染并接管自动化基础设施，实施他们的恶意行为。
同样，在去年，Jenkins服务会被攻击者利用，快速实现DDoS攻击。这是基于一个能引起UDP反射放大攻击的DoS漏洞，漏洞编号为CVE-2020-2100，分别会影响Jenkins v2.219和Jenkins LTS 2.204.1以下的版本。
尽快在高危漏洞被披露的时候给自动化工具和管道打上补丁，这依然是确保CI/CD基础设施安全的关键。
6. 在进行更新前验证其完整性
应用最新的更新和补丁是一个好主意，但是如何确保收到的更新并未被篡改?“升级到最新版本”这个被安全人员用了十几年的铭言在SolarWinds供应链攻击后开始遭到质疑。
在SolarWinds事件中，Orian的IT产品遭到恶意更新，使得攻击者通过他们将恶意代码下发到1.8万个客户中。同样的，Passwordstate的口令管理功能失陷，将恶意更新传播给了他们的用户。因此，现在盲目地进行产品更新是一个糟糕的主意。
在Codecov的案例中，一个简单的完整性检查就能发现为期两个月的泄露事件。一个客户注意到了在服务器上Bash Uploader的哈希校检和与Codecov在GitHub库上的合法校检和不符，从而通知了Codecov。Codecov随后修复了该问题。
因此，一个深度的防御机制，要求对任何更新、补丁和下载都进行完整性验证，从而将复杂的供应链攻击可能排除。
点评
CI/CD管道安全不仅仅需要拓宽对攻击面的防御范围，还需要一系列的安全意识与规范的补充。而从技术层面，由于CI/CD本身带有极强的自动化属性，对于防护能力的自动化水平也有了新的要求——安全不能以过于牺牲业务为代价而存在。同时，开源软件带来的供应链攻击也意味着代码也需要赋予“零信任”，并非来自可靠来源的代码都必然是安全的。
