We’re quickly moving toward a reality where everything needs to be signed. Not just the software we buy from third-party vendors, but also the software we build and deploy within our own organizations — everything from PowerShell scripts, Bash scripts, containers, libraries, files, and executables. Thanks to the adoption of CI/CD and build and test automation tools, application and operations teams are moving faster than ever, but that means fewer human eyes with a direct line of sight into what’s happening throughout the pipeline.
<p>Bad actors from advanced persistent threat (APT) groups to basement-dwelling hackers look for weaknesses or vulnerabilities in these fast-moving and complex environments. To keep a low profile, malicious code is often injected or modified at virtually any point in the supply chain without detection. Either that or they compromise the code-signing process itself.</p> <p> </p> <p>In a recent study, we found that companies have an average of 25 code-signing certificates. About 51% of respondents said they store the associated private keys in a hardware security module (HSM). On the flip side, many said that private keys are also found on build servers (33%) and developer workstations (19%), and nearly two-thirds (60%) of companies have no formal access controls and approval processes for code-signing keys. </p> <p> </p> <p>From a security perspective, it’s not enough to simply sign code anymore. Now, it’s just as important to: (1) make sure that what developers are building is what’s getting signed and delivered to your customers, and (2) that the infrastructure and the private keys used to sign code are tightly controlled.</p>