Introducing code-signing provides security within the application, but teams should take care to understand and implement the process effectively
Digital certificate management, with hundreds or thousands of certificates required to support IT infrastructure, can easily lead to degradation of application integrity and unnecessary risk to the business. The cumbersome nature of siloed teams manually managing digital certificates often results in the bypassing of PKI standards mandated by their organization.
Based on the complexity of their pipeline, DevOps and DevSecOps teams may issue certificates signed by an untrusted source and stored insecurely to speed up the build and deployment stages of CI/CD workflows to avoid a lengthy certificate request process, which could take weeks or even months. Using this manual, insecure cryptographic practice to sign and deploy code exposes organizations to a high level of avoidable risk.
Code signing, and the certificates used in that process, should be centralized and automated using cryptographic hardware. Here we will walk through the process of hardened code signing and how to streamline its management in DevOps and DevSecOps pipelines.
Hardened Code Signing in 4 Steps
- Unsigned code ready for distribution. Time to generate public-private key pair
We start with an unsigned executable that is ready for distribution. To securely sign the code, the code publisher needs to generate a public-private key pair. This is required by most runtime architectures, including Windows, Java and others. The most secure way to generate code-signing keys is by using a FIPS 140-2 Level 3 validated hardware security module (HSM).
- Submit public key and Certificate Signing Request (CSR) to an issuing certificate authority (CA)
With the key pair generated in step No. 1, the CSR is generated and submitted to an issuing CA. The CSR contains information that identifies the publisher and signature algorithm, as well as the digital signature. This information is used by the issuing CA to issue the code signing certificate.
In some situations, such as with internet of things (IoT) device manufacturing, the organization may decide to act as its own Issuing CA.
- Identification of publisher and authentication of CSR
The Issuing CA verifies the code publisher’s identity then authenticates the CSR, ensuring the publisher has digitally signed it. If both identification and authentication are successful, the Issuing CA packages the publisher’s identity with the public key then signs the package, creating the code-signing certificate.
- Ready to sign. Determine the level of security
Now that the code-signing certificate is ready for use, any executable can be signed and deployed unless further code testing or QA needs to occur. Enterprises, particularly fast-moving ones, often find themselves storing their code-signing keys on the code publisher’s local machine or server, an insecure method that can result in significant problems. Storing the keys on a local machine or server presents major security risks. The local machine could become compromised/stolen along with the code-signing keys, or a disgruntled employee could maliciously sign and deploy unauthorized code, which could go unnoticed for a while.
It is best to import and store the code-signing certificate in a key management server (KMS), which stores the certificate behind a FIPS 140-2 Level tamper-resistant physical boundary. In addition to hardened storage, a KMS with proper cryptographic features and functionality can be utilized to help automate the entire code-signing and certificate management life cycle. A KMS allows DevOps and DevSecOps teams to seamlessly meet best practices while removing the manual workflow bottlenecks and natively integrating with CI/CD systems. Less time generating and managing digital certificates results in faster code deployments and an increase in team output.
Streamline Continuous Integration
There is tremendous value in using an HSM for secure key generation and certificate storage. Additionally, DevOps and DevSecOps teams can drastically reduce the manual labor required with continuous integration code builds. For builds requiring a defined and trackable workflow for signing, code signing with CI/CD integration can offer significant benefits.
This workflow typically consists of a CI/CD system that is managing the build and signing request process, a centralized and secure key management server to manage all code-signing keys and perform the signing process, and an approval entity to govern the process by which code is signed in an authorized manner.
When deploying a system like this, backed by a FIPS 140-2 Level 3-validated HSM, organizations can also introduce automation into the process. This means that instead of code signing being a manually driven step that introduces room for human error, it is natively incorporated in the code development and release workflow.
Integration With Code-Signing Technologies
KMS and HSM cryptographic devices that provide hardened key storage commonly integrate with popular code-signing technologies that conduct various tasks such as validating publisher identity and ensuring code integrity. For instance, organizations using SignTool.exe with Microsoft Authenticode can directly integrate with a KMS with full certificate management functionality. Other integrations and use cases include Java Jar Signer, RPM (Red Hat), Docker, and various IoT implementations. Beyond that, innovative organizations are looking at systems that can deploy more advanced code-signing workflows outside of the standard OS and runtime SDKs, to integrate more tightly with CI/CD systems.
Integrating HSMs into DevOps and DevSecOps pipelines simultaneously improves workflow efficiency and supports other cryptographic operations across the organization.
