作者丨Ariadne Conill
编译丨诺亚
自从Linus Torvalds创建Linux内核并发布其第一个版本以来,已经过去了30多年。当我们回顾自由软件发展早期时,当然应该给予Debian,FreeBSD和其他开源的自由/开源软件发行版大量荣誉,它们提供了稳定性保证,预先打包了通用的实用程序,并且使用户不必手动安装所有内容。
但是,现在的世界与90年代大不相同,虽然确实有很多发行版在安全方面做得很好,但在许多方面,现代软件消费模式,比如使用Docker构建软件和使用curl-pipe-bash命令安装软件,已经给软件供应链带来了安全挑战。通过这些变通办法,世界在很大程度上已经摆脱了传统的自由和开放源码软件分发模式,同时失去了通过精心策划的分发获得的软件的优势,例如分发提供的漏洞管理。
让我们来看看软件发行版的演变,现代开发人员的需求已经超出了以牺牲安全性为代价的一些传统智慧的领域,并仔细看看 Wolfi——一个围绕模块化和可重新定位性构建的滚动发布 Linux 发行版,它提供了用于满足现代用户供应链安全需求的原语,同时还提供多个应用程序版本流的稳定性。
今天的软件消费看起来有很大的不同
在传统的软件消费模型中,系统管理员选择发行版,将它们安装在虚拟机中,并直接从这些发行版获取尽可能多的软件。开发人员如果需要这些发行版之外的额外内容,就必须提交申请,等待IT部门为他们的请求提供服务。
容器和微服务立即颠覆了这种软件消费模式,让开发人员能够完全控制软件的构建、分发和获取方式。
同时,FOSS的爆炸式增长产生了一种影响,即大多数开发人员所追求的软件不再得到世界上最著名的发行版的支持。从NPM到Maven再到PyPI,世界上最受欢迎的语言和库发布的软件包和版本比发行版所能跟的要多几个数量级。
其结果是,开发人员现在在他们的发行版之外安装程序。好处是能够获得最新和最好的软件。但缺点是,这一切都发生在直接从发行版安装软件时内置的管理和信任的背景之外。
当你在发行版之外安装软件时,你从谁那里获取软件之间存在巨大的语义差异。手动安装软件时,开发人员可以获得最新的软件包(和版本),而不必等待发行版正式支持它们的缓慢步伐。然而,随着FOSS的普及和普遍存在,人们习惯了在没有任何旧世界发行版内置的信任保证的情况下获取软件。
软件工件的安全压力越来越大
积极利用像 Log4j 这样的备受瞩目的漏洞,为软件供应链安全的重要性提供了新的视角。
在大多数组织痴迷于网络安全的情况下,Log4j展示了这类全新的漏洞利用,因为开发人员构建系统和他们使用的工件从未被赋予信任机制。现代黑客是从这些敞开的门口进入——找到依赖项,不安全的库或其他组件——然后一旦进入,就转向所有其他可传递的依赖项。
对于现在关注软件供应链安全的组织来说,Log4j激发了对更好地了解软件工件来源的需求。公司开始问这些问题,比如这些人工制品是从哪里来的?他们通过监管链被篡改了吗?这个开源项目还在维护吗?
许多人沮丧地意识到,他们的安全扫描程序完全错过了安装在容器外部和底层发行版之外的软件。当扫描程序找不到这些软件包时,它们也无法找到它们的漏洞。
除了不想花费下一个假期来补救下一个Log4j之外,组织也感受到了迫在眉睫的监管变化带来的热度。CISA的自我认证通用表格 ——结合正在进行的白宫网络安全法令——清楚地表明,不安全软件的责任将在未来适用于供应商。措辞仍然模糊不清,但这种立法/监管努力的演变是显而易见的。FedRAMP(规定了向美国联邦政府销售软件的合规条款)已经对建立软件组件的信任和修复已知漏洞提出了非常具体的要求。
如今,大多数公司都意识到,扮演鸵鸟不是管理软件支持生命周期的策略。我们都需要了解在环境中运行的所有软件工件,并且我们需要对正在部署的软件工件的安全状况充满信心。
我的发行版中有什么乱七八糟的东西?
在开源项目进入软件供应链之前,公司可以看到一些不错的信号,以尝试了解开源项目的安全状况。例如,OpenSSF Scorecard项目就是一个很好的资源。
但是发行版本身通常是你在了解你已经在运行哪些安全漏洞时面临的最大障碍之一。
一方面,世界上许多最流行的发行版都存在误报问题——这是相当于“嘈杂寻呼机”综合症的安全漏洞。例如,这里是红帽通用基础映像 9 的扫描。如果我在此映像上运行 syft,我在此发行版中看到203个软件包,其中记录了211个 CVE,这比软件包的数量还要多。例如,在这里,我重点介绍 dmidecode 组件,该组件的严重程度评分为中等:
为什么所有这些单片发行版都要在它们的基本映像中安装那么多你根本不需要的组件?例如,dmidecode是一个用于从服务器的BIOS检索信息的组件——它与容器化环境无关。
在发行版中包含这些工具的最初目的是为管理员提供统一的体验,并支持“开箱即用”的最常用实用程序。因此,所有这些“厨房水槽”包的存在是累积技术债务的一种形式,这种债务是由于发行版需要默认地服务于每个可能的用例而产生的。
对于当今使用这些发行版的组织来说,这种技术债务是巨大的成本。如果我们经常遇到我们既不使用也没有发行版维护者打算修复的组件上的CVE,我们就会遇到“漏报”问题,这会影响我们对影响我们基础架构的实际漏洞进行分类的能力。
这些报告的漏洞不仅会产生你不想要的CVE修复的额外噪音,而且还可能创造出可用于其他开发链的小工具,这类攻击被称为“离地生活攻击(LOTL)”。例如,攻击者可以利用sudo,获得容器内部的root权限,然后使用这些其他工具突破容器。现在,攻击者已在主机上并已完全破坏系统。通过使用你实际上不使用的软件包,你将承担未知的责任。
Wolfi:调整发行版的大小,使安全信号有意义
Wolfi 是一个发行版,其名字的灵感来自世界上最小的章鱼。它于一年前推出,强调模块化设计,并将更细粒度和最小的包打包,以便开发人员和安全团队可以对他们正在运行的内容进行推理。其设计原则是为了解决为早期时代设计的发行版与当今在云和边缘运行的工作负载之间的这些基本脱节:
容器映像往往滞后于上游更新,导致用户运行具有已知漏洞的映像。
容器映像中使用的常见发行版也落后于上游版本,导致用户手动或在包管理器外部安装包。
容器映像通常包含比所需更多的软件,从而导致不必要地增加攻击面。
嵌入式方案(例如在边缘运行的 IoT 设备)存储容量较小,因此需要更小的分布。
大多数发行版都针对稳定性、广泛的兼容性和缓慢、有目的的更改进行了优化——Wolfi 优先考虑快速更新和极简主义,使用版本流允许用户选择他们希望使用的更新以及何时使用。
Wolfi 软件包是使用 melange 构建的,melange 是一种灵活且安全的构建工具。它使用 YAML 进行配置(世界在 YAML 上运行),并在容器中运行构建步骤(可以使用 bwrap、docker、Kubernetes 运行)。它生成使用私钥签名的 .apk。Wolfi 将这些软件包托管在CDN上,CLI(apk)管理安装。此外,Chainguard使用apko(一种将APK软件包组合成OCI基础映像的工具)从这些软件包以声明式构建其Chainguard Images产品。
Wolfi 强调频繁更新和自动化。过去,开源意味着你可以永远获得软件的免费副本,而今天的现实是,你必须有一个不断更新软件的计划,这就是Wolfi的原语优化的目的。用 Wolfi 术语来说,软件包更新的生命周期如下所示:
Wolfibot 监控 GitHub 和发布监控的更新,并将其作为 PR 归档。
维护者审查并批准这些更新,并将它们合并到发行版中。
Wolfi 中上游发布和可用性之间的时间可以用分钟来衡量,而不是几天/几周。
可用性并不意味着你应该将其推广到生产环境,你应该对其进行测试。
在Wolfi的极简设计下,默认情况下包含更少的组件,这意味着在测试时需要担心的组件更少。
随着Wolfi发布一周年,它吸引了一些伟大的贡献,包括1300个软件包配置。此外,我们还与一些使用最广泛的容器扫描仪建立了合作伙伴关系,如Docker Scout,Grype,Snyk,Trivy,Wiz和Prisma Cloud。
不同的发行版有不同的优先级。Debian 的首要任务是稳定性、广泛的兼容性以及缓慢而有目的的更改——这些优先事项使其成功了三十多年。Alpine的首要任务是……更快。Alpine以安全为中心,最小,更频繁的发布和补丁——在许多方面,Alpine是Wolfi的精神前身。所有这些发行版都是了不起的公共产品,激发了围绕Wolfi的许多设计合理化。
参考链接:
https://thenewstack.io/meet-wolfi-the-linux-distro-designed-to-shrink-your-supply-chain/