数字证书管理需要数百或数千个证书来支持IT基础架构，因此很容易导致应用程序完整性下降，并给业务带来不必要的风险。孤立的团队手动管理数字证书的繁琐性质通常会导致绕过其组织要求的PKI标准。

根据其管道的复杂性，DevOps和DevSecOps团队可能会发行由不可信来源签名并被不安全存储的证书，以加快CI / CD工作流程的构建和部署阶段，从而避免冗长的证书申请过程，这可能需要数周甚至是数周的时间。几个月。使用本手册，不安全的加密做法来签名和部署代码会使组织面临可避免的高风险。

代码签名和该过程中使用的证书应使用加密硬件进行集中管理和自动化。在这里，小编将逐步介绍强化代码签名的过程以及如何在DevOps和DevSecOps管道中简化其管理。

    强化代码签名的4个步骤  

    1.准备分发的无符号代码生成公钥和私钥对的时间  

我们从一个准备发布的无签名可执行文件开始。为了安全地签署代码，代码发布者需要生成一个公私密钥对。这是大多数运行时架构所要求的，包括Windows、Java等。生成代码签名密钥的最安全方式是使用FIPS 140-2三级验证的硬件安全模块（HSM）。

    2.向发证机构（CA）提交公钥和证书签名请求（CSR）  

有了在步骤1中生成的密钥对，就会生成CSR并提交给发行CA。該CSR包含識別發佈者和簽章演算法，以及數位簽章的資訊。这些信息被发行CA用来发行代码签名证书。

在某些情况下，例如物联网(IoT)设备制造，组织可能决定作为自己的发证CA。

    3.发布者的识别和CSR的认证  

签发CA验证代码发布者的身份，然后对CSR进行认证，确保发布者对其进行了数字签名。如果识别和认证都成功，发证CA将发布者的身份与公钥打包，然后对打包进行签名，创建代码签名证书。

    4.准备签名确定安全级别  

现在代码签名证书已经准备好了，任何可执行文件都可以被签名和部署，除非需要进行进一步的代码测试或QA。企业，尤其是快速发展的企业，经常发现自己将代码签名密钥存储在代码发布者的本地机器或服务器上，这种不安全的方法会导致重大问题。将密钥存储在本地机器或服务器上会带来重大的安全风险。本地机器可能会和代码签名密钥一起被入侵/盗取，或者心怀不满的员工可能会恶意签名并部署未经授权的代码，这可能会在一段时间内不被发现。

最好将代码签名证书导入并存储在密钥管理服务器（KMS）中，该服务器将证书存储在FIPS 140-2级防篡改的物理边界后。除了加固存储外，还可以利用具有适当加密特性和功能的KMS来帮助实现整个代码签名和证书管理生命周期的自动化。KMS允许DevOps和DevSecOps团队无缝地满足最佳实践，同时消除手动工作流瓶颈，并与CI/CD系统原生集成。减少了生成和管理数字证书的时间，从而加快了代码部署，提高了团队产出。

    简化持续集成  

使用HSM进行安全密钥生成和证书存储有巨大的价值。此外，DevOps和DevSecOps团队可以大幅减少持续集成代码构建所需的人工劳动。对于需要定义和可跟踪的签名工作流的构建，使用CI/CD集成的代码签名可以提供显著的好处。

该工作流程通常包括管理构建和签名请求流程的CI/CD系统、管理所有代码签名密钥并执行签名流程的集中式安全密钥管理服务器，以及管理以授权方式签署代码的流程的审批实体。

当部署这样的系统时，在FIPS 140-2 3级验证的HSM的支持下，组织还可以将自动化引入该流程。这意味着，代码签署不再是一个人工驱动的步骤，而会引入人为错误的空间，它被原生地纳入到代码开发和发布工作流程中。

    与代码签名技术整合  

提供加固密钥存储的KMS和HSM加密设备通常与流行的代码签名技术集成，这些技术可执行各种任务，如验证发布者身份和确保代码完整性。例如，使用带有Microsoft Authenticode的SignTool.exe的组织可以直接与具有完整证书管理功能的KMS集成。其他集成和用例包括Java Jar Signer、RPM(Red Hat)、Docker和各种物联网实现。除此之外，创新组织正在寻找能够在标准操作系统和运行时SDK之外部署更高级的代码签名工作流的系统，以便与CI/CD系统更紧密地集成。

将HSM集成到DevOps和DevSecOps管道中，同时提高了工作流程的效率，并支持整个组织的其他加密操作。