Running Burp Suite in CI/CD: How Headless-Burp Brings DAST to Your Build Pipeline

Hook

Most security teams run Burp Suite manually days or weeks after code ships. What if your build could automatically fail when shipping a SQL injection vulnerability—before it reaches production?

Context

Dynamic Application Security Testing (DAST) has traditionally lived in a separate world from continuous integration. Security professionals fire up Burp Suite Professional, manually configure scanning parameters, click through authentication flows, and generate reports days after developers have moved on to new features. By the time vulnerabilities are discovered, the original developer context is lost, and fixes require expensive context-switching.

This disconnect exists because tools like Burp Suite were designed for interactive pentesting, not automation. They require GUI interaction, don't produce machine-readable output by default, and lack the declarative configuration needed for repeatable pipeline execution. NetsOSS's Headless-Burp bridges this gap by wrapping Burp Suite Professional's scanning engine with command-line interfaces, XML-based configuration, and JUnit report generation. It's not a replacement for Burp Suite—it's an automation harness that lets you run the same enterprise-grade scanner that security professionals trust, but triggered automatically on every merge to main.

Technical Insight

Headless-Burp's architecture revolves around two custom Burp extensions and a Maven plugin that orchestrates them. The extensions run inside Burp Suite's JVM, programmatically controlling the spider and scanner components that would normally be manually operated through the GUI. The Maven plugin handles process lifecycle management, configuration injection, and build integration.

The core scanning workflow starts with an XML configuration file that defines your scan parameters. Here's a realistic example for scanning a Spring Boot application:

<config xmlns="https://nets.eu/headless-burp-scanner">
  <targetSitemap>
    <url>http://localhost:8080/api/users</url>
    <url>http://localhost:8080/api/orders</url>
  </targetSitemap>
  
  <scope>
    <include>http://localhost:8080/.*</include>
  </scope>
  
  <exclusions>
    <exclude>http://localhost:8080/health</exclude>
    <exclude>http://localhost:8080/metrics</exclude>
  </exclusions>
  
  <falsePositives>
    <issue>Cross-site scripting (reflected)</issue>
    <path>/api/legacy/display</path>
  </falsePositives>
  
  <reportType>junit</reportType>
</config>

This configuration demonstrates one of Headless-Burp's killer features: false-positive suppression at the configuration level. The falsePositives block lets you document why certain vulnerability reports should be ignored (perhaps that legacy endpoint is already behind additional WAF rules) without losing the alert entirely—it's still reported but won't fail the build.

The Maven integration looks like this in your pom.xml:

<plugin>
  <groupId>eu.nets.burp</groupId>
  <artifactId>headless-burp-scanner-maven-plugin</artifactId>
  <version>1.0.8</version>
  <configuration>
    <burpSuite>/path/to/burpsuite_pro.jar</burpSuite>
    <configFile>security-scan-config.xml</configFile>
    <reportType>junit</reportType>
    <reportOutputDir>target/security-reports</reportOutputDir>
  </configuration>
  <executions>
    <execution>
      <phase>integration-test</phase>
      <goals>
        <goal>scan</goal>
      </goals>
    </execution>
  </executions>
</plugin>

When Maven reaches the integration-test phase, the plugin launches Burp Suite in headless mode (using Java's -Djava.awt.headless=true), loads your configuration, and begins scanning. The proxy extension can replay recorded traffic from functional tests, which solves one of DAST's hardest problems: authenticated scanning. If your Selenium or REST Assured integration tests run first, Headless-Burp can capture that authenticated traffic and use it as the crawl basis, ensuring the scanner reaches authenticated endpoints without complex authentication configuration.

The scanner extension generates a JUnit XML report that Maven's Surefire plugin understands natively. Each vulnerability becomes a test failure with severity and remediation details. This means your CI system treats security vulnerabilities identically to failing unit tests—blocking merges, sending notifications, and preventing deployment. The HTML reports generated alongside the JUnit output give security teams the familiar Burp-style vulnerability details they expect, complete with request/response examples and remediation guidance.

One architectural detail worth noting: Headless-Burp doesn't reimplement any scanning logic. It's purely an orchestration layer around Burp's existing spider and active scanner. This means you get the same vulnerability detection quality that makes Burp Suite the industry standard, including its sophisticated SQL injection, XSS, and business logic testing capabilities. The trade-off is that you inherit Burp's limitations too—it's still a general-purpose web scanner that won't catch application-specific logic flaws without custom configuration.

Gotcha

The most significant limitation is the Burp Suite Professional license requirement. At roughly $400-500 per user annually, this isn't expensive for professional penetration testers, but it becomes a serious cost consideration when you need licenses for CI/CD runners. Some teams have creatively worked around this by sharing a single headless license across build agents, but PortSwigger's licensing terms are somewhat ambiguous about this scenario. You'll need to engage with their sales team to understand compliant usage at scale.

Scanning performance can be problematic for large applications. Burp Suite's active scanner is thorough but slow—a comprehensive scan of a moderately sized application can take 30-60 minutes or more. This duration doesn't fit well in pre-merge CI pipelines where developers expect feedback in minutes. The typical solution is running Headless-Burp in nightly or weekly security pipelines rather than on every commit, but this reduces its value as a shift-left tool. There's no good workaround beyond carefully scoping your scans to changed endpoints or accepting longer feedback cycles. The documentation around optimizing scan performance is sparse, leaving teams to rediscover best practices through trial and error.

Verdict

Use Headless-Burp if: You already have Burp Suite Professional licenses and want to leverage that investment in automated pipelines; you're building Java/Maven applications where the plugin integration is seamless; you need sophisticated false-positive management to prevent alert fatigue; or your security team already trusts Burp's scanning quality and wants consistency between manual and automated testing. It's particularly valuable when you have complex authenticated workflows that can be captured via proxy replay. Skip if: You don't have existing Burp Pro licenses and need a budget-friendly solution (OWASP ZAP is the obvious alternative); you need sub-10-minute scanning for pre-merge checks (consider focused tools like Nuclei or Semgrep for faster feedback); you're working primarily in non-Java ecosystems where the Maven dependency feels heavy; or you want a tool with modern API-first design and active community support. The project's moderate GitHub activity suggests maintenance is ongoing but not aggressive, which may concern teams wanting cutting-edge features or rapid bug fixes.