Back to Articles

Running Burp Suite in CI/CD Pipelines with Headless Burp

[ View on GitHub ]

Running Burp Suite in CI/CD Pipelines with Headless Burp

Hook

Burp Suite is a powerhouse for manual security testing, but its GUI-first design makes it nearly impossible to run in automated pipelines—until now.

Context

Security testing traditionally happens at the end of development cycles, performed manually by specialists using tools like Burp Suite. This creates a bottleneck: developers ship code, security teams test it weeks later, vulnerabilities are discovered, and the expensive cycle of patching begins. The industry response has been “shift left”—catch security issues during development, not after deployment.

But there’s a problem. Burp Suite Pro, arguably the most comprehensive web application security scanner available, was designed for interactive use. It has a rich GUI, requires manual configuration, and produces reports meant for human consumption. CI/CD pipelines need the opposite: headless execution, programmatic configuration, and machine-readable output that can fail builds automatically. Headless Burp bridges this gap by providing extensions that enable Burp Suite’s scanning capabilities to run in headless mode via command-line, giving teams a path to integrate their existing Burp expertise into continuous security workflows.

Technical Insight

Post-Processing

Burp Suite Process

scan parameters

triggers

loads & starts

configures

configures

discovered URLs

raw findings

filtered results

JUnit/HTML/XML

XML Config File

Maven Plugin

Burp CLI Launcher

Headless Extension

Spider Tool

Scanner Tool

Filter Engine

Report Generator

CI/CD Pipeline

System architecture — auto-generated

Headless Burp provides extensions for scanner and proxy functionality, along with a Maven plugin for build integration. The scanner extension enables Burp’s spider and scanner tools to run in headless mode with programmatic configuration.

Instead of using Burp’s GUI, you define scan parameters in an XML configuration file. Here’s a minimal example that scans target URLs and generates an HTML report:

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <reportType>HTML</reportType>
    <targetSitemap><![CDATA[http://localhost:5432]]></targetSitemap>
    <scope>
        <url><![CDATA[http://localhost:5432/auth]]></url>
        <url><![CDATA[http://localhost:5432/users]]></url>
    </scope>
</config>

You invoke it by launching Burp with the extension in the classpath and passing configuration parameters:

java -Xmx1G -Djava.awt.headless=true \
-classpath headless-burp-scanner-master-SNAPSHOT-jar-with-dependencies.jar:burpsuite_pro_v1.7.31.jar burp.StartBurp \
--unpause-spider-and-scanner \
--project-file=project.burp -c config.xml

The --unpause-spider-and-scanner flag tells Burp to start scanning immediately rather than waiting for user interaction. The --project-file parameter enables Burp’s project state management, allowing you to resume scans or compare results across runs.

What makes this genuinely useful for CI/CD is the false-positive suppression system. Anyone who’s run automated security scans knows the problem: the same non-issues appear in every report, creating noise that trains teams to ignore security findings. Headless Burp lets you build a baseline by filtering out known false positives:

<false-positives>
    <issue>
        <type>5244416</type>
        <path>.*</path>
    </issue>
    <issue>
        <type>5247488</type>
        <path>.*bower_components.*</path>
    </issue>
</false-positives>

The type corresponds to Burp’s internal issue type identifier, and path accepts regex patterns. This means you can suppress all instances of a particular issue type globally, or only suppress it for specific URL patterns—like ignoring cookie security flags in third-party dependencies.

The reporting system generates JUnit XML output, which Jenkins and most CI servers can parse natively. This transforms security findings into test failures, making vulnerability detection a first-class part of your build pipeline. The extension also supports HTML and XML formats for human review.

A Maven plugin is also provided to integrate scans into build configurations, though the complete setup details would need to be referenced from the project documentation.

The proxy mode enables a different workflow: instead of pointing Burp at URLs to spider, you first capture traffic from functional tests by proxying requests through Burp, then scan the accumulated sitemap. This approach finds endpoints that aren’t linked in HTML (like API calls from JavaScript) and includes authenticated requests with valid session tokens—solving one of the hardest problems in automated security testing.

Gotcha

The biggest limitation isn’t technical—it’s licensing. Headless Burp requires Burp Suite Pro, which costs around $400 per user per year. For a CI/CD setup, you’ll need at least one license dedicated to your build server.

The project’s age is concerning. The documentation references Burp Suite Pro version 1.7.31 in examples, while PortSwigger currently ships much newer versions with potential API changes. The repository shows the extension was published to the BApp Store (PortSwigger’s official extension marketplace), which suggests some level of maintenance, but you’ll need to validate compatibility with current Burp versions before committing to production use.

Another limitation is scope: you’re constrained by Burp’s built-in scanning capabilities. If you need custom security checks beyond what Burp provides out of the box, you’ll need to write separate Burp extensions and manage their integration. Tools like ZAP with scripting support or Nuclei with YAML templates offer more programmatic extensibility for custom vulnerability detection.

Verdict

Use headless-burp if you already have Burp Suite Pro licenses and want to integrate Burp’s scanning into CI/CD pipelines without building custom automation from scratch. It’s particularly valuable for teams that have security specialists who work in Burp daily—the same issue taxonomy and false-positive decisions transfer directly to automated scans, reducing the learning curve. The JUnit reporting integration is genuinely useful for failing builds on vulnerability detection. Skip it if you’re starting from zero (ZAP is free and more actively maintained), if you need modern API-first scanning capabilities, or if the project’s maintenance status relative to current Burp versions makes you uncomfortable. For greenfield projects or teams without existing Burp expertise, OWASP ZAP with zap-cli or a SaaS solution like StackHawk will be easier to adopt and maintain.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/netsoss-headless-burp.svg)](https://starlog.is/api/badge-click/cybersecurity/netsoss-headless-burp)