Why Code Signing is Critical for Software Security
Not that long ago, I worked for a company that didn’t have a DevSecOps team. The company didn’t even really have a DevOps team. Like many small, fledgling companies most of our devops was handled by backend developers, and they did a pretty decent job. Obviously their main focus was on the product we were building — our build environment was a second thought for them. If it was working then all was good, while security wasn’t even a second thought. They knew the basics but even those best practices weren’t always adhered to — we had a product to build!
Also like many small, fledgling companies, there were a good number of pranks. One in particular caught my attention and has stuck with me. I was asked to review a pull request from myself! How was that possible? It had my GitHub account avatar, GitHub username and everything. As it turns out it was easier than you might imagine.
Accepting only verified commits, is one of the easiest and most powerful things a company can do to ensure that the code is from trusted sources. Luckily it’s also one of the easiest and most transparent to developers.
Git hosting services like GitHub make it easy to identify and only accept signed commits. Have you seen that beautiful green “Verified” icon in the commit history?
That icon lets everyone know that the commit was signed by the given individual – the email address and signing key match the git user at the time of commit. On the other hand, if you see an “Unverified” or blank commit there’s no telling who actually committed the code or if the original code was tampered with.
So back to the prank. The code that was sent to me for review, “from me”, was of course unverified. It had my GitHub username and my avatar but no beautiful green “Verified” icon. All the malicious committer had to do was get my email address and change their .gitconfig file, like so:
Now every commit that’s made will look like this:
Notice there’s no icon at all next to the commit ID on the right? This is because there is no signing key to match to the email address. The user is a GitHub user, their email is in the GitHub system, and for all GitHub knows this is in fact Payman. Nothing is necessarily wrong here – just someone making a commit to the repository – and there’s no way to know who actually committed the code.
If the malicious committer attempts to sign the commit, but the key doesn’t match the user’s email address, it looks like this:
Notice “Unverified” is now displayed in the icon. This tells anyone that is paying attention that something is definitely wrong if you normally expect that all team members are verified.
And finally, when the signing key and the user’s email address do match, you get the very satisfying green “Verified” icon:
Knowing who is committing code to your repositories is a simple but effective start to securing your supply chain. GitHub has the ability to enforce signing and reject unsigned commits all together so that only verified commits are ever allowed. Learn more about securing your GitHub repositories with branch protection rules here, and requiring signed commits here.
How Can BluBracket Help?
The BluBracket CLI tool walks developers through setting up a GPG key and the necessary steps for signing your code. The tool also gives developers the ability to scan commits for sensitive information like tokens, keys, IDs, sensitive words, PII and even custom regular expressions before their code is committed. The really great part is that it’s 100% free. Go here to try it out. Once you’ve tried it out, we would love to hear your feedback on how we could make it even better – email@example.com.