Recently, headline-making software supply chain failures have caused serious damage to brands, reputations and bottom lines. One of the most notorious of these incidents was Nvidia. Earlier this year, stolen code signing certificates from Nvidia were used to sign malware. Nvidia was hit by ransomware that led to a data leak of up to 1TB of data. Employee login information and intellectual property was stolen, including two expired code signing certificates and their private keys. Although the certificates were expired, at the time of the incident Windows permitted driver signed with public trust codesigning certs to be loaded in their OS even if certificates are expired. According to samples uploaded to the VirusTotal malware scanning service, the stolen certificates were used to sign various malware and hacking tools, such as Cobalt Strike beacons, Mimikatz, backdoors and remote access trojans.

Code signing attacks are not new

However, codesigning as an attack vector is not new. We’ve seen warnings for the past decade about the risk of stolen code signing keys to digitally sign and distribute malware as “trusted.” But the threats have expanded. We’ve seen not only stolen and lost keys but also signing environment breaches and malware infected code or vulnerabilities infecting code due to ever growing popular use of opensource libraries in software development. All these lead to major financial and reputation loss for affected organizations.

In fact, the issue is so widespread that recently the United States issued an executive order on improving the nation’s cybersecurity, and one of the key steps included was the use of code signing to assure code integrity.

So with the software supply chain a target of attacks, what can you do to secure your software specifically related to codesigning to prevent future issues and keep up with evolving software security threats? We recommend a managed signing solution. In this blog, I’ll explain some of the pitfalls with what is often known as traditional, manual or local codesigning and how a signing solution enforces best practices. .

Manual code signing allows organizational vulnerabilities to persist

Cyber criminals look for ways to exploit unsafe code signing practices. According to the National Institute of Standards and Technology (NIST), undermining code signing is one of the common attack techniques in software supply chain attacks.

Manual code signing can lead to vulnerabilities in key security, people or policy and processes.

1. Key security: In manual code signing, it is difficult to keep track of where keys are and how they are protected. Key access may be left unrevoked when employees leave, and keys or certificates may not be stored securely. This makes it all too easy to share, misuse or steal signing keys.
2. People/policy: With manual code signing, there is no easy solution to tracking or auditing who signed what, when. Without rights management, enforcing and maintaining corporate policy and roles is quite difficult.
3. Processes: Finally, processes like separation of duties, and knowing which keys or certificates to use when signing may lead to signing keys used for all apps, impeding remediation. It also makes it easier to sign builds that unknowingly contain malware.

That’s why, especially as vulnerabilities expand, it is best to use a managed signing solution to ensure code signing best practices.

Managed signing solutions ensure secure code signing best practices

A managed signing solution helps to ensure best practices, including:

• Key protection
• Hash signing
• Security controls
• Role-based access controls
• Maintaining compliance
• Software lifecycle visibility
• Software bill of materials

Maintaining compliance is more relevant than ever, as the Code Signing Working Group of the CA/B Forum has been developing improved requirements for code signing key protection, which will require changes to code signing management. Using a managed solution, you can more easily stay up to date with changing regulations.

Signing solutions offer ways to prevent the risk of stolen keys, amongst other important controls. For instance, DigiCert^®Software Trust Manager secures keys, centralizes management, enforces policy and integrates with CI/CD, all with flexible deployment options.

Software lifecycle visibility

Software lifecycle visibility is no longer just a good practice for organizations to track for their own visibility, it is also becoming more important for customers and the industry. Customers now want to know how the sausage is made so that they can put plans and controls in place to take action if a piece of that software becomes compromised.

It is important that enterprises building software trace the lifecycle of that software over time, so that they have full visibility of what is changing from one release to the next. Additionally, tracking the lifecycle gives you the ability to identify where you have risks associated with third-party code and the library that is being utilized as a component in the software make up.

Why you need a software bill of materials

Just as IoT devices are vulnerable to hacking, breaches and other forms of cybersecurity attacks, so are all forms of software, hardware and even containerized data centers. The U.S. Executive Order on Cybersecurity is designed to help fix these IoT device vulnerabilities, but it only works if there’s an attestable software bill of materials (SBOMs). SBOMs are best implemented and utilized in opensource and private trust use cases related to software running on connected devices.

Knowing the make-up of your software will help to translate that spaghetti code design to a clear SBOM deliverable that reads like the label on the back of a cereal box, so really this will benefit all software types. This will not only help organizations keep vigilant against third-party vulnerabilities, but will also help with building customer confidence through transparency. This gives the customers the ability to take rapid action in their environment if the software or device running a vulnerable component is identified.

Software is ever evolving and ever changing. And customers want to know what the software is made up of. I expect to see a move to incorporate SBOMS into all software in the future as the industry moves to ensure visibility into what components make up software.

About DigiCert Software Trust Manager

DigiCert Software Trust Manager in DigiCert ONE™ is a modern way of managing code signing by enabling automated security across Continuous Integration/Continuous Delivery (CI/CD) pipelines with portable, flexible deployment models and secure key management. DigiCert Software Trust Manager supports code signing best practices like unique key and certificate per signing for private signing, on-demand keys and rotating keys. It is compatible with major platforms and libraries like Docker, Microsoft, Java, Android and more.

Using DigiCert Software Trust Manager, enterprises integrate code into their product development processes easily, while delegating cryptographic operations, signing activities and management in a controlled, auditable way. As a part of DigiCert ONE, DigiCert Software Trust Manager offers a quick deployment of high volumes of certificates within minutes, plus the flexibility to deploy on-premises, in-country or in the cloud.