It’s easy to integrate StackHawk into your pipeline with Travis CI. The basic steps are:
- Secure your API key as an environment variable in your Travis CI Project
- Configure your Travis CI job by adding or editing the
.travis.ymlfile in your project repository
- Configure HawkScan with a
We will first describe the simple scenario of scanning a publicly available example app, example.com. Then under Local Scanning, we will show you how to run and test your app all within the self-contained Travis CI build environment.
When you signed up on StackHawk, you created an API key. To keep it a secret, copy it to the Environment Variables for your project. In the Travis CI web app, find your repository, and select More options –> Settings. From here, find the Environment Variables section. Add your StackHawk API key as a variable called
At the base directory of your code repository, add a
.travis.yml file to configure Travis CI to run HawkScan. An example is provided below.
docker run -v $(pwd):/hawk:rw -t
This configuration tells Travis CI to run a single script, which runs HawkScan as a Docker container. The StackHawk API key injected from the secure environment variable,
NO_COLOR environment variable suppresses colorized text so that HawkScan’s output is more readable in the Travis CI console.
At the base directory of your code repository, create a
stackhawk.yml appropriate for scanning your application. For our example, we will create a minimal config pointing to our
Development environment API endpoint.
host entry with your test endpoint, and replace
applicationId with your App ID from StackHawk.
Check those two files into source control, and head over to the Travis CI console to watch your job run. When your job is complete, check your account at StackHawk to review your scan details!
The previous example assumes that you have an integration environment that is publicly accessible. Alternatively, you can run your app and scan it directly on the ephemeral Travis CI build host. Here are two common ways of doing that.
One way to test an app after building it is to launch it directly on the build environment VM, and scan it on the localhost address. You can launch the HawkScan container with the flag
--network host to give it access to localhost, and set
For our example app, we will launch an Nginx container listening on port 80. Then we will scan it at the localhost address with HawkScan running in host networking mode. This method works with any app you wish to scan, containerized or not, as long as it is listening on the localhost address.
Here’s our modified GitHub workflow.
- docker run --detach --publish 80:80 nginx
docker run -v $(pwd):/hawk:rw -t --network host
--network host flag appended to the HawkScan
docker run command. This gives HawkScan direct access to the host’s network stack, including the localhost address. This is what allows it to reach Nginx running on the localhost.
Finally, here’s our modified HawkScan configuration pointing to the localhost address,
Pro Tip: avoid using
localhost, because that name won’t resolve in Docker containers running on a Linux host. Instead, use
When you run this job, it will launch Nginx, scan it with HawkScan, and post the results to your StackHawk scan list.
Another way to test your app is to run it in a container and scan it on a Docker bridge network. You can do this with
docker run commands, but we will be using Docker Compose for simplicity and flexibility. Docker Compose allows you to define a set of containers that can address one another by name using a declarative YAML configuration.
First we add a Docker Compose configuration file,
docker-compose.yml, to the root of our repository.
# Fire up the app to test, nginx_test
# Fire up hawkscan to scan the test app (nginx_test)
- type: bind
# Make the scan_net network to run hawkscan against the app
This configuration creates 2 containers (a.k.a. services) named nginx_test and hawkscan running on the bridge network scan_net.
In the Travis CI configuration, we replace the
docker script with
docker-compose, which reads
docker-compose.yml by default for its configuration. And since Nginx is represented in Docker Compose, we can remove it from the
- docker-compose up --abort-on-container-exit
--abort-on-container-exit, tells Docker Compose to tear down all of the containers as soon as any one of them exits. This will stop all containers once the HawkScan container is finished. Without this flag, the nginx_test container would continue running, and the job would hang until the build timeout was reached.
Finally, update the HawkScan configuration to point to your test app,
With this approach you can build sophisticated arrangements of Docker containers, adding databases and other services as needed to create realistic test environments.