Using Github Pull Request Templates and Checks to Implement Security Checklists

This blog post will show one way to build security checklists into your code review and pull request flows in GitHub.

On almost every project we do with developer teams, one thing we recommend is a simple checklist to help keep security top of mind. Back in 2013 we helped a client implement this in TFS. It took a long time…

Yesterday I added this to our organization’s process in about 90 seconds using existing GitHub functionality. For free.

I have to acknowledge my colleague Joe Kerby on this blog post (@iamjoeker) who pointed me to
both of the component parts that make this idea work.

The Checklist

Let’s start with the checklist. When I do training, I advise companies to adopt a standard four
item checklist:

• Prevented InjectionInjection is a type of cyber attack where an attacker exploits vulnerabilities in an application or system to inject malicious code or commands. Injection attacks are often carried out by inserting code or commands into input fields or parameters that are passed to an application or database. (Command and SQL - parameterized queries)
• Prevented XSS (Used framework that does escaping and didn’t bypass)
• Implemented authorization
• Identified any sensitive data and handled according to data classification

There is no one right or wrong list, but be mindful of making the list too long or cumbersome.

Using a Pull Request Template

GitHub has an idea of a pull request template. This is just a markdown file named pull_request_template.md that you drop in your project root (or several other locations) and then when you create a pull request in GitHub the content is pre-populated in the body of the pull request.

So in this case, we can create a file like this:

## Security Checklist

- [ ] Authorization has been implemented across these changes
- [ ] Injection has been prevented (parameterized queries, no eval or system calls)
- [ ] Any web UI is escaping output (to prevent XSS)
- [ ] Sensitive data has been identified and is being protected properly

## Additional Deploy Steps

This section lists any additional steps to deploy the PR

Then when we create a new pull request, we get that pre-populated:

I can edit and check those boxes right in the UI when I create the pull request.

Note that there is a check that hasn’t passed and the PR doesn’t look ready to merge. See the yellow toward the bottom? That’s because I haven’t completed the checklist.

Now that I’ve completed the checklist, I can see the checks are green and it looks like I can merge.

The first step was having the pull_request_template.md file in the root of our project. The next section describes how to set up the “check” that ties this to the green “checks have passed” section.

Verifying the Checklist Is Completed

The second element is the “task-list-completed” GitHub App. You can find the
source code here on GitHub or go straight to the marketplace to install it.

I installed it for our entire organization, which required privileges at the organization level. Thankfully, the App only needs to read the text of PR’s so it doesn’t even get access to source code. Also, since the source is available, you can always go read how it works.

In any case, it was fairly easy; and I turned it on for all Jemurai repos.

Conclusion

Of course, checking these boxes doesn’t ensure everyone reviewed code properly or that they even tried. But having a checklist brings the security questions to mind on each and every PR and with proper investment can be a part of building good secure development habits.

I was thrilled to see how easy these two pieces were to put together and bootstrap a checklist in just a few minutes. I hope it is useful to you as well.

References

• Task List Completed App
• Pull Request Template