Burpa: Turning Burp Suite Into a CI/CD Security Scanner

Hook

Burp Suite Professional is the gold standard for manual web app security testing, but automating it for CI/CD requires navigating two different REST APIs—one official, one community-maintained—that don't talk to each other. That's the problem burpa solves.

Context

Security testing in modern development pipelines faces a fundamental tension: the best security tools are built for human experts doing manual analysis, while CI/CD demands automation and repeatability. Burp Suite Professional exemplifies this challenge. It's arguably the most powerful web application security testing platform available, with sophisticated scanning engines and extensive attack surface coverage. But it was designed as an interactive proxy, not a headless scanner.

PortSwigger eventually released an official REST API for Burp Suite Professional, enabling programmatic scan control and authenticated scanning capabilities. However, it came with a glaring omission: no HTML report generation. Meanwhile, the community-maintained burp-rest-api extension (originally from VMware) could generate beautiful reports but lacked support for authenticated scans and modern API features. This created a gap for DevSecOps teams who needed both capabilities: automated scanning with proper authentication AND human-readable reports for security review. Burpa emerged as a Python wrapper that orchestrates both APIs simultaneously, providing the missing bridge between Burp Suite's interactive power and CI/CD automation requirements.

Technical Insight

Burpa's architecture is deceptively simple: it's essentially a coordination layer that makes API calls to two different services running inside the same Burp Suite instance. The official Burp Suite REST API handles scan submission and authenticated scans, while the burp-rest-api extension generates HTML/JSON reports. The tool uses python-fire to auto-generate its CLI from Python class methods, creating an elegant developer experience where the same code serves both library users and command-line consumers.

Here's a practical example of using burpa programmatically to scan an authenticated application:

from burpa import Burpa

# Initialize with both API endpoints
burp = Burpa(
    api_url='http://127.0.0.1:8090',  # Official Burp REST API
    api_port=8090,
    burp_rest_api_url='http://127.0.0.1:8080'  # burp-rest-api extension
)

# Configure authenticated scanning
auth_config = {
    'Username': 'testuser',
    'Password': 'testpass'
}

# Submit scan with authentication
scan_id = burp.scan(
    urls=['https://app.example.com/dashboard'],
    application_logins=auth_config,
    scope_file='scope.json',
    report_output_dir='./reports'
)

# Poll until completion (blocking)
burp.wait_scan_finish(scan_id)

# Generate HTML report via burp-rest-api extension
burp.report(
    scan_id=scan_id,
    report_type='HTML',
    output_file='./reports/scan_results.html'
)

The tool handles several non-obvious complications automatically. When you pass a file URL like https://example.com/api/users, burpa intelligently adds parent paths (/api/, /) to the scan scope—without this, Burp would only test that exact endpoint and miss related attack surface. It also manages the polling mechanism with configurable intervals, preventing your CI pipeline from hammering the API while waiting for long-running scans.

For CI/CD integration, burpa supports configuration via environment variables, making it container-friendly:

export BURPA_API_URL=http://burp-scanner:8090
export BURPA_BURP_REST_API_URL=http://burp-scanner:8080
export BURPA_API_KEY=your_api_key_here

# Scan multiple targets from a file
burpa scan --urls-file=targets.txt --report-output-dir=/reports

The dual-API architecture has an important implication: you're actually running three separate services (Burp Suite GUI/headless, official REST API, burp-rest-api extension), and they all need to be properly configured and running. The official API requires explicit configuration in Burp's settings with API key authentication, while burp-rest-api runs as a BApp extension that starts its own HTTP server. Burpa doesn't manage these dependencies—it assumes they're already running and accessible.

One clever design choice is how burpa handles report generation. The official API can retrieve scan issues in JSON format, but only basic machine-readable data. The burp-rest-api extension maintains its own internal state of scans and can render them as comprehensive HTML reports with request/response details, remediation guidance, and severity categorization. By coordinating both APIs, burpa gives you the best of both worlds: authenticated scanning capabilities from the official API and rich reporting from the community extension.

Gotcha

The biggest limitation is the setup complexity. You need Burp Suite Professional (a commercial license starting at $449/year per user), manual installation and configuration of the burp-rest-api extension, and both API services running simultaneously. There's no Docker image or automated setup script—you're manually configuring API keys, extension settings, and network endpoints. For teams expecting a simple npm install or pip install experience, this is a significant barrier.

More problematic is the scanner reset issue. The official Burp API has no endpoint to clear scanner state or reset between scans. If you need isolation between test runs (common in CI/CD), the documented approach is to completely stop Burp Suite and restart it via your process manager (systemctl, supervisord, or NSSM on Windows). This restart-everything approach adds significant time overhead to pipeline runs and feels architecturally wrong—you're bouncing an entire JVM process because there's no API endpoint for state cleanup. This limitation comes from Burp Suite itself, not burpa, but it's a real operational pain point when you're trying to run clean, isolated security scans in automated pipelines.

Verdict

Use if: You're already invested in Burp Suite Professional licenses and need to integrate those scans into CI/CD pipelines, especially when authenticated scanning is required. Burpa provides the cleanest Python interface available for orchestrating Burp's dual APIs, and the ability to generate HTML reports makes security review workflows much smoother than parsing raw JSON. It's particularly valuable if you have security engineers who already know Burp's scanning engine and want to leverage that expertise programmatically. Skip if: You don't have Burp Pro licenses and don't want the setup complexity of running multiple services. OWASP ZAP offers 90% of Burp's DAST capabilities with official Python APIs, Docker images, and zero licensing costs. Also skip if you need frequent scanner resets in CI—the restart-Burp-entirely workaround is too slow for rapid pipeline iterations. Consider commercial DAST platforms like StackHawk or Probely if you want turnkey CI/CD integration without managing Burp infrastructure yourself.