大内高手社区 › 首页 › 互联网资讯 ›

分享到

Log4J等软件供应链中的安全问题有解吗？

互联网资讯 2022-8-30 11:24 758人浏览 0人回复

收藏分享邀请

摘要

这就是在过去12个月中导致大量高调攻击的原因，从SolarWinds到Codecov攻击，再到Travis CI机密泄露。虽然我们的基础设施方面做得非常好，但却让攻击者寻找到更简单的方法进入，并在我们在供应链中敞开的大门中找到了 ...

Log4J等软件供应链中的安全问题有解吗？

Log4J这盆冷水，让大多数开发人员意识到他们的软件供应链安全问题。我们的构建环境并不像我们的生产环境那样安全。

几十年以来，大大小的公司都把注意力聚焦在软件构建和各自的生产环境上，很少意识到这一切是基于未打补丁的Jenkins盒子上构建的。我们把大部分时间都花在保护“运行时”，然后使用业余工具部署到它们。

这就是在过去12个月中导致大量高调攻击的原因，从SolarWinds到Codecov攻击，再到Travis CI机密泄露。虽然我们的基础设施方面做得非常好，但却让攻击者寻找到更简单的方法进入，并在我们在供应链中敞开的大门中找到了它。

无法通过周边安检进入？只需找到一个开源依赖项或库，然后就可以了。然后转向所有客户。这是现代软件供应链黑客。

PART 01

软件也需要有信任的根基

人们之间有信任的根源。我们有双重身份验证，我们有识别系统。这些都是证明一个人身份的东西。硬件也有同样的东西。我们有加密密钥。我们有我们可以相信的硬件在启动时没有被篡改。

即使作为互联网用户，我们也有信任的根源。我们有URI、URN和URL——也就是互联网上连接我们所浏览站点的身份、名称和位置的命名空间；SSL证书则表明浏览器网站是安全的；DNS防火墙位于用户的递归解析器之间，以确保我们的缓存没有被错误的请求加载。所有这一切都发生在幕后，几十年来在支持数十亿互联网用户方面取得了令人难以置信的效果。

但是我们今天没有这个用于软件工件。

PART 02

开发人员过于隐晦地信任

开发人员经常把许多事情委托给不同的人员和系统，却没有意识到其中的风险。因为其中的每一个环节都可能被篡改或攻击，或者甚至可能是恶意的。

举一个当下开发者习以为常的例子：从云原生计算基金会(CNCF)Artifact Hub安装Prometheus（目前非常流行的开源可观察性项目）。技术人员安装完Helm，然后查看所有被拉取且开始运行的集群镜像，就会发现：许多容器镜像最终都是通过一个简单的安装运行开始的。

这与“零信任”是完全相悖的——我们信任几十个我们一无所知的系统。

首先，我们不知道作者，也不知道代码是否是恶意的。而且因为每个镜像都有各自的工件，所以整个供应链是环环相扣的。因此，我们不仅信任工件，还信任那些信任这些工件的依赖关系的人。

我们也信任操作存储库的人。因此，如果存储库运营商遭到入侵，那么现在这些入侵者也就成为了“信任圈”的一部分。任何控制这些存储库之一的人都可能改变某些东西并发起攻击。

然后是构建系统。构建系统可能会受到攻击并被注入恶意代码。2020年，SolarWinds软件供应链入侵事件就是一件值得让人警醒的事情（SolarWinds是一家生产名为Orion的网络和应用程序监控平台的公司，然后使用该访问权限生成木马化更新并将其分发给软件用户）。

即使你信任镜像的运营商以及运行托管图像的系统的人员，如果这些系统的构建不安全，一样存在被注入恶意软件的风险。而且这种风险一直是可传递的。依赖关系维护者以及他们使用的构建系统、所在的工件管理器——它们都会被破坏掉。

因此，当开发人员安装软件包时，他们无选择地信任了很多东西，无论他们是否有这些目的。

PART 03

软件供应链安全陷阱

在软件供应链安全中，最糟糕的策略就是什么都不做，这也是当今许多开发人员正在做的事情。他们允许任何东西在生产环境中运行。更为危险的是，如果缺失对可以运行的工件的安全性，就意味着不知道它们来自哪里。

下一个陷阱则是允许列出特定标签。如果您通过一些关于Kubernetes最佳实践的教程，这很容易设置。如果将所有镜像都推送到一个位置，开发者至少可以将内容限制在该位置。这比什么都不做要好得多，但这依旧不够，因为任何被推到那里的东西现在都会被默认放在信任圈内，这并不是真正的零信任。“允许列出特定存储库”和“允许列出特定标记”具有相同的限制。

甚至供应链安全中的签名模式也在解决同样的问题。任何被签名的东西现在都可以运行，无论它来自哪里，这会导致大量的攻击，这类攻击大多涉及欺骗某人签署伪造协议或无法撤销证书等。

PART 04

是时候开始提出正确的问题了

假设走在办公室外的人行道上，发现地上有一个USB ，绝对不应该将它带入办公室并将其插入工作站。世界各地的安全组织都将这一警告作为培训的一部分。

同样地，像docker pull，npm install之类的命令，大多数开发者甚至想都不想就运行了，即使这种情况必比插入捡来的USB更糟糕。它们都可能会从不被信任的人那里获取代码并运行，但Docker容器或NPM包最终会将一路进入生产环境中！

供应链安全的演进的本质成了：作为一个行业，我们正在远离信任软件工件的来源，而是花费更多的时间来找出工件是什么的信任根。

谁发布了这个二进制文件？它是如何建造的？使用的是什么版本的工具？它是从什么来源构建的？谁签署了此代码？有没有被篡改过？这些是要关注的问题。

安全团队需要一套标准流程来锁定软件工件的信任根，开发人员需要一条清晰的路径来平衡开源选择与安全策略。开源或许是个答案。

PART 05

上一篇：一个应对复杂产品难题的顶层思维

下一篇：如何使用Node.js构建微服务

本文暂无评论，快来抢沙发!