DevOps teams are increasingly using containers to execute job-specific workloads in Cloud Native environments. But many developers lack security expertise in code signing and machine identities that are used to protect containers. This can result in custom scripted code signing in pipelines—using certificates from outside of security team oversight that aren’t built with security in mind.
Code signing containers: overview
Code signing of containers is a critical security measure that developers often handle—but that can be dicey.
A container is an entire runtime environment: an application, plus all its dependencies, libraries and other binaries, and configuration files needed to run it—bundled into one package. By containerizing the application platform and its dependencies, differences in OS distributions and underlying infrastructure are abstracted away, allowing software to run reliably when moved from one computing environment to another. For example, from a developer's laptop to a test environment or from a physical machine in a data center to a virtual machine in a private or public cloud.
Containers are similar to Virtual Machines (VM), but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
Using containers—such as Kubernetes or Docker—for deploying applications is now a common practice. However, the reality is that most containers aren’t well protected because organizations often struggle to secure and protect code signing operations for containers.
DevOps driving insecure code signing
DevOps teams are increasingly using containers to execute job-specific workloads in Cloud Native environments. The problem is that most of the time the job-specific containers that drive the software development pipeline are built by developers who lack security expertise in code signing. This can lead to insecure custom-scripted code signing in pipelines, using certificates from outside of security team oversight, according to Arnold van Wijnbergen, Cloud Native Architect at Fullstaq, speaking about this in an interview with Venafi last year.
“For a developer, code signing is just another build step, but they are often so focused that they forget about the controls that are important to security teams,” according to van Wijnbergen.
“Security controls are there to assure that no risks are introduced, especially the malicious use of the code signing keys. In most cases, all the time-consuming security effort is not aligned with their primary software product outcome,” van Wijnbergen said.
When software is signed with a valid machine identity—such as a code signing certificate and encryption key—computing devices implicitly trust the software and unconditionally run it. The valid code signature indicates that the code comes from the trusted source that signed it and hasn’t been modified by a third party. When this process is compromised, cybercriminals can misuse code signing machine identities to sneak malware into your software and have it appear to come from your organization.
To avoid having malware inserted in code before it is signed, you need a code signing process that works across the overall CI/CD (Continuous Integration, Continuous Delivery) technology. CI/CD pipelines are usually completely automated, running multiple times a day. Code signing the artifacts that are used and produced by these pipelines needs to be automated as well.
How well does your code signing process protect software throughout the development process? See how Venafi CodeSign Protect can help.