Software supply chain attacks have been on the rise and attackers continue to use sophisticated techniques to infiltrate organizations. Since a typical supply chain has many distinct components and can run in a variety of environments, it’s important to have a multi-faceted approach to securing the entire chain. At Chainguard, we believe that one of the most critical components of a secure supply chain is signing and verifying software. Additionally, the Cybersecurity and Infrastructure Security Agency (CISA) recently introduced requirements for a self-attestation form that vendors who sell software to the federal government will have to provide. The term integrity shows up 37 times across the self-attestation form in each of the major sections. Ultimately it states, vendors will now be responsible for signing and verifying the signatures of all components they use, including commits, artifacts, and more.
Software signatures can help you confirm that the software you’re running has not been tampered with and came from a trusted source. But building signing and verification mechanisms in your organization from scratch is easier said than done (to name a few, check out these five common problems you'll likely encounter when trying to verify signatures at deployment time in Kubernetes).
At Chainguard, we have been thinking about solving the software signing problem for some time. Our founding team was instrumental in starting the Sigstore project–an open source suite of tools for signing, verifying, and protecting software that enables developers to validate that the software they are using is exactly what it claims to be using cryptographic digital signatures and transparency log technologies.
To tackle software signatures internally, we use keyless signatures to ascertain who built a piece of software and where it was built. This ensures that a strong custody chain is maintained when handing off images from producers to consumers. We also layer on identity information on top of our Chainguard Image signatures to ensure that only trusted parties have built, signed and made these Images available for usage. Our signed Images can then be verified at deployment time within Chainguard Enforce, which acts as a gate to allow only trusted and verifiable workloads into production.
Here’s a more in-depth look at how we approach software signing internally at Chainguard and how we can help enterprises looking to tackle this problem within their own organization.
Chainguard Enforce Signing
Public artifacts typically can use Sigstore’s public infrastructure, including the Fulcio certificate authority and the Rekor transparency log for storing signatures. Since these artifacts are already public, there’s no concern around leaking sensitive data. Using public Sigstore tools makes it easy for end users to verify signatures with minimal effort, and this process has become the de facto wax seal of approval for major open source projects like npm and Kubernetes.
Through our own journey, we’ve recognized that private and public software artifacts might have different signing requirements. Enterprises with private artifacts have concerns with leaking sensitive private information and may not be able to store any information in a public log, so public Sigstore infrastructure is not an option. This is why we built our Enforce Signing feature, which gives users the flexibility of keyless signatures alongside a privately managed signing infrastructure where no sensitive data is stored. Let’s take a look at how we sign and rely on both the public Sigstore instance and a private instance of Enforce Signing to secure our own software.
Signing our private artifacts
Having a way to sign our private artifacts was a big inspiration behind the development of Enforce Signing. We needed a way to sign our production images privately, and in the process figured other organizations might be looking for a similar solution. We previously used a public instance of Sigstore to sign production images, but have been dogfooding signatures for our private production images with Enforce Signing since making the feature available. Internally, we get the convenience of using Sigstore without the concern of storing sensitive information in a public log.
With Enforce Signing, we can also set custom IAM rules around which employees or machines can sign with that instance of Enforce Signing. You can say things like, “only this specific Github Action can build and sign this image.” If verification passes successfully, we can know exactly where/when the image was signed. We can then write policies for these images before they’re deployed internally, such as a policy to verify that they have been signed by our instance of Enforce Signing and confirm that they’ve been built within our Github organization.
Signing Public Chainguard Images
Our publicly available Chainguard Images are signed by the public Sigstore instance in Github Actions and can be easily verified with the cosign CLI tool.
This is an easy way to prove a Chainguard Image hasn’t been tampered with and verify that it was built in the expected repository.
Git commits
Lastly, every commit that enters our internal repos has been signed by a Chainguardian. We use the gitsign tool to associate every commit with an email address using the Sigstore public infrastructure. We then use a tool we call Enforce for Git to verify these commits have been signed by a Chainguardian as a required presubmit check on every Github PR. If the commit hasn’t been signed, then the PR can’t be merged. Signing git commits is an easy way to start securing your source code and make sure that only authorized users are able to commit code.
We are working on making our tool freely available through the GitHub Marketplace. If this is something you’d be interested in testing out in your environment as an early user, reach out to our team.
Let us help you on your signing journey
Software signatures at Chainguard are a critical piece of our own software supply chain security, and we believe it should be a part of any organization’s approach to secure software development. Soon, having signed software will be required in order to sell software to the federal government. If you haven’t yet thought about how you will meet this requirement, we are here to help.
If your organization is just starting to explore a strategy for software signing or you already are on your way, reach out to our team to learn more about Enforce Signing.
Chainguard will be at Hacker Summer Camp in Las Vegas, NV on August 9 - 13. Check out our booth #SC208 at Black Hat or book a meeting with our team on site.
