在这个信任难以实现的世界，我们必须扪心自问。我们如何知道我们运行的应用程序、部署的容器或交付给客户的代码是真实的？我们如何知道它没有被篡改？

    如今，软件已不再只是店面。它是每个企业背后的运营引擎。为了让这个引擎像一台运转良好的机器一样运转，我们需要知道我们构建的所有内容和部署的所有内容都是可信的。

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

    我们正迅速走向这样一个现实：一切都需要签名。不仅是我们从第三方供应商那里购买的软件，同样重要的是，我们在自己的组织内构建和部署的软件。

    这意味着从 PowerShell 脚本、Bash 脚本、容器、库、文件到可执行文件（随便什么都可以）。

    但代码签名已存在多年。那么，它有什么变化呢？

软件供应链中的威胁

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

    从高级持续性威胁 (APT) 组织到地下室黑客等不良行为者都在这些快速变化且复杂的环境中寻找弱点或漏洞。为了保持低调，恶意代码通常会在供应链的几乎任何一点注入或修改而不被发现。要么他们破坏代码签名过程本身。

    攻击者可以将恶意代码注入开源软件、源代码存储库或入侵构建服务器本身。在 SolarWinds案例中，攻击者仅将几行看似无益的代码注入单个 DLL 文件中，就对其整个供应链造成了深远而广泛的威胁。

    攻击者还可能 获取或窃取易受攻击的系统上的代码签名密钥， 以对其恶意软件工具进行签名。我们已经在许多不同的场景中看到这种情况，其中代码签名私钥从构建服务器、开发人员工作站被泄露，甚至在固件或软件本身中意外暴露。

    因此从安全角度来看，仅仅对代码进行签名已经不够了。现在，同样重要的是：(1) 确保开发人员正在构建的内容经过签名并交付给客户；(2) 严格控制用于对代码进行签名的基础设施和私钥。

代码签名是攻击者的天然目标，因为它允许他们潜入供应链并从内部攻破目标。具体实现方式如下：

    密钥盗窃或滥用： 对手通过不受保护的系统或错误配置的帐户访问控制窃取代码签名材料。

    系统入侵： 攻击者还可以入侵集中式签名或更新服务器，以在交付过程中劫持软件更新。

    代码泄露：恶意代码被注入开源库或源代码存储库，在签名并推送给最终用户之前未被发现。

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

代码签名的当前状态

    尽管存在这些众所周知的威胁，但现实情况是，我们今天交谈过的大多数组织并没有签署尽可能多的代码，更重要的是，他们通常没有一致的代码签名流程。

是什么阻碍了它？

    问题在于，代码签名通常与软件开发松散耦合，而非紧密集成。这两个过程脱节，导致软件交付出现摩擦和延迟，更糟糕的是，这为不良行为者提供了可乘之机。以下是一些常见障碍：

    远程团队： 分散式开发是新常态，这带来了一些挑战。将密钥存储在本地机器上不是一种选择，但将大文件传输到集中式签名系统会导致大量等待时间。

    无流程： 代码签名密钥在 HSM 中受到很好的保护，但仍然需要控制签名的内容、谁可以签名等。

    手动流程： 政策护栏至关重要，但严重依赖硬件配置和手动审批流程的流程无法扩展。

    缺乏集成： 缺乏文件类型支持或与现有工具（例如 SignTool、Authenticode、jarsigner）的集成，使得维持集中控制同时允许开发人员透明地工作变得极其困难。

信查查代码签名

    为了在我们（以及我们的客户）对透明度、易用性以及安全性的要求之间找到适当的平衡，我们构建了 一个解决方案 ，可以：

    在集中控制的 HSM（物理或云）中保护私钥

    使开发人员 能够在本地机器上使用本机工具和签名方法，而私钥无需离开中央 HSM

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

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

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