Software Supply Chain: Part 3
As part of my software supply chain series, I want to move on to the area of code signing and deployment. One new standard that is starting to gain traction is called Sigstore, led by the Linux foundation but with contributions from many industry leaders.
Sigstore is a bit of a complicated topic, but it’s gaining a lot of popularity. It is used at tech giants like Google and has 2,000 users in their corporate Slack channel. The idea is fairly straightforward, and simply described as “the new standard for signing, verifying, and protecting software”. In basic terms, this will allow you to verify software integrity without manually managing all the other overhead.
Why do we need this anyways? Well when you look at the software development lifecycle, the build process is often over looked as something that just needs to work. If this sounds familiar, you might remember this type of attack from the SolarWinds hack back in 2020.
Here is an example software workflow where attackers could potentially break in:
With that background, let’s dive into the tech stack a bit more. In today’s software development process, each developer does not have the ability to sign code, and most organizations implement it at the release process before it is shipped. The certificates need to maintained and protected, which often fall on a select group of engineers or security members.
Sigstore delivers a free and open-source signing tool through ephemeral certificates (public/private key pairs) and links to a corporate email address or other account for tracking purposes, thus simplifying and lowering the bar for more developers to use the tool. In addition, the sigstore ecosystem is able to centralize and verify all the metadata from all these code signatures in the process. This allows for more transparency and spreads the responsibility across the entire organization.
Secure by default is very important and must not be understated. We need more verifications during our development lifecycle to ensure software integrity from start to finish. The way I see it, there are still a few things holding sigstore back from wider adoption:
- Sigstore root CA is a single source of failure – It hasn’t been tested for scale and could potentially block code deployments. The website currently claims 99.5% availability meaning 1d 19h 28m of downtime per year. The bigger issue is there is little recourse if they fail to meet the SLO.
- Increased data – You’ve just gone from a few keys to potentially thousands. This means there is a lot more data to sift through and understand. Even though the solution is open-source, you will likely need to spend money on infrastructure so you can make use of the data, such as a log aggregation tool.
- It’s written in Golang – This isn’t necessarily a downside, but it could be if you need to support a new language in your environment. The project is heavily backed by Google and there are stable versions for other languages, but the main branches are developed in Go, which means you need to ensure your environment can support this integration.
Signing code is very important to defend against supply chain attacks, but it’s also one of the most cumbersome to implement for internal development. While sigstore may not be perfect, the security gains are substantial. For highly targeted and regulated industries, consider the value of implementing this process early in the code lifecycle to reap the maximum benefits.