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.
Let’s start with the checklist. When I do training, I advise companies to adopt a standard four
There is no one right or wrong list, but be mindful of making the list too long or cumbersome.
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.
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.
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.