代码签名最佳实践要求将私钥保护在合规的加密硬件中，限制可发起签名请求的人员与系统，并在签名前后校验每个制品；同时要求为每个发布添加可信时间戳、记录每次签名事件，并制定密钥泄露应急响应方案。代码签名证书用于验证身份，但真正的防护来自你对密钥、流程与背后系统的安全管理。以下控制措施覆盖工程、DevSecOps 与安全团队端到端保护签名流程所需的能力。

哪些代码签名控制最重要

最重要的代码签名控制是保护私钥并阻止未经批准的软件被签名。基于硬件的密钥保护可降低密钥被提取的风险，却无法判断某个签名请求是否合法。核心控制维度包括：私钥保护（防止密钥被导出或在非批准加密环境之外使用）；签名授权（将访问限制于批准的身份、系统、仓库与流程）；制品校验（确认提交的文件是经过评审的发布制品）；签名验证（检查签名、时间戳、证书链与发布者身份）；生命周期管理（追踪过期、续期、替换、算法与吊销）；监控与响应（记录签名事件、检测异常活动并支持调查）。无法导出私钥的攻击者仍可能滥用已授权的签名服务；经过妥善评审的制品若在签名后被篡改，仍可能验证失败。代码签名有明确边界：有效签名标识发布者并表明签名内容是否变更，但不证明软件没有恶意软件、漏洞或不安全依赖。

保护私钥

代码签名私钥应在合规的加密硬件或合规的远程签名服务内生成、存储与使用，不可导出到开发者笔记本、共享文件夹、源码仓库、构建目录或普通备份系统。对于公开信任的证书，硬件保护同时适用于 OV 与 EV 代码签名。自 2023 年 6 月 1 日起，CA/Browser Forum 代码签名基线要求规定用户私钥必须在合格的硬件加密模块（如合格的硬件令牌或硬件安全模块 HSM）中生成、存储与使用。

存储：保持密钥不可导出，留在批准的令牌、HSM 或签名服务内，不要为图方便导出为 PFX 文件或在系统间复制。
激活：单独保护凭据，切勿将令牌 PIN、密码、API 凭据或服务密钥存入源代码、流水线文件、脚本或日志。只有批准的构建代理、发布服务与管理系统才能访问签名环境。硬件保护防止密钥提取，而批准每次签名请求是决定文件本身是否可信的另一步。

控制可签名软件的人员

只有经批准的人员与系统才能请求生产签名，访问应遵循最小权限原则，每个身份仅获得其角色所需权限。典型分工：开发者产出候选发布版本；评审者批准软件；发布经理授权生产签名；服务身份提交已批准制品；安全管理员管理签名环境。小团队可合并部分职责，但生产签名不应依赖无法追溯到具体人员或服务的共享账号。在支持处启用多因素认证；自动化流水线应使用专用的 workload 或托管身份，而非分配给个人的凭据。在平台允许时，按仓库、流水线、文件类型、产品、环境、证书或发布窗口限制身份；高影响发布可能还需第二位授权人审批。

签名前校验每个制品

每个制品在签名前都应被扫描、评审并与批准的发布匹配。有效签名无法区分经过评审的软件与通过被入侵构建流程提交的恶意代码。在候选发布被批准时生成密码学哈希，并与签名流程收到的哈希比对，不一致应中止流程。安全检查可包括恶意软件扫描、漏洞测试、依赖分析、密钥检测与包校验，具体组合取决于软件及其风险等级，不要将单次杀毒扫描视为软件安全的充分证据。发布记录应标识仓库与批准修订、构建任务、制品名称与哈希、必要安全检查结果、发布审批人与签名策略。对于高保证发布，可对比同一源码修订在独立隔离系统上构建出的哈希——无法解释的哈希不一致是流水线某处被篡改的强烈信号。

将签名嵌入受控发布流程

代码签名应作为可重复流程的一部分，在签名施加前后设定明确检查。自动化可减少人工操作，但不应让每个构建或拉取请求都能触达生产密钥。将未签名的候选发布与已完成签名的包分开存放；必须在用户将下载的版本上执行验证，因为打包、压缩或后续修改可能使先前的签名失效。

测试与生产签名分离

测试与生产构建应使用不同的证书、密钥与访问策略。测试证书绝不可用于公开发布，生产密钥也不应对日常开发流程可用。开发身份可自签名或由内部 CA 签发，仅在受管测试设备或预发环境中受信任，不要广泛分发该信任。生产签名应有更严格的控制，可能需要批准的流水线、受保护的构建代理、发布授权或额外评审。本地构建与拉取请求流程不应拥有生产身份。发布前确认最终制品带有预期的生产签名，未签名或测试签名的构建应被发布检查拒绝。

