保护持续集成(CI)/持续交付(CD)管道的6个优秀实践

 网络攻击者利用了持续集成(CI)/持续交付(CD))管道和开发工具中的弱点，因此需要提高开发基础设施的安全性。值得关注的是，无论环境多么安全，针对软件审计商Codecov公司供应链的网络攻击事件都在警告人们不要在持续集成(CI)/持续交付(CD)环境变量中存储机密数据。

[[412656]]

通过破坏数千名开发人员使用的Bash上传程序，针对Codecov公司的网络攻击者设法从客户环境中窃取凭据、密钥和API令牌，而在入侵两个月之后没有被发现，据报道，此次攻击还破坏了数百个受限制的客户网络。同样，对Jenkins、GitHub Actions和云原生容器化环境等自动化工具的攻击进一步促使企业探索和部署这些工具的有效防御措施。

以下是确保持续集成(CI)/持续交付(CD))管道保持安全的一些最佳实践。

1.停止在持续集成(CI)/持续交付(CD)环境中存储机密

对Codecov公司的供应链进行网络攻击取得成功背后的原因仍然是网络攻击者泄露的环境变量包含硬编码的秘密，其中包括密码、令牌和密钥。由于其中一些凭证让网络攻击者可以访问企业的私有GitHub存储库，因此这些私有存储库可能会发生进一步的数据泄露，其中包含机密数据。

尽管包括HashiCorp、Twilio、Rapid7和Monday.com在内的Codecov公司多个客户披露了供应链攻击的影响，但迄今为止曝光的最严重的数据泄露事件发生在日本电子商务巨头Mercari公司。在Codecov公司遭遇网络攻击之后，Mercari公司的客户、商户、业务伙伴、公司员工、承包商等组织泄露的总记录超过27000条。

诚然，这些网络攻击中的每一个都可能始于Codecov漏洞，而有些人质疑为什么将客户财务记录等个人身份信息(PII)存储在私有GitHub存储库中。

存储在持续集成(CI)/持续交付(CD)环境中的HashiCorp的GPG私钥也引起了类似的担忧。这是用于签署和验证HashiCorp发布的软件版本的密钥。在密钥被撤销之前，网络攻击者可能已经滥用密钥在恶意软件版本上伪造HashiCorp的签名。一位开发者在推特上写道，“为什么没有人谈论Vault的制造商HashiCorp将他们的签名密钥存储为ENV的事实?”

企业需要重新考虑哪些机密数据可以存储在持续集成(CI)/持续交付(CD)工具、环境变量和私有GitHub存储库中。如果应用程序需要将凭证或令牌存储在这些地方，最好将凭证存储到具有最低权限的帐户或资源中，这正是完成任务所必需的——通常称为最小权限原则。这样，即使机密数据确实在前所未有的网络攻击对外泄露，造成的损害也会得到控制。

2.审查自动拉取请求和计划任务

GitHub Actions等持续集成(CI)/持续交付(CD)自动化工具允许开发人员为其代码存储库设置计划任务，例如自动审查和处理传入的拉取请求。但是，如果向开源项目提出拉取请求的人员具有恶意的话，会发生什么?

2021年4月，GitHub Actions被网络攻击者滥用，他们向数百个存储库发出自动拉取请求，其目的是使用GitHub的基础设施挖掘加密货币。此次大规模网络攻击是在今年2月初报告GitHub Actions的“缺陷”之后发生的。

这些拉取请求可以滥用GitHub的服务器来挖掘加密货币或执行网络攻击者的恶意代码。如果项目所有者疏忽并合并这些拉取请求，他们现在已经将恶意代码引入到存储库和更广泛的软件供应链中。今年5月，GitLab报告称，网络攻击者滥用分配给新帐户的“空闲时间”(配额)，在其平台上实施了类似的加密货币挖矿攻击。

因为像GitHub Actions和GitLab这样的持续集成(CI)/持续交付(CD)自动化工具的本质是提供自动化关键任务的便利，所以网关安全成为一个挑战。在被威胁行为者滥用之后，原本可能是有意设计的功能很快就变成了安全漏洞。

GitHub公司最近发布了新功能，以防止加密攻击者滥用其Actions平台。GitHub公司产品经理Chris Patterson在一篇博客文章中说，“在任何Actions工作流程运行之前，拉取请求将需要具有写访问权限的存储库合作者的人工批准。当申请者打开拉取请求时，他们会看到一条消息，表明维护人员必须在运行之前批准他们的Actions工作流。”

