By: Axel Simon, Open Source Security, Office of the CTO, Red Hat
In the race for competitive gains, businesses are increasingly turning to specialist software solutions. As a result, their IT landscapes have become a patchwork of different vendor systems. This can threaten information security. More solutions increases the number of trust relationships and gives intruders more potential entry points to strike from. And with businesses employing deeper integrations between systems to optimise performance and productivity, an attack can quickly spread.
Supply chain attacks, which use third-party software to infiltrate an organisation, have become prevalent. In 2020, malicious code injected into a SolarWinds software update spread first through US federal government departments, before going global to infect around 18,000 organisations. While 18,000 customers downloaded the impacted version of SolarWinds’ software, a far smaller number were actually targeted by the attackers. As CISA has noted, “a much smaller number have been compromised by follow-on activity on their systems”. SolarWinds also announced “the actual number of customers who were hacked through SUNBURST to be fewer than 100”. In March this year, more than 20,000 US organisations were compromised through a vulnerability in Microsoft’s Exchange Server. It isn’t uncommon for relatively innocuous supply chain partners to pose the most risk. One of the largest ever data breaches in history, the 2013 attack on US retailer Target, was achieved by hacking into their partner’s air conditioning software. Supply chain security has become such hot news that it is the subject of a new Executive Order straight from the White House.
Whereas the risks from software supply chain attacks are unignorable, so are the promises of technological prowess. This is the dichotomy that many organisations present themselves with. In day-to-day terms, this perception can force software developers to make a choice — make the effort to comply with the highest security standards, or free yourself of the inconveniences and friction and focus on creativity instead.
One way to reconcile these seemingly opposed drives is to rethink software signing, the process of providing undeniable proof that software has not been altered or corrupted prior to deployment.
Traditional code signing techniques use cryptographic keys to verify the author and the integrity of the content of a software repository, for instance. That places a burden on the developer to generate keys and then keep them safe. Some may view the burden as too much, and stop signing the code they write (bad for security) or write less code (bad for innovation). Both have knock-on effects for other developers. When much of the world’s software today 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 leverages open source code.
That said, it is the open source community that is taking the lead in devising a more developer-friendly software signing environment. The project — named sigstore — replaces the long-lived keys with ephemeral keys linked to existing identifiers (think email addresses and social media logins). It also produces a public and immutable log of all activity. Both essentially take the burden for software signing away from developers, freeing them up to do what they’re best at. What’s more, a system that doesn’t rely on keys that can be stolen or lost is inherently safer.
Progress has been swift. Since sigstore launched in 2019, its founding members — Red Hat, Google and Purdue University — have been joined by other organisations, and the project has moved under the auspices of The Linux Foundation. The scope has expanded too, with sub-projects now gaining a life of their own, such as Cosign (for container and general software artefact signing), Rekor (a transparency log) and Fulcio (a certificate authority) and collaborations have begun with other open source initiatives, notably Tekton Chains (an offshoot of the Tekton CI/CD project).
These are not only important predictors of success. They also point to how sigstore might be deployed; as an integrated feature within broader technology. Any moves to assimilate sigstore’s capabilities into a developer’s existing toolkit will only advance one of the key aims of the project; to simplify and automate digital signing to the point where it becomes invisible infrastructure and developers no longer notice or have to worry about it.
