Rethinking the digital signature – a new way to secure the software supply chain


By: Axel Simon, Open Source Security, CTO Office, Red Hat

In the race to gain competitiveness, companies are increasingly turning to specialized software solutions. As a result, their IT landscapes have become a patchwork of systems from different vendors. This can threaten information security. More solutions increases the number of trusting relationships and gives intruders more potential entry points from which to strike. And with businesses using deeper integrations between systems to optimize performance and productivity, an attack can spread quickly.

Supply chain attacks, which use third-party software to infiltrate an organization, have become common. In 2020, malicious code injected into an update to SolarWinds software first spread to departments of the US federal government, before going global to infect around 18,000 organizations. In March of this year, more than 20,000 US organizations were compromised by a vulnerability in Microsoft’s Exchange Server. It is not uncommon for relatively harmless supply chain partners to pose the most risk. One of the biggest data breaches in history, the 2013 attack on U.S. retailer Target, was carried out by hacking their partner’s air conditioning software. Supply chain security has become so hot that it is the subject of a new executive order directly from the White House.

While the risks of attacks in the software supply chain are immeasurable, so too are the promises of technological prowess. This is the dichotomy with which many organizations present themselves. On a day-to-day basis, this perception can force software developers to make a choice: to make the effort to adhere to the highest security standards, or to free themselves from inconvenience and friction and focus on creativity instead.

One way to reconcile these seemingly opposing readers is to rethink software signing, the process of providing unmistakable proof that software was not tampered with or corrupted prior to deployment.

Traditional code signing techniques use cryptographic keys to verify the author and integrity of content in a software repository, for example. This forces the developer to generate keys and keep them safe. Some may consider the load too heavy and stop signing the code they write (bad for security) or write less code (bad for innovation). Both have ripple effects for other developers. When much of the software in today’s world is built with open source principles, where anyone can take the code and adapt it, the question of provenance becomes paramount. And this applies just as much to proprietary software, which increasingly uses open source code.

That said, it is the open source community that is taking the initiative to design a more developer-friendly software signing environment. The project – named sigstore – replaces long-lived keys with ephemeral keys linked to existing identifiers (think email addresses and social media connections). It also produces a public and immutable journal of all activities. Both essentially take the burden of signing software off of developers, freeing them up to do what they do best. In addition, a system that does not rely on keys that can be stolen or lost is inherently more secure.

Progress has been rapid. Since the launch of sigstore in 2019, its founding members – Red Hat, Google and Purdue University – have been joined by other organizations, and the project has moved under the auspices of the Linux Foundation. The scope has also widened, with subprojects now making a living, such as Cosign (for signing general software and container artifacts), Rekor (a transparency journal) and Fulcio (a certification authority). ) and collaborations have started with other open source initiatives including Tekton Chains (an offshoot of the Tekton CI / CD project).

These are not only important predictors of success. They also indicate how sigstore can be deployed; as an integrated feature within a larger technology. Any attempt to assimilate sigstore capabilities into a developer’s existing toolbox will only advance one of the key objectives of the project; to simplify and automate the digital signature to the point that it becomes an invisible infrastructure that developers no longer notice or have to worry about.


Comments are closed.