DevSecOps – Integrating Vulnerability Scanning Within the CI/CD Pipeline Part 1

Recently I made a slight career change, a shift into DevSecOps as opposed to pure sec – i’m excited and loving it so far. My first task – integrate security scanning within the pipeline. Disclaimer: This article is very beginner friendly.

Our tech stack that supports our CI/CD consists of Kubernetes, docker and Gitlab. I didn’t find much on getting automated security scanning going using Gitlab so I basically started from scratch.

Picking a tool

Coming off a pentesting background i’m comfortable with OWASP ZAP as well as Burp Suite. Burp Suite has recently released an enterprise edition that touts CI integration but my gut was telling me that it would be easier with ZAP, as there may be more support online if (turned into when) I run into difficulties. The first thing to do now was find a Docker container that had ZAP installed. This did the trick.

Getting Started

I found a container online but I had no idea how Gitlab worked. I knew Gitlab was what we used for our entire SDLC lifecycle but I was not sure exactly how the CI/CD integration worked. Turns out the way it works is as follows:

Once you have commited your code, the code is compiled and a build is created. That build is run by Gitlab and Gitlab carries out a specific set of jobs that one can define using a YAML file. A YAML file is basically a configuration file that tells the Gitlab runners (carrying out the jobs) what to do. In our case it will need to tell the runners to kick off an automated scan. Remember, the idea here is to get a scan going every-time a developer commits a piece of code. If the scan picks up any HIGH sev vulnerabilities, the build should fail.

Configuring ZAP

ZAP needs to be able to kick off a scan automatically and fail the build if a High or Critical vuln is discovered. The following does the job:

 

!/bin/bash
 zap-cli --verbose quick-scan -sc --start-options '-config api.disablekey=true' \
 https://xxxx.xxxx.xxx.xxx \
 -l Informational | tee scan_result.txt; alerts=cat scan_result.txt | grep 'High|Critical' | (wc -l); echo $alerts
 Get Results
 if [ $alerts -gt 0 ]; then
   echo "$alerts findings. Build failing"
   exit 1
 else
   exit 0
   echo "success - no findings identified"
 fi

Save this as shellscript in your repo. In my case I am using Gitlab – So the next step is to tell the Gitlab runner what to do by creating a Gitlab CI yaml file. The below does the trick.

image: docker-registry.public-xxxxx.xxxxx.xxxxx/owasp/zap2docker-weekly

stages:
  - zap
 
Scan:
 stage: zap
 tags: [ kubernetes-deploy ]
 script:
   - ./quick-scan-zap.sh<br /><br /><br />
Boom!