Security Scan implementation as part of CI – Continuous Integration

Background: There is no need to explain that it has become imperative to implement security scanning as part of CI process.

Tool:  Portswigger’s Burp Suite , Jenkins

One line statement on how it works :  Burp Suite acts as proxy between client and service and scans all request/response to find security vulnerability.

Obviously, the tool is much more powerful than what I stated in above line and provides range of options to handle various use cases.

Steps to integration Burp Scan in CI using Jenkins: 

1. Install Python/Jython plug in “Carbonator” into Burp.  —> When one launches burp with carbonator options, it can scan all traffic automatically, once traffic stops flowing for 30 seconds.

Without carbonator, you need to generate report manually, which is then impossible to integrate in CI.

2.  Use pipeline to launch Burp Scan —> Pipeline should launch two tasks in parallel.

a) First task starts burp scanner on specific port on a slave.

b) Second task launchs automated flow (UI automation) on same flow that uses Burp as proxy

Once task “b”, finishes , Task “a” creates and publishes report.

3. Review report to see if it identified any new issue.

Task “a” :  Command to launch Burp with carbonator:

java -jar c:\burp\burpsuite_pro_1.7.33.jar  --project-file=burp/test.burp  --config-file=burp/projectOption.json --user-config-file=burp/UserOption.json --unpause-spider-and-scanner https 443 /

project-file:  Use a non existing file so that the test report is clean and consistent and does not have data from previous reports. The file , if not present, gets created on the fly.

cont-file:  Set up project config file based on your requirement. you can run Burp manually and setup all the required data for you test. Export project config as Json to create this file. 

user-config-file:  Set up User config file based on your requirement. you can run Burp manually and setup all the required data for you test. Export User config as Json to create this file.

unpause-spider-and-scanner  —  This option start spider and scanner automatically when Burp launches.

https:  http or https can be used as protocol to test  Url scope for testing

443: Port on which the service is running

/  — Starting folder for test scope:

https  443 /   —> This will create as in-scope url

https 443 /test   —> This will create as in-scope url

Additional information: can be modified to suite your needs.

This script can typicaly be found @

  /Users//.BurpSuite/bapps/e3a26fff8e1d401dade52f3a8d42d06b/  on Mac

  /Users//.BurpSuite/bapps/e3a26fff8e1d401dade52f3a8d42d06b/ on Windows.

Recommended changes: 

1. Change Time out from 30 seconds to 30 minutes   [ Other wise, Automated test should start within 30 seconds of  Burp scanner start ].

2. Out of Scope Url: Default Carbonator options does not provide command line option to include “Out of Scope Url” . Based on knowledge on the service you are testing, you can disable scanning of various urls by modifying  some lines.

Ex: If you want to include three URLs in “Out of Scope” group

Added three lines as we needed to include three URL as out of scope. This was added after below three lines.

#add to scope if not already in there.

if self._callbacks.isInScope(self.url) == 0:





Value for these variables are set below in the same code after line

self.url = URL(self.scheme,self.fqdn,self.port,self.path)

Added lines:
self.exclude1 = URL(self.scheme,self.fqdn,self.port,'/api/logs')
self.exclude2 = URL(self.scheme,self.fqdn,self.port,'/javascripts')
self.exclude3 = URL(self.scheme,self.fqdn,self.port,'/login')



SSLv3 vulnerability: POODLE

POODLE :  Padding Oracle On Downgraded Legacy Encryption : – This vulnerability allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack.

Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).

POODLE affects older standards of encryption, specifically Secure Socket Layer (SSL) version 3. It does not affect the newer encryption mechansim known as Transport Layer Security (TLS).

How to test this against your Server:

openssl s_client -connect <server>:443  -ssl3

If above command succeeds, it indicates that SSLV3 is enabled on your server.

Script @

To fix this, disable sslV3 on your server.

How to fix this on Apache:

> SSLProtocol All -SSLv2 -SSLv3                   <- Removes SSLv2 and SSLv3 from Config

> service apache restart                          <- Restart server