首页>最新数字证书问答>代码签名在软件供应链中的重要性

代码签名在软件供应链中的重要性

怎么知道您的代码是可信的?

在这个难以获得信任的世界里,问自己一个重要的问题。我们如何知道我们正在运行的应用程序或正在部署的集成系统或正在交付给客户的代码是真实的呢?我们怎么知道它有没有被篡改过呢?

这一切都归结于代码签名

在本文中,我们将讨论代码签名的重要性、所面临的挑战,以及Keyfactor Code Assure确定如何允许您在不中断开发人员工作进程的情况下集中和安全保护代码签名。

如今,软件不仅仅是店面,而是每个企业背后的运营引擎。为了让这个引擎像润滑良好的机器一样运行,我们需要知道我们构建和部署的一切都是值得信任的。

软件供应链信任的核心是代码签名。代码签名证明代码源供应商的身份,并可以验证代码自发布以来未被篡改。

我们正在迅速走向一个一切都需要签署的现实。不仅仅是我们从第三方供应商那里购买的软件,同样重要的,我们在我们自己的组织中构建和部署的软件也需要签署。这意味着从PowerShell脚本、Bash脚本、容器、库、文件和可执行文件(您命名)的所有内容。

但是代码签名已经存在很多年了。那么,是否有变化呢?

软件供应链中的威胁

由于采用了CI/CD以及构建和测试自动化工具,应用程序和运营团队的发展速度比以往任何时候都要快。这意味着更少的人能直接看到整个链中正在发生的事情。

不管是高级持续威胁(APT)组织还是地下室黑客,他们的不良行为者都会在这些快速移动和复杂的环境中寻找弱点或漏洞。为了保持私密,恶意代码通常在供应链的任何点被注入或修改,而不会被发现。这样它们就损害了代码签名过程。

黑客可以在开源软件、或您的源代码库中注入恶意代码,或破坏服务器本身。SolarWinds是一个例子,攻击者只在一个DLL文件中注入了几行看似良性的代码,这在整个供应链中造成了深刻而广泛的危害。

黑客还可能获取或窃取在易受到攻击的系统上发现代码签名密钥来签名他们的恶意软件工具。我们已经在很多不同的场景中看到过这样的情况,在这些场景中,代码签名私钥从构建服务器、开发人员工作站泄露,甚至意外地暴露在固件或软件本身中。

所以从安全的角度来看,仅仅简单地签名代码是不够的。现在,同样重要的是:(1)确保开发人员正在交付给客户的内容是经过签名的;(2)同时确保用于签名代码的基础设施和私钥受到严格控制。

代码签名:攻击者的自然目标

攻击者已经转移。他们不是直接针对组织,而是在软件供应链中寻找薄弱环节,以窃取工具或破坏代码。国家支持的APT 41已经掌握了这项技术十多年,通过损害他们的软件供应商或供应商,间接针对其他公司。

代码签名是攻击者的一个自然目标,因为它允许他们进入供应链,并从内部破坏目标。这是如何发生的:

密钥盗用或误用:攻击者通过未受保护的系统或错误配置的账户访问控制来窃取代码签名材料。

系统危害:攻击者还可以危害集中签名或更新服务器,以劫持交付过程中的软件更新。

代码泄露:恶意代码被注入到开源库或源代码存储库中,并且在签名推送到最终用户之前仍然不会被检测到。

内部威胁:组织内的开发人员可能有意签署恶意代码,甚至故意在公开访问软件更新或存储库中披露签名密钥。

代码签名的现状

尽管存在着这些众所周知的威胁,但现实是,我们今天谈论的大多数组织并没有像他们应该签署的软件那么多,更重要的是,它们通常没有一致的代码签名过程。

在最近的一项研究中,我们发现很多公司平均有25个代码签名证书。大约51%的受访者说,他们将相关的私钥存放在硬件安全模块(HSM)中。另一个方面,许多受访者表示,在构建服务器(33%)和开发人员工作站(19%)上也有私钥,近三分之二(60%)的公司表示对代码签名密钥没有正式的访问控制和审批过程。

是什么阻碍着我们?

实际上问题是,代码签名通常与软件开发松散耦合,而不是紧密集成。这两个过程是脱节的,这造成了软件交付的摩擦和延迟,或者更糟糕的是,它为恶意参与者提供了利用的可能性。以下是一些常见的阻碍:

远程团队:去中心化的开发是一种新常态,它面临着几个挑战。在机器本地存储密钥不是一个选项,但是将大文件传输到集中式签名系统需要大量的等待时间。

没有流程:代码签名密钥在HSM中得到好的保护,但是仍然需要控制已签名的内容,谁可以签名等。

手动流程:策略护栏是必要的,但严重依赖于硬件配置和手动审批流程的流程无法扩展。

没有集成:缺乏文件类型支持或与现有工具(如SignTool, Authenticode, jarsigner)的集成,使维护集中控制的同时允许开发人员工作透明变得困难。

因此,问题是,如何使开发人员签署代码更简单和透明,同时保持他们对可以签名的内容和方式的集中控制?这是一个我们问自己的问题,但我们没有寻找答案,而是建立了它。

关键因素代码保证

随着我们转向更频繁的软件更新、远程开发团队和更多的产品,我们超越了现有的签名解决方案,它依赖于高度安全但繁琐的手动流程。这就是Keyfactor Code Assure的来源。

为了在我们(和客户)对透明度、易用性,当然还有安全性的要求之间找到平衡,我们构建了一个解决方案(关于它是如何运作的,在原网站有视频可观看),可以:

保护集中控制的HSM(物理的或云)中的私钥

使开发人员能够在其本地机器上使用本机工具和签名方法,而无需私钥离开集中控制的HSM。

控制对不同团队和角色的访问权限和职责分离

根据用户/组、位置、签名方法或其他参数,强制执行进行签名的策略护栏

维护所有代码签名活动和密钥使用情况的跟踪和时间戳

与构建服务器和CI/CD工具(最显著的是Jenkins)集成,以自动化进行代码签名

来源网站:https://www.keyfactor.com/沃通WoTrus原创翻译整理,转载请注明来源

最新资讯

为什么要停止使用RSA密钥交换?

什么是DNS-over-HTTPS.是如何工作的?

Apple macOS操作系统中存在三个致命漏洞

"此网站提供的安全证书不安全"的解决方法

Chrome浏览器中出现“安全连接”错误,该如何解决?

标签推荐:数字证书申请 | ssl证书验证失败 | https证书申请| 数字签名技术| 电子签名软件| ssl证书更新| 小程序证书| ca认证电子签名| 个人代码签名| 微软代码签名| 泛域名证书| java代码签名| 代码签名证书| https证书配置| PKI技术知识| SQL注入| openssl漏洞| 识别钓鱼网站