行业领先的持续集成(CI)/持续交付(CD决方案和DevOps平台可以效仿GitHub，添加一些安全检查，以阻止恶意行为者大规模滥用其基础设施。

3.强化并定期审核云原生容器

没有什么比遵循标准最佳实践更为出色，例如确保容器被正确配置并针对常见攻击向量加强防范。这包括保护管道配置。

然而，简单的配置错误有时很难被工作人员发现。那么就会出现一个问题，企业的基于Docker的环境是否没有漏洞?这就是为什么定期对容器的弱点执行安全审计、扫描容器镜像和清单文件以发现常见的安全问题仍然很有帮助的原因。

建议采用可靠的云原生容器安全解决方案，将其大部分实现自动化。每年报告的大量安全漏洞使得人类几乎不可能跟踪它们。

此外，随着越来越多的企业采用Kubernetes框架和Docker容器来部署其应用程序，具有内置Web应用程序防火墙的容器安全解决方案可以及早检测和阻止可疑的网络流量。这有助于防止更大的危害，即使网络攻击者能够入侵容器并获得初始访问权限也可以阻止。

4.集成深度代码扫描，实现代码质量检查的自动化

在代码提交进入生产环境之前，采用工具来自动发现代码质量问题、安全漏洞以及诸如内存泄漏或竞争条件之类的错误，需要从一开始就保护持续集成(CI)/持续交付(CD)管道的有效策略。尽管其重点似乎主要是防止网络攻击，但无害的错误也可能产生大规模的影响。人们最近从Fastly 公司CDN在全球范围内的中断中看到了这一点，该中断使该公司在世界各地的主要站点脱机。

GitHub代码扫描器或Sonatype的Lift等解决方案无缝集成到企业现有的编码工作流程中，并免费为开发人员提供基本的保护措施。最终，企业的目标应该是支持其开发人员的工作，同时尽可能地防止在应用程序中引入错误或安全漏洞。这需要在开发团队和安全团队之间的配合。在这里，实时通知提醒开发人员在编写代码时可能出现的疏忽，可以节省开发人员的时间，并从一开始就保护持续集成(CI)/持续交付(CD)工作流程。

5.尽早修补最新的持续集成(CI)/持续交付(CD)工具漏洞

2021年3月，网络攻击者利用名为z0Miner的加密挖掘僵尸网络在易受攻击的Jenkins和ElasticSearch服务器上挖掘加密货币门罗币(XMR)。通过利用面向互联网的服务器中的远程代码执行(RCE)漏洞，网络攻击者试图攻击并接管自动化基础设施以进行他们的恶意活动。

正如去年媒体报道的那样，网络攻击者可以利用Jenkins服务器来迅速造成分布式拒绝服务(DDoS)。这是由UDP放大反射DoS漏洞引起的，这个漏洞名为CVE-2020-2100，它影响低于Jenkins v2.219的版本以及低于Jenkins LTS的2.204.1的版本。

一旦发现这些严重漏洞，立即针对这些严重漏洞进行修补对于确保持续集成(CI)/持续交付(CD)基础设施的安全性仍然至关重要。

6.在应用更新之前验证更新的完整性

采用最新的更新和补丁是合理的建议，但能确定收到的更新没有被篡改吗?在SolarWinds供应链遭到网络攻击之后，几十年来一直是安全专业人士的口头禅的“更新最新版本”的建议受到了挑战。

在SolarWinds的数据泄露事件中，对Orion IT产品进行的恶意更新使网络攻击者能够向下游的18000多个客户分发恶意代码。Passwordstate密码管理器的“就地升级功能”遭到破坏，以向Passwordstate用户分发恶意更新。因此，盲目采用更新补丁并不是一个好主意。

在Codecov公司的案例中，简单的完整性检查发现了长达两个月的数据泄露行为。一位客户注意到托管在服务器上的Bash上传器的校验和哈希值与Codecov的GitHub存储库中列出的合法校验之间存在差异，因此立即联系Codecov公司，该公司于是致力解决数据泄露的问题。

纵深防御方法可以保证任何更新、补丁和下载的完整性都得到验证，从而排除来自复杂供应链攻击的风险。