Source code repositories are an important link of any software supply chain - equally as important as securing artifacts such as containers. If a trusted person's identity is spoofed and potentially leads to malicious code being committed to a repository, the integrity of the software supply chain can be compromised. By signing git commits, organizations are able to distinguish between verified and unverified changes made to a GitHub repository to attest identity – one more link in your supply chain hardened!
However, while this is not a security vulnerability per se, it can cause other issues. When you see an unsigned commit, you have no guarantee that:
1. the committer is really the person whose name is on the commit
2. the code change you see is really what the author wrote and that it has not been tampered with.
Making a habit of signing your Git commits, instead, gives you the ability to prove that you were the author of a specific code change. When paired with additional metadata such as OIDC claims, this can even let you distinguish signing events from different automation events!
Here at Chainguard, we are big fans of Sigstore and the Gitsign tool for signing your commits without needing to provision long-lived keys. This allows us to:
However, using this in practice today comes with a downside: source repositories themselves don't know how to recognize Sigstore signatures yet.
Instead of waiting for source providers to add support, we implemented this ourselves.
Today, we are announcing Chainguard Enforce for GitHub–- a GitHub App for public repositories that lets you define and enforce policy for Sigstore-based Git signatures.
As an example, the policy below (real policy we use for our prod codebase), ensures that only users with @chainguard.dev email addresses and select CI jobs are allowed to commit changes:
How it works
With the Chainguard Enforce for GitHub App, you can create policies for Sigstore Gitsign signatures to define what identities are allowed to sign commits in your codebase. Whether they are human users or CI/CD, they can take full advantage of the Sigstore keyless flow to sign commits without needing to store long-lived keys.
When combined with GitHub's Repository Rulesets, you can make this a merge blocking check, ensuring that submitted commits comply with policy.
Install the app today at https://github.com/marketplace/chainguard-enforce!
For more information, check out our documentation on Chainguard Academy.
What’s next
Commit signature verification isn’t the only capability we’re focusing on when it comes to helping organizations secure their source code. At Chainguard, we are big proponents of other repository hardening tools like GitHub Repository Rules, but these features only protect before merge, and it can be difficult to audit whether these rules were in place when a change was submitted.
To ensure that this critical supply chain metadata is preserved and auditable long after the pull request is submitted, we are looking to add a feature we’d like to call Code Review Provenance. Code Review Provenance could do things like capture code review state for all your pull requests, allowing you to enforce and audit compliance for security best practices like two-person code reviews.
Wrapping it all up together together
Last year, we announced the private preview availability of our Enforce Signing feature, which enables customers to generate digital signatures for software artifacts inside their own organization using their individual identities and one-time-use keys.
In short, Enforce Signing gives you your own Sigstore-compatible environment to sign your artifacts. Don't want your data on a public transparency log? Want to use your existing SSO provider not supported by the public Sigstore instance? We can help with that.
Want to collaborate? Let's talk!
As we focus on securing the software supply chain by securing the build pipelines and signing container images, we should also aim to practice good source hygiene by locking down who can commit changes to the code base. By shifting signing and verification to earlier in the SDLC, we can further lock down our supply chain and prevent rogue actors from injecting malware or vulnerabilities in our source code. If you are interested in working with us, we're looking for design partners for these new features, so please get in touch by filling out this form.
