代码签名利用公钥基础设施（PKI）作为软件的数字护照。通过数字签名，它可以创建真实性和完整性的加密证明。 它可以验证您作为发布者的身份，并通过证明您的代码在发布后未被篡改来确保代码的完整性。
当用户下载你的软件时，他们就把系统安全交给了你。一旦失信，你就完了。
目录
- 用硬件安全模块保护私人密钥
- 对代码签名密钥实施严格的访问控制
- 在签名过程中为代码打上时间戳
- 将测试-签署与发布-签署环境分开
- 在签名前实施代码验证和完整性验证
- 签名前对代码进行病毒扫描
- 轮流使用密钥和多个证书
- 认真对待证书吊销
- 利用扩展验证代码签名证书
- 自动化和集中化代码签名管理
- 使用 SSL Dragon 确保您的软件供应链安全
SolarWinds 的漏洞暴露了重要的软件供应链漏洞，显示了被破解的签名密钥如何将合法的软件更新武器化，并危及成千上万的组织，这让我们看到了真正的利害关系。 现在，遵循代码签名最佳实践已不再是可有可无，而是保护用户和声誉的根本。
保护软件供应链已成为各种规模企业的当务之急。这些指南将帮助您实施重要的安全措施，无论您是单独开发人员还是管理企业 DevOps 管道。无论您签署的是 Windows 可执行文件、macOS 应用程序、Linux 软件包，还是 iOS 和 Android 移动应用程序，这些原则都适用于所有平台。
用硬件安全模块保护私人密钥
您的 私钥在代码签名中至关重要。如果私钥泄露，攻击者就可以用你的身份签署恶意软件。您的证书会被吊销，您的客户会失去信任，您的品牌也会受到打击，甚至无法挽回。
私人密钥安全为何至关重要
将私钥视为软件可信度的万能钥匙–它能生成证明你身份的数字签名。如果有人窃取了它，他们就可以发布看起来像是来自你的恶意代码。你需要撤销你的证书，重新签署你发布的所有内容，并希望你的客户在安装受感染的软件之前注意到其中的不同。
将密钥存储在硬盘或构建服务器上的传统方法会带来麻烦。开发人员的机器会被入侵。构建服务器会被攻破。即使在普通硬件上进行加密存储，密钥也很容易被提取。
FIPS 140-2 认证硬件解决方案
硬件安全模块（HSM）将私钥存储在防篡改硬件中，从而解决了这一问题。作为PKI 基础架构的基石，HSM 提供了基于证书的信任所需的安全基础。这些设备在内部生成和使用密钥，而不会将它们暴露在系统中。如果试图对 HSM 进行物理篡改，就会破坏密钥。
FIPS 140-2认证在这里很重要。第 2 级要求有物理篡改证据，而第 3 级则增加了主动篡改响应，在有人试图入侵时将密钥清零。对于大多数企业来说，2 级认证提供了可靠的保护。这些硬件解决方案可与 Windows、macOS 和 Linux 开发环境无缝集成，无论您的构建平台如何，都能保护您的密钥。政府和高安全性应用应考虑第 3 级。
USB 令牌提供了一种便携式 HSM 替代方案。它们是经过 FIPS 认证的加密硬件，可以随身携带，通过持有增加物理安全性。主要证书颁发机构都支持 HSM 和 USB 令牌实现代码签名证书。
不过，CA 的政策各不相同，您需要根据这些政策制定计划。DigiCert 和GoGetSSL 颁发的代码签名证书有效期只有 1 年，您可以使用 CA 提供的 HSM 或自己的硬件。
Sectigo (Comodo)提供最长 3 年的多年期证书，但规定更为严格。如果选择 2 年或 3 年证书，则必须使用自己的 HSM。CA 提供的硬件只适用于 1 年期订单。
Want to sign code? You need the token. No token, no signing—even if someone compromises your entire network.
对代码签名密钥实施严格的访问控制
并非团队中的每个人都需要访问生产签名密钥。事实上，大多数人都不应该拥有它。
原理很简单：有访问权限的人越少，攻击载体就越少。设置基于角色的访问控制（RBAC），将签名权限限制在特定角色。您的质量保证团队不需要生产签名权限。你的初级开发人员可能也不需要。
创建审批工作流程，要求对生产版本进行多次签批。一个人提交要签署的代码，另一个人审批，然后才是实际签署。这种职责分工可以避免错误，防止内部威胁。
保存全面的审计日志。记录谁签署了什么、何时签署以及从哪个系统签署。CA 安全委员会的《代码签名最佳实践》白皮书强调，详细的日志记录对于事件响应和取证调查至关重要。当出现问题时–最终总会出现问题–你需要知道到底发生了什么。
实体安全也很重要：
- 不要将 USB 令牌放在桌上。
- 不要在纯文本文件中存储 HSM 访问凭证。
- 不要在便签上写 PIN 码。
这些问题听起来很明显，但它们是常见的问题，会破坏原本稳固的安全性。
在签名过程中为代码打上时间戳
问题是：代码签名证书通常会在一到三年后过期。如果没有时间戳，证书过期后，你的签名就会失效。即使你的代码没有发生任何变化，用户也会开始看到有关软件不可信任的警告信息。
时间戳可以解决这个问题，即在签名过程中添加一个来自证书颁发机构时间戳服务器的可信时间戳。该时间戳证明你在证书有效期内签署了代码。即使您的证书过期或被吊销，签名也会保持可信。
将其视为带有日期的公证印章。公证人可能会退休或关店，但他们在你 2020 年的文件上盖章，仍能证明该文件在 2020 年存在并经过验证。
技术过程简单明了。在签名过程中，工具会与证书颁发机构运行的时间戳服务器联系。服务器返回一个已签名的时间戳，并将其嵌入代码签名中。当用户在任何平台（Windows、macOS、Linux、iOS 或 Android）上验证您的签名时，他们会同时检查您的签名证书和时间戳。即使证书过期和安全标准不断变化，这一验证过程也能长期保持代码的完整性。
这还能节省资金。如果没有时间戳，每次更新证书时都需要重新签署所有已发布的软件。有了时间戳，旧版本就能无限期地保持可信度。
将测试-签署与发布-签署环境分开
测试环境不应使用与生产环境相同的签名密钥。永远不要
测试证书应自行签名，或由内部测试证书颁发机构签发，该机构与生产证书的根目录不同。这种架构上的分离可防止测试签名代码被误认为是可发布的软件。
为每个环境设置独立的签名基础架构。测试签名可以更容易访问，限制更少–开发人员需要快速迭代。但生产环境的签名应采用我们讨论过的所有安全措施进行严格锁定。
明确标记测试包。在文件名中包含 “TEST “或 “BETA”。使用不同的产品标识符。防止意外向客户分发测试签名代码。
访问控制也应大不相同。开发人员可以直接访问测试签名。生产签署则需要审批工作流，可能还需要完全不同的凭证。
在签名前实施代码验证和完整性验证
代码签名提供代码认证–确认软件的发布者。它并不能确认软件是否安全。
这种区别很重要，因为你要对你签署的所有内容负最终责任，即使这些内容并不全是你写的。在未经核实的情况下签署代码，就像在未核实借款人财务状况的情况下共同签署贷款一样。
在签署任何文件之前，执行提交和审批流程。请专人审查要签署的内容。将构建服务器上的代码与源代码库进行比较。确保它们完全匹配。
SolarWinds 的漏洞告诉我们，攻击者可以将恶意代码注入构建管道。这次攻击凸显了软件供应链安全的重要性–每一个组件、依赖关系和构建步骤都是潜在的攻击载体。如果不经过验证就签名，就等于信任了基础架构的每一部分和来自外部的每一段代码。这可不是你想下的赌注。
尽可能设置自动检查。对开发人员检入版本库的代码进行数字签名验证。运行静态分析工具。为已批准的构建文件创建校验和，并在签署前对其进行验证。
记录一切。当有人提交代码供签署时，记录提交了什么、谁提交的、谁批准的以及签署了什么。这些审计跟踪在调查事件时至关重要。
签名前对代码进行病毒扫描
代码签名证明你发布了软件。用户相信你不会发布恶意软件，但代码签名证书并不能验证安全性。
当你从外部资源（开放源代码库、第三方组件、承包商贡献）中获取代码时，这一点很重要。你要把所有代码都签在你的名下。
签署前扫描所有内容。尽可能使用多种杀毒引擎。检查已知的恶意软件签名、可疑模式和潜在漏洞。无论您准备的是 Windows 可执行文件、macOS 应用程序、Linux 软件包，还是 iOS 和 Android 的移动应用程序，这一点都适用。
在签名前捕获无意中插入的恶意软件可以保护用户和公司声誉。而在分发已签名恶意软件后发现恶意软件，则意味着证书吊销、客户通知和损害控制。
扫描只会给您的构建过程增加极少的时间，但却能为代码的完整性和真实性提供必要的保护。扫描是强制性的，而不是可有可无的。
轮流使用密钥和多个证书
不要把所有鸡蛋放在一个篮子里。在所有情况下都使用单一代码签名证书会造成单点故障。
考虑为不同的产品线或主要版本使用不同的证书。如果发现某个证书的管理方式存在安全漏洞，只需撤销该特定证书即可。你的其他产品仍会受到信任。
定期更换密钥也能限制风险。如果有人在 6 个月前泄露了你的密钥，但你已经更换了新的证书，他们就无法以你的身份签署当前的代码。损害仅限于旧版本。
有些组织会为不同的 DevOps 团队或发布分支分配独特的证书。这样可以分散风险，使漏洞调查更容易。当出现问题时，您可以清楚地知道涉及到哪个证书以及哪些版本受到了影响。
制定一个兼顾安全性和运行开销的轮换时间表。对许多组织来说，每年或每半年轮换一次是可行的。高度安全的环境可能每季度轮换一次。
认真对待证书吊销
证书吊销是核选项，但有时是必要的。
如果私钥被泄露，请立即撤销。不要等待评估损失。不要希望没有人注意到。撤销，通知证书颁发机构，并开始控制。
撤销会影响使用该证书签署的所有代码。用户将看到警告。自动系统可能会阻止安装。这就是时间戳至关重要的原因–它限制了在时间戳之后但在废止之前签署的代码所受到的损害。
在 PKI 基础架构中仔细跟踪证书。了解证书的位置、访问权限、过期时间以及所签署的代码。随着规模的扩大，证书生命周期管理变得至关重要。
按照证书颁发机构的程序向其报告泄密事件。他们会帮助撤销证书，并可能提供通知要求方面的指导。
在需要之前制定撤销计划，可以减少程序的混乱。记录步骤、分配责任并练习程序。
利用扩展验证代码签名证书
扩展验证（EV）代码签名证书是X.509 数字证书，比标准证书提供更高的保证。证书颁发机构在颁发证书前会进行更严格的身份验证。
EV 证书需要符合FIPS 140-2 2 级或更高标准的硬件存储。你无法获得 EV 证书并将其存储在硬盘上。这种强制性硬件保护降低了密钥泄露的风险。
大多数 EV 证书都装在带 PIN 码保护的 USB 令牌上。您需要同时使用物理令牌和 PIN 码来签署代码。这种双因素方法使未经授权的签名更加困难。
佐治亚理工学院网络取证创新实验室的研究发现，EV 签名的可执行文件抵御了 99.99% 的网络钓鱼攻击测试，而标准签名的抵御率为 90%。包括 Windows、macOS 在内的操作系统以及 iOS 和 Android 等移动平台都能识别 EV 签名，并向用户显示增强的信任指标。增强的信任指标和严格的审核带来了显著的不同。
选择 EV 证书当您需要最大限度地信任旗舰产品、广泛分发的软件或处理敏感数据的应用程序时，请选择 EV 证书。额外的成本和管理开销可以提高可信度和安全性。
自动化和集中化代码签名管理
在多个团队持续交付代码的 DevOps 环境中，手动证书管理无法扩展。
证书生命周期管理（CLM）解决方案在与 CI/CD 流水线集成的同时实现了集中控制。Sectigo Certificate Manager 和 AppViewX CERT+ 等平台可提供专为代码签名工作流设计的企业级 CLM 功能。开发人员无需直接访问密钥即可自助生成数字签名。安全团队可在所有签名活动中保持可见性并执行策略。
这些平台可跟踪证书库存、过期日期和使用模式。集中化管理对软件供应链安全至关重要，尤其是当多个团队和承包商为您的代码库做出贡献时。它们可以自动更新，并使审计变得简单明了。当你需要知道哪些证书是用哪个证书签署的时候，信息就会出现在你面前。
与构建系统集成意味着开发人员无需考虑证书细节。他们只需提交代码，管道就会使用相应的证书自动处理签名，签名后的成果就会从另一端输出。
预先定义的工作流程可执行安全策略。代码未经批准不得签名。测试证书不能用于生产。一个业务部门的开发人员不能访问另一个部门的签名密钥。
集中化既简化了安全性，又不会增加开发人员的工作难度。这就是你所需要的平衡–强大的安全性与你的开发流程协同工作，而不是与之对立。
使用 SSL Dragon 确保您的软件供应链安全
SSL Dragon提供来自DigiCert和Sectigo 等领先证书颁发机构的代码签名证书。无论您是需要为内部应用程序提供标准代码签名，还是需要为广泛分发的软件提供 EV 证书，我们都将帮助您选择正确的解决方案。
我们的团队了解软件开发人员面临的安全挑战。我们可以指导您进行证书选择、实施和管理，确保您的代码签名基础架构遵循行业最佳实践。
了解 SSL Dragon 的代码签名证书，或联系我们的团队，讨论哪种解决方案最适合您的软件开发和安全要求。保护您的软件供应链–您的用户正在依靠它。