为每个发布添加时间戳并验证

每个生产签名都应获得可信时间戳，并在最终分发文件上验证。时间戳记录签名是在代码签名证书有效期内创建的；有了被接受的时间戳，签名在证书常规过期后仍可验证，因为验证者可确定其施加时间。时间戳不能修复无效签名，也不能保证在每次吊销或泄露事件后持续可信。将时间戳失败视为发布失败：签名工具即使无法连接时间戳服务器也可能施加签名，因此流程必须确认时间戳已添加；若时间戳失败，应中止发布、记录错误并通过批准流程重试。签名与打包后验证要点：签名在密码学上有效；出现预期的发布者身份；证书链到预期的可信根；文件摘要与签名内容匹配；存在有效时间戳；使用了预期的证书与摘要算法；每个需要签名的组件都已签名。

在生命周期内管理证书与密钥

代码签名证书与密钥应通过文档化的生命周期进行登记、监控、续期、替换与退役，等待签名命令失败才发现证书过期是不可接受的方式。应记录证书序列号、关联密钥或服务、CA、责任人、授权产品、环境、日期、续期状态与事件联系人。2026 年 3 月 1 日及之后签发的公开信任代码签名证书最长有效期为 460 天，应提前启动续期以完成验证、签发、密钥配置、流程配置与发布测试。续期并非仅因新证书已签发即告完成，投产前需测试签名、时间戳、证书链验证与批准流程的访问。团队还应监控摘要算法、密钥长度、加密模块标准、CA 政策、签名工具与平台规则的变化，在泄露、基础设施变更、政策或加密要求需要时替换密钥；密钥退役时应禁止其用于新签名，但保留验证历史发布所需的记录。

记录与监控签名活动

每次生产签名事件都应记录签名了什么、何时签名、使用了哪张证书以及由谁或什么授权了请求。签名记录可包括制品名称、版本与哈希，签名时间，证书或密钥标识，请求身份，发布审批，时间戳状态，以及签名与验证结果。保护日志不被未授权删除或篡改；监控异常签名量、意外时间、陌生系统、认证失败、错误证书以及无匹配发布记录的请求。并非每个异常事件都意味着泄露，但在相关软件发布前仍应调查。

为签名密钥泄露做准备

疑似签名密钥泄露需立即暂停签名、保全相关记录、联系签发 CA 并识别受影响软件。步骤：暂停签名，禁用受影响密钥、令牌、账号或服务；保全证据，保留签名、认证、构建与审批记录；联系 CA，遵循其泄露报告与吊销流程；识别受影响发布，区分合法与可能未授权的签名；评估分发，判断是否受影响软件已触达用户或第三方；替换与恢复，在干净环境中创建新密钥并在恢复签名前纠正根因。不要假设每个带时间戳的签名在吊销后仍持续可信，应与签发 CA 协调吊销决策，同时阻断受影响密钥的继续使用。

代码签名最佳实践清单

- 私钥保留在合规加密硬件或合规签名服务内。
- 签名访问仅限于授权身份与流程。
- 测试与生产签名相互分离。
- 制品与批准的构建及记录哈希一致。
- 必要的恶意软件、漏洞与依赖检查已通过。
- 发布已获得所需审批。
- 已添加可信时间戳。
- 最终可下载包通过了签名验证。
- 证书过期与续期处于监控中。
- 签名事件已被记录。
- 已具备密钥泄露响应方案。

关于安全代码签名的常见问题

最重要的代码签名最佳实践是什么？保护私钥是最重要的单项控制。但仍需将硬件保护与访问限制、制品审批结合，因为攻击者即使不导出密钥也可能滥用已授权的签名服务。

测试与生产构建应使用同一证书吗？不应。测试与生产构建应使用独立的签名身份与访问策略，生产密钥只应对批准的发布流程可用。

代码签名能证明软件安全吗？不能。代码签名用于标识发布者并检测签名内容的变更，并不证明软件没有恶意软件、漏洞或不安全依赖。

代码签名密钥应多久轮换一次？没有适用于所有环境的统一间隔，应根据 CA 要求、组织政策、基础设施变更、加密要求、使用限制或疑似泄露来替换密钥。

若签名密钥可能泄露，团队应怎么做？暂停使用受影响密钥，保全证据并联系签发 CA，识别用该密钥签名的软件、调查可能的未授权使用，并在干净、批准的環境中创建替换密钥。

结语

选择符合验证需求、密钥存储方案与软件发布流程的 OV 或 EV 代码签名证书，并将上述最佳实践落实到签名全流程，是保护软件供应链与发布可信度的关键。具体证书品牌、密钥存储形态与申请方式请以各证书服务商公布的信息为准。