Recently I have been thinking and talking to other people about open source security. The more conversations I had, the more convinced I became that this is a very complex topic. It is full of nuance and conflicting opinions. It is also an area that is in need of guidance and educational content.

Making good security practices the path of least resistance is a solid way to raise the bar in this space.

GitHub is in a very special position. It is the dominant platform for open source projects. I am very positively surprised that GitHub has been consistently adding security features to the platform. I am sure they are not done yet, but today they cover a pretty broad set of capabilities that allow for strong authentication, protecting and recovering from sensitive data leaks, managing vulnerabilities in dependencies, scanning source code for potential security issues, and disclosing vulnerabilities.

Those features are great, and I want to make programmers more aware of how to use them, and when.

GitHub Project Security Checklist

If you don’t know how to secure your open source project, I put together a checklist that you can use to get started.

1. Use a credential manager to protect your access credentials. Regardless of whether you use username and password or SSH keys to authenticate to GitHub, make sure to protect them well. Leaked credentials may allow attackers to take over your project and use it to attack your users.
2. Configure two-factor authentication (2FA). GitHub offers several 2FA mechanisms to provide stronger authentication. You can use one-time codes sent over text messages (SMS) and mobile apps. If you want even stronger protection, you can use security keys as your second authentication factor.
3. Enforce signed commits. Git makes it a little bit too easy to spoof commits and allow attackers to make their code to look like yours. GitHub supports cryptographic protection against such attacks.
4. Protect the release branch. Not all branches in your repo were created equal. Git promotes a development model where branches are cheap, and the bulk of work happens in branches. Some of them are used to release software. These branches should have additional rules that govern who and when can merge changes.
5. Require pull request reviews and approvals. Git and GitHub are all about enabling collaboration but it does not mean that you cannot control what code is merged. You can and you should.
6. Scan source code for sensitive data leaks. Mistakes happen and we sometimes commit sensitive data to public repositories. GitHub integrates with multiple services and can detect their leaked secrets.
7. Scrub leaked secrets from git history. Sensitive data leaked into a public GitHub repository might be out of your control. Git and GitHub allow you to contain the damage by rewriting git history to remove the sensitive data. It is not full remediation, but we should still do it to limit the blast radius.
8. Only use trusted GitHub Actions. GitHub Actions are tremendously useful, but if you are not careful, you may end up running malicious or sloppy code in your build pipeline. Make sure you only run Actions you trust.
9. Protect the secrets used by GitHub Actions. GitHub Actions that handle software releases and deployment often require credentials to work. Make sure these credentials are appropriately protected.
10. Review project dependencies for vulnerabilities. Our code is rarely written from scratch. Modern applications are built on top of a rich ecosystem of open sources modules and packages. Some of those packages contain security vulnerabilities that may impact your code. Make sure you review and vet your dependencies.
11. Patch dependencies with vulnerabilities. Security vulnerabilities are discovered and disclosed every day. Plan and be prepared to patch your vulnerabilities. GitHub allows you to automate much of this process using Dependabot. Use it if you can.
12. Scan project source code for vulnerabilities. Your code can have security bugs, too. Discovering vulnerabilities is still a bit more art than science but there is a lot of progress in automated source code analysis. GitHub CodeQL is a state-of-the-art security analyzer. At least try it out.
13. Publish a security policy. If your project is successful, there is a chance that someone will discover a security flaw in your code. Make it easy for them to report it and be very clear about what you will do with that report.
14. Collaborate on fixes for security vulnerabilities in private forks. Working in the open means that it is impossible to hide things. And yet, sometimes you will want to work on some changes in the code in private, for example when fixing a security vulnerability. Working on a fix in the open might allow attackers to reverse engineer the bug and attack your users. GitHub provides a mechanism to easily create a private fork of your repo. Use this private fork to collaborate on a fix.
15. Publish maintainer advisories for security fixes. Fixing a security vulnerability is no small feat and you should tell your users about it. You should do it in a way that will make it easy for them to learn about it and patch (see point 11 above). GitHub provides an easy way to publish a security advisory that will be incorporated into security scanning tools that your users depend on to keep their applications secure.

Completing all these tasks is a very good start. If your project is successful, you will be well equipped to handle increased expectations your users will have of the security of your code.

Where to Learn More?

From the documentation, of course! GitHub has very decent docs and they cover the security features pretty well. I provided links to git and GitHub documentation wherever I could.

That said, I thought there is another way to reach a broader development community to evangelize using good open source security practices. I am currently working on a Pluralsight course that demonstrates how to implement items from this checklist for a fictional open source project.

I think it is going to be a fun and engaging way to demonstrate how to implement security best practices. Stay tuned!