Security testing in CI/CD

- [Instructor] For continuous integration for the course, I decided to go with Travis CI. Travis CI was the first to turn continuous integration into a software as a service offering, and I've used it for many years. I really like Travis CI as they're a software as a service offering, but they're free for open-source projects to use. At Signal Sciences, we use a similar setup that I'm going to show here, but we do it all in Jenkins. The actual CI system is not that important as long as it supports using Docker containers. I am opening my browser to travis-ci.org/wickett/security-testing-class. I can see the latest build and the results. Travis shows me red or green, whether I passed or failed, and how long the whole thing took. There is a badge that you can insert into a webpage that shows your current status. Now we'll click Build History, and I can see the status of all the past jobs that I've run. This all looks great, but how is it all set up? Let's head over to our security testing class repo in GitHub. This is at github.com/wickett/securitytestingclass. In here is a file called travis.yml. This is the config that Travis uses as instructions for the build. Let's check it out. The first few lines are letting Travis CI know what kind of instance to put on the job and tell Travis CI to use Docker. Next, we have a stanza of before_install. In here, we have taken some of the shortcuts from our make file and added them here. Since our demo uses two Docker containers, I've made sure to pull both of them here. Travis CI works just like our development environment. It will run gruyere as a daemon on port 8008, and then we'll use our second container, gauntlt-docker, to execute attack files. This is just like what we've been doing, only now it is our CI system that is doing the heavy lifting. There's a line in here that says ./scripts/travis-config.sh. Let's take a look at this. I'm moving up a level, and then opening the scripts directory and clicking on travis-config.sh. This script finds the IP address of the host, and then sets the environment variable in the config/cucumber.yml. It sets this up as a TARGET_HOSTNAME environment variable. This isn't a permanent change. It's just for the build. Let's go back to our main config over at the root of the project in .travis.yml. In this script portion, the long statement here is just telling Travis to use gauntlt in a Docker container, much like we've been doing throughout the course in our helper script gauntlt Docker that we put in our path at the start of the course. Notice what attacks we're running here, hello-world and our environment variables attack. I also took the cross-site scripting attack and made some changes. Let's open up attacks/ci/xss.attack. This is in the exercise files of course, but let's just view it in GitHub. Notice how it is using our environment variable approach. Also, at the bottom, I've changed it so that even though it detects two cross-site scripting issues, it will still pass. You obviously don't want to do this in real life, but this is just for the demo. Now that we've worked our way through the configuration of Travis, let's fire a build and check the results. Any change, no matter how small, will invoke the build to run. So instead of heading back to the command line, let's just stay in the browser, and let's do all of our edits from here. I'm opening up the readme and making a small change to the readme, which will kick off a build. Add a little message in here. It says, "Thanks for watching, and be sure to star this repo if you like the course." Now I've committed this change, and this launches a Travis CI run. Let's head back over to Travis CI and watch the build run. Since this takes a little time, we will speed it up. The build looks good. We can see that our Docker containers got downloaded and then our attacks got run. This puts security testing alongside other tests, and this approach can work for almost any CI system you're working with. Like I said, even though we did this in Travis, at work, we use Jenkins in the same fashion. We've run over 10,000 deploys through it in the last two years. Security has to be part of delivering value, and we move security tests to where the code is being written as much as we can.