盘点CI/CD管道安全的六种优秀实践

安全 应用安全
最近的网络攻击利用了持续集成/持续交付(CI/CD)管道和开发人员工具中的漏洞,这说明了提高开发人员基础设施的安全性迫在眉睫。

CI/CD是应用程序开发周期的重要组成部分。然而,犯罪分子正在利用CI(持续集成)/CD(持续交付)管道中的漏洞,窃取敏感信息,挖掘加密货币,并交付恶意代码。

最近的网络攻击利用了持续集成/持续交付(CI/CD)管道和开发人员工具中的漏洞,这说明了提高开发人员基础设施的安全性迫在眉睫。最典型的案例则是Codecov供应链攻击,这也提醒了用户,无论环境多么安全都不要在CI/CD环境变量中存储私密信息。

Codecov攻击者入侵了数千名开发人员使用的Bash上传器,成功地从客户环境中窃取了凭证、密钥和API令牌,且隐藏了两个月,一直未被发现,据说还攻破了数百个受限的客户网络。同样,对自动化工具(如Jenkins、GitHub Actions和云原生容器环境)的攻击也进一步促使企业探索和部署对这些工具的有效防御措施。

以下是确保CI/CD管道安全的一些优秀实践。

一、请不要在CI/CD环境中存储敏感信息

Codecov供应链攻击之所以能成功,背后的原因在于攻击者渗出的环境变量包含硬编码的敏感信息,包括密码、令牌和钥匙。由于其中一些凭证使攻击者能够访问公司的私人GitHub存储库,因此可以从这些包含本应保密数据的私人存储库中进一步渗出数据。

尽管包括HashiCorp、Twilio、Rapid7和Monday.com在内的多个Codecov客户披露了供应链攻击带来的影响,但迄今为止影响最为深远的数据泄露还是在日本电商巨头Mercari。在Codecov攻击之后,与Mercari客户的财务、商户、商业伙伴、公司员工、承包商和各种实体有关的共27000多条记录泄露给了未经授权的外部攻击者。

尽管这些攻击可能都是从Codecov漏洞开始的,但一些人也质疑了为什么客户财务记录等个人身份信息(PII)会被存储在私人GitHub存储库中。

对于HashiCorp存储在CI/CD环境中的GPG私钥,人们也提出了类似的担忧。这是由HashiCorp发布的用于签署和验证软件版本的密钥。在该密钥被撤销之前,攻击者可以滥用该密钥来伪造HashiCorp在恶意软件发布上的签名。一位开发者在推特上说:"为什么没有人谈论Vault的制造商HashiCorp将他们的签名密钥存储为ENV这一问题?"

企业需要重新思考哪些信息可以存储在CI/CD工具、环境变量和私人GitHub存储库中。如果一个应用程序需要将凭证或令牌存储在这些地方,最好是将凭证存储在具有最低权限的账户或资源中,只是完成任务的必要条件,通常被称为最小权限原则。这样,即使私密信息在一次前所未有的攻击中被暴露,也能够控制损失。

二、审查自动拉取请求和计划任务

像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在一篇博文中说:"当首次贡献者打开拉取请求时,他们会看到一条信息,即维护者必须批准他们的行动工作流才能运行。

领先的CI/CD解决方案和DevOps平台可以效仿GitHub的做法,增加一些安全检查,以阻止恶意行为者大规模滥用其基础设施。

三、加强并定期审计云原生容器

实践出真知,标准的最佳实践具有很大的参考意义。比如确保生产容器配置正确,并对常见的攻击载体进行加固,包括保护管道配置。

然而,简单的错误配置有时很难被发现。那么问题来了,基于Docker的环境是否有漏洞?所以,需要定期对容器进行安全审计,以发现弱点,扫描容器镜像和清单文件,以发现常见的安全问题,这些措施仍然是很有帮助的。

投资于可靠的云原生容器安全解决方案也是明智之举,它可以自动完成大部分工作。每年都报告了大量的安全漏洞,并且难以被人发现。

此外,随着公司采用Kubernetes框架和Docker容器来部署他们的应用程序,具有内置Web应用防火墙的容器安全解决方案可以在早期检测和阻止可疑的网络流量。这可以防止较大的损害,即使攻击者能够穿透容器并获得初始访问。

四、集成深度代码扫描以自动进行代码质量检查

在代码正式提交之前,需要自动化工具来发现代码质量问题、安全漏洞和内存泄漏或竞赛条件等错误,这可以从一开始就确保CI/CD管道安全的有效策略。虽然重点主要放在防止网络攻击上,但微小的错误也同样可能产生大规模的影响。比如,Fastly的全球故障使世界各地的主要网站都下线了。

像GitHub代码扫描器或Sonatype的Lift这样的解决方案可以无缝地集成到现有的编码工作流程中,并为开发者提供基本的保障。归根结底,一个组织的目标应该是支持其开发人员做好工作,同时尽可能地防止在应用程序中引入错误或安全漏洞。这需要开发和安全团队之间的相互契合。在开发人员编码时提醒他们可能出现的疏忽,实时通知可以节省每个人的时间,并从一开始就确保整个CI/CD工作流程。

五、尽早对最新的CI/CD工具漏洞打补丁

2021年3月,攻击者利用一个名为z0Miner的加密挖矿僵尸网络,在有漏洞的Jenkins和ElasticSearch服务器上开采Monero(XMR)加密货币。通过利用互联网服务器中的远程代码执行(RCE)漏洞,攻击者试图感染和接管自动化基础设施,以进行他们的犯罪活动。

无独有偶,去年报告了攻击者利用Jenkins服务器开展造成分布式拒绝服务(DDoS)攻击。事件背后是因为一个UDP放大反射DoS攻击漏洞,被追踪为CVE-2020-2100,它影响到Jenkins v2.219以下的版本,以及Jenkins LTS 2.204.1以下的版本。

一旦发现这些严重的漏洞,立即对自动化工具和管道进行修补,这对于确保CI/CD基础设施的安全至关重要。

六、在应用更新之前验证其完整性

应用最新的更新和补丁听起来是合理举措,但更新是否又被篡改这似乎很难确定?几十年来,"更新到最新版本 "的建议一直是安全专家的口头禅,但在SolarWinds供应链攻击事件后,这一建议受到了挑战。

在SolarWinds事件中,对Orion IT产品的恶意更新使攻击者能够向下游的18000多名客户分发恶意代码。然而,Passwordstate密码管理器的 "本地升级功能 "再次被入侵,向Passwordstate用户分发恶意更新。因此,盲目地应用产品更新未必是一件好事。

在Codecov的案例中,一个简单的完整性检查发现了长达两个月的漏洞。一位客户注意到托管在服务器上的Bash Uploader的校验和(哈希值)与Codecov的GitHub仓库中列出的合法校验和之间存在差异,立即与Codecov联系,随后他们修复了这一问题。

因此,深度防御的方法要求对任何更新、补丁和下载的完整性进行验证,以便排除来自复杂的供应链攻击的风险。

参考链接:Securing CI/CD pipelines: 6 best practices 

 

责任编辑:赵宁宁 来源: FreeBuf
相关推荐

2021-09-26 09:26:46

开发安全CICD管道

2022-05-19 09:00:00

安全CI/CD工具

2021-05-18 08:00:00

Kubernetes容器进程

2019-07-25 10:31:55

AWSDevOps架构

2023-01-16 08:00:00

2021-07-23 10:17:17

网络攻击存储供应链

2022-09-05 15:12:34

数据库GitHub开发

2022-02-22 09:00:00

软件开发CI/CD 管道工具

2023-01-30 15:55:08

2023-05-04 16:03:50

KubernetesCI/CD集成

2021-07-02 16:30:01

CICDDevOps

2020-12-15 16:13:21

DevSecOpsCICD

2023-02-19 15:28:39

CI/CD 管道集成开发

2023-07-13 23:35:06

系统Linux

2020-11-17 11:18:31

Docker

2023-08-26 20:51:25

Python函数代码

2016-07-08 15:02:47

云计算

2009-10-29 16:52:23

2020-07-31 11:12:39

安全威胁网络攻击网络安全

2018-08-24 09:00:00

DevOps持续集成连续部署
点赞
收藏

51CTO技术栈公众号