U.S. President Joe Biden’s executive order dated May 12, 2021, on improving the nation’s cybersecurity, outlined multiple steps that both the government and businesses could take to help mitigate attacks on the country’s critical infrastructure. One of these steps involves the use of code signing to assure code integrity and the delivery of code that is free of malware and threats to the country’s security (Sec 4 (e) (iii))¹.

Code signing is not a new concept. In fact, it has been around since the late 1990s. The National Institute of Standards and Technology (NIST) has authored a white paper on code signing² that describes in detail how this technology works. Simply put, signing code creates a metaphorical shrink wrap around the software which makes it impervious to tampering. Any modifications to signed code would be immediately evident. In addition, signing the code provides authenticity and shows who signed the code and when they signed it. This helps establish the provenance of the software as it moves through the build cycle.

With increasingly complex procurements consisting of bundles of hardware/software and firmware, it is becoming more and more difficult to ensure the security and reliability of third-party code in systems. One solution is to require a software bill of materials (SBOM) with each item purchased. This list would be digitally signed to prevent tampering and would include a listing of all code included in the final build (custom developed and open source), as well as a history of the custom code (or modified open source). This history would show all the digital signatures accumulated during the build cycle and would provide assurance that the code was not tampered with by an intruder. While code signing doesn’t prevent an insider from introducing a threat, it does provide a provenance which can be used to trace back to the point in time the threat was inserted.

Traditional code signing involved passing around private keys to all developers which would then be used to sign the code. The problem with this approach was that having a number of private keys on desktops sitting with multiple developers could allow for an attacker to harvest those keys via malware. It also made it impossible to determine which of the developers signed the code.

The solution is to use a cloud-based code signing service, which allows for uploads of code (or the hash) to be signed by the service and returned to the developer. The benefits of using a service are numerous, but in summary, a service secures the keys centrally, keeps track of who uploaded the code to be signed (via two-factor authentication), integrates with existing developer platforms and allows for the signing of code with unique keys. All these benefits are valuable to developers and the organization using code signing.

After recent high-profile attacks on software used in public services, ensuring the security of software code used in the U.S. critical infrastructure³ is a prime goal of this administration. Luckily the tools to do this exist today and are commercially available from a number of sources.

I invite readers to also review this article from my colleague Mike Nelson on the Solar Winds software compromise for additional insight into code signing. For more information on code signing best practices, visit www.digicert.com/campaigns/devops-close-the-loop.

¹ https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
² Security Considerations for Code Signing, David Cooper, Andrew Regenscheid, Murugiah Souppaya, NIST, Jan. 26, 2018
³ https://www.cisa.gov/critical-infrastructure-sectors