Automated OWASP Zap Security Scans

OWASP Zap (aka Zed Attack Proxy) is a security scanner. Reports can be consumed by plugin-zap

For our CI purposes we will use a prepackaged OWASP Zap docker container in Baseline Scan-mode. In addition to the baseline scans, production and staging systems are scanned in full-mode on a schedule.

Fast CI responses

Developers require fast responses for their builds. Therefore full OWASP Zap scans are not an option for branch or Pull-Requests builds, since they take 30 minutes upwards depending on the complexity of your application. Nonetheless it is a very good idea to perform small scans in your CI Pipeline to prevent “smaller” security issues popping up in a later stage of your deployment pipeline, causing unplanned developer workloads.

For this purpose OWASP Zap comes with a baseline scan mode, which is a timeboxed passive scan intended for use in CI/CD pipelines.

Anatomy of a scan performed by CI

The scan is performed at the end of the build process. Should you package your application inside an image run OWASP Zap against an instance of your application image.

1. CI launches the application. This instance is used as a target for the baseline scan.
2. CI starts the OWASP Zap container
3. Zap probes the application in baseline scan mode
4. Zap writes a report to a volume mount and exits
5. CI sends the report using Yoke CLI to Swingletree for further processing

Configuring a OWASP Zap scan

Some CI tools like Jenkins also offer plugins to handle and orchestrate OWASP Zap scans

A Baseline scan can be started and configured with a set of options passed to the Python script zap-baseline.py inside the OWASP Zap container. This script is configurable via command-line options:

Usage: zap-baseline.py -t <target> [options]
    -t target         target URL including the protocol, eg https://www.example.com
Options:
    -h                print this help message
    -c config_file    config file to use to INFO, IGNORE or FAIL warnings
    -u config_url     URL of config file to use to INFO, IGNORE or FAIL warnings
    -g gen_file       generate default config file (all rules set to WARN)
    -m mins           the number of minutes to spider for (default 1)
    -r report_html    file to write the full ZAP HTML report
    -w report_md      file to write the full ZAP Wiki (Markdown) report
    -x report_xml     file to write the full ZAP XML report
    -J report_json    file to write the full ZAP JSON document
    -a                include the alpha passive scan rules as well
    -d                show debug messages
    -P                specify listen port
    -D                delay in seconds to wait for passive scanning 
    -i                default rules not in the config file to INFO
    -I                do not return failure on warning
    -j                use the Ajax spider in addition to the traditional one
    -l level          minimum level to show: PASS, IGNORE, INFO, WARN or FAIL, use with -s to hide example URLs
    -n context_file   context file which will be loaded prior to spidering the target
    -p progress_file  progress file which specifies issues that are being addressed
    -s                short output format - dont show PASSes or example URLs
    -T                max time in minutes to wait for ZAP to start and the passive scan to run
    -z zap_options    ZAP command line options e.g. -z "-config aaa=bbb -config ccc=ddd"
    --hook            path to python file that define your custom hooks

The following command starts a scan configured to

• spider the target for 2 Minutes
• generate a JSON-formatted report report.json
• generate a HTML-formatted report report.html
• generate and use a default zap configuration written to gen.conf

docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-weekly zap-baseline.py \
    -t https://targeturl -g gen.conf -r report.html -J report.json -m 2

Swingletree integration

A JSON report is required by the Swingletree OWASP Zap Plugin, which annotates the results to the Commit and Pull Request. Developers have quick access to the information through GitHub Check runs to fix the findings:

Summary

Baseline OWASP Zap scans can help to fix security issues as early as possible. A scan performed inside the CI pipeline helps to maintain security und and code quality each time the code is changed.

A full scan should not be replaced by baseline scans. Scheduling full scans (for example nightly) preferrably on production systems is mandatory.