We often discuss how important it is to incorporate security into all parts of the DevOps software development lifecycle (SDLC). For example, my post Security...Security Everywhere discusses what types of security can be incorporated into the different phases of the SDLC. However, incorporating security is often hard, due to part to the fact that most automated security testing tools are only available in a couple of places in the SDLC, primarily the continuous integration (CI) server. There is an opportunity for lots of testing without much additional overhead. This opportunity presents itself when developers push their code to a central code repository, specifically git repositories. Using git hooks, developers can write tests for their code and run them when code is committed and pushed to the repository. These tests will actually prevent developers from committing and pushing their code if they contain security flaws. In this blog post, I will introduce and present a demonstration of Overcommit, an open-source tool that manages git hooks.

Overcommit is easy to set up and can be used with any git repository. The Overcommit tool supports several third-party hooks out of the box that can be managed simply through an .overcommit.yml file. The tool also includes a mechanism that allows developers to be confident that no one will be able to execute malicious code on their system. Developers will have to run overcommit --sign the first time they set up Overcommit and each time they make a change to the settings file mentioned above. Developers can also install Overcommit by default in all git repositories within a system, which can be useful when bringing new team members up to speed on a development pipeline.

There are two primary places where security tests can be included in the coding phase of the SDLC, the PreCommit and PrePush phase. PreCommit tests are run when a developer runs the command git commit. If the tests fail, the developer will not be able to commit the code locally. PrePush tests are run when a developer tries to push the committed code to the central code repository by running the command git push. If the PrePush tests fail, the code will still be committed locally, but the code changes in that commit will not be pushed to other developers.

This demo uses a Ruby on Rails application and Brakeman, a Ruby on Rails static analyzer, which is one of the third-party hooks that is available out of the box with Overcommit.

1. The first thing a developer would need is a Ruby on Rails application. I am using a simple example that is the result of an online walkthrough tutorial. I recommend this tutorial for anyone interested in learning Ruby on Rails. This application is using Ruby Version 2.2.4 and Rails Version 5.0.0.1. Pull the completed tutorial from my Github repo by running the following command.
   
   git clone https://github.com/kontostathisk/rails_simple_blog.git cd ./rails_simple_blog/
   
   
2. Next, run the application by using the command bin/rails server and go to localhost:3000, a simple blog application that will allows for CRUD operations on blog posts.
   
   
3. Then install Overcommit and Brakeman on the machine that is running the application.
   gem install overcommit
   gem install brakeman
   
   
4. Now it is time to set up Overcommit in the repository. This needs to be set up for each repository with which Overcommit is to be used.
   
   overcommit --install
   
   
5. Then sign the configuration file so that no one can add malicious git hooks into the repositories in within a system. Signing must be run each time a change is made to the configuration file.
   
   overcommit --sign
   
   
6. To see Overcommit and Brakeman in action make changes to two files that will fail Brakeman tests. Then uncomment the "http_basic_auth.." lines at the top of the file, and save those files.
   
   
7. Run the traditional git commands that allow developers to push their code to the central code repository.
   
   git status
   git add .
   git commit -m "Committing bad authentication"
   git push
   
   
8. A couple of tests will run after the commit command, and then the Brakeman tests fail when the edited code is pushed to the Github repository. It is important that the Brakeman tests fail because the lines of code that were uncommented include username and passwords in plain text, which is insecure.

Wrapping Up and Looking Ahead

Overcommit is a simple way to incorporate security testing into the SDLC pipeline and can take some pressure off of the CI server. In just a few commands, developers can run an automated testing suite of tools that will help developers create a more secure code base.

Looking ahead, developers should incorporate Overcommit into automated environment creation scripts, which will ensure the benefits of Overcommit when they set up their development environment with a tool such as Vagrant.

Additional Resources

To view the webinar DevOps Panel Discussion featuring Kevin Fall, Hasan Yasar, and Joseph D. Yankel, please click here.

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.