CI/CD and its Integration with Code Signing 

CI/CD pipelines are an integral part of modern workflows and the tools that support them further expand their latent capabilities. Team effort is essential in modern workflows where deadlines are not only urgent but regular as well. Every second counts when a customer is waiting on the other end.

Having a big organization that requires multiple steps in the process of developing code can become daunting when faced with manually handling each step of the process. That’s why tools like CI/CD pipelines, such as Jenkins, have become so commonplace now in developer workspaces. The best place to start the discussion on CI/CD therefore is what the tools allow you to accomplish. 

What is a CI/CD Pipeline? 

The idea behind a pipeline is that it is a series of processes that drive software development through the steps of building, testing, and deploying code. This is also referred to as CI/CD. CI/CD is a model for a shared, usually locally hosted, build environment. The various platforms bundle implementations of CI/CD with communication and build tools that allow software to go live sooner by streamlining the build and release process.

Historically code is developed by separate teams and tested in personal environments, integration takes time, and feedback on broken code takes longer. This leads to lengthy build cycles and decreases in efficiency. It’s common practice to test a piece of code with some amount of test cases designed before development.

If the final code meets these standards, it should integrate into existing code easily. But as developers, we all know this is far from the only possible outcome even with meticulously designed test cases. As you can tell, CI/CD is the basis of DevOps in general. It focuses on continuous integration, delivery, and deployment.

The integration steps involve building the code itself, running test cases, and merging that code together. The delivery phase automatically releases the code to the specified repository, and the deployment phase, as it suggests, automatically deploys the code to the production environment.

Even though there are many steps through the CI/CD pipeline, one of the most important steps in this process is the ability to test code. CI/CD presents a way to execute test cases at scale, where changes to code can be tested in a single streamlined and automated action.

Code is pushed, received by the pipeline, tested and if all cases pass, the build can be set to go live. It’s amazing what this can do for your organization’s agility. Fixing a bug on a dime is quite possibly the future of development. Except we are missing an important step here. No customer or organization should be running unsigned code. This is where code-signing comes into play.

What is Code-Signing and Why is it Important? 

Code-signing is the process of generating a digital signature and attaching it to code, so that an end-user can trust that the code distributed to them is safe to use. The basics of code-signing are as follows: 

1. A developer will decide that they wish to sign their code. This will occur with most developers now, as providing an end-user with unsigned code is unsafe and insecure.
2. Once a developer decides to sign their code, they must then generate a public-private key pair, and a Certificate Signing Request (CSR). The public-private key pair identifies the developer as themselves and is necessary to create the CSR. The CSR is given to a Certificate Authority, along with the key pair, and is necessary to generate a digital signature for the code.
3. The public key of the public-private key pair is then sent to the Certificate Authority, or CA, and a code signing certificate is requested.
4. The CA then verifies the identity of the publisher, authenticates the publisher’s certificate request, and then bundles the identity of the publisher with the public key.
5. The CA then signs the bundle, thus creating a digital code signing certificate. This certificate allows the developer to generate a digital signature for the code in question, identifying that the code was developed by the software publisher.
6. Finally, the signing certificate is sent to the software publisher and they can now generate their digital signature and attach it to their code.

The modern release process demands codesigning, a step that depending on your organization’s current process, could greatly reduce the speed and efficiency conferred by CI/CD. Code-signing proves the identity of the developer of the code, as well as ensures the integrity of the code.

When code-signing occurs, any further modifications will invalidate the signature, providing assurance that signed code is free of tampering. This is the central benefit of codesigning that makes it so necessary in the modern world. Regardless of your industry, your products will be unusable in environments from school networks to banks if you do not implement code-signing.

There is also the benefit of mitigating risks for reputational damage. By only distributing signed code, your organization can ensure that users are used to seeing a signature before installing your software. This leaves them less vulnerable to attackers impersonating your organization. 

Integrating a CI/CD Pipeline with an HSM 

So, we need code signing, but an automated build system with direct access to keys is a recipe for disaster. Leaks and compromises happen, it’s essential to properly store and protect your codesigning keys in a Hardware Security Module, or HSM. The consequences of not securing codesigning keys with an HSM have already been seen in the last year, with organizations losing access to their codesigning keys that service firmware.

Because they service firmware, these keys cannot be cycled or replaced, and the consequences will haunt the affected companies for potentially years. HSMs are tools not just for code signing, but also for securing Public Key Infrastructure’s and database encryption keys as well. It must be said that HSMs are an essential tool for almost all organizations storing data, encryption keys, or developing code.

Now when we talk about HSMs, some with mild experience may think managing an HSM can be a difficult process. Optimal security means regular updates to firmware and software, regular audits, and properly managing access to keys. In addition, there is the work of actually integrating the HSM into your existing pipeline.

Custom work from a certified HSM engineer is expensive and time-consuming, and if something breaks, having to contact someone outside your company can prove slow and impractical. To solve the issues and complexities presented thus far, Encryption Consulting has developed a competitively priced solution in Code Sign Secure and its integration with any HSM your organization may desire.

Leveraging the capabilities and security of HSMs such as the Thales, Entrust, or Utimaco HSMs, Code Sign Secure will easily integrate into your existing pipelines, streamlining the codesigning process.  

Conclusion 

System-as-a-service offerings save you the headache of owning and maintaining an HSM, however, if your organization already owns an HSM or is concurrently implementing PKI or another HSM-dependent service, the same HSM can support Code Sign Secure. For this reason, the best choice for your organization depends on your security roadmap.

Luckily Encryption Consulting can work with your organization to help plan a path forward, identifying current shortcomings in the security space as well as needs for your organization. We provide audit and consulting services and will employ our team of industry experts to identify the solution ideal for you.