Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Burp Suite

Burp Suite is the tool a web-application tester reaches for first, and PortSwigger has held that position long enough that “running Burp against it” is shorthand for dynamic web testing the way “Nessus scan” is shorthand for host vuln scanning. It is an intercepting proxy with a scanner bolted on, plus a workbench of tools for tampering with HTTP by hand. PortSwigger built it in Birmingham, UK, founded by Dafydd Stuttard in 2008, and the company is still independent. In June 2024 it took its first outside money, a roughly $112M minority investment from Brighton Park Capital, with PortSwigger keeping control. That matters here only because vendor ownership is the thing that rots fastest in tool documentation, and the honest 2026 answer is that nobody acquired PortSwigger.

Schematic of an intercepting proxy sitting between a browser and a web application, with HTTP requests paused mid-flight and a scanner branch auditing them for injection points.

The product lineup is where most stale references break. There are three editions, and one of them changed names in April 2025. Burp Suite Professional is the per-seat desktop application a pentester runs, the proxy/Repeater/Intruder workstation with Burp Scanner included. Burp Suite DAST is the server-deployed product for automated scanning at scale across many sites; this is the one that used to be called Burp Suite Enterprise Edition. PortSwigger renamed it because the old name made buyers think it was just a license tier of Pro rather than a separate DAST platform. If a document calls the enterprise product “Enterprise Edition” in present tense, it is a year out of date. Community Edition is the free build: the manual tools work, but Scanner automation is absent and Intruder is throttled hard enough to be useless for real work.

Versioning moved to a calendar scheme, so there is no fixed “latest” number worth quoting. Pro and Community share a release train (2026.2.3, 2026.3.3, 2026.4 landed across the first months of 2026); DAST runs its own line (2026.5 and on). The old 2023.x-style numbers are gone. Cite the year, not a frozen point release, because PortSwigger ships roughly monthly and any specific number is wrong within weeks.

Where it lands in the federal flow

Burp is the dynamic half of application security testing. The SAST scanners in this fleet (Fortify, Checkmarx, SonarQube) read source; Burp tests the running application from the outside, authenticated and unauthenticated, which is the only way to see runtime authorization failures, business-logic abuse, and injection that source review keeps missing. That distinction is the whole reason it exists in the toolchain. Burp is not SAST and it is not software composition analysis. If you want dependency and SBOM coverage, that is Anchore, Trivy, or Snyk, and conflating the two is a common SSP-narrative error.

In NIST SP 800-53 terms the primary home is SA-11, Developer Security Testing and Evaluation, where dynamic analysis is an explicit expected activity; SA-11(8) calls out dynamic code analysis by name. The recurring web-application scan obligation lives under RA-5, Vulnerability Monitoring and Scanning. For DAST wired into a pipeline, SA-15 development-process expectations come into play lightly, and scan configuration baselines touch CM-6 only at the edges. ATO web applications and FedRAMP systems routinely need a web-app or DAST scan as assessment evidence, and Burp findings are a standard way to produce it. Cadence splits by edition: DAST runs per-release or per-sprint in CI, while Pro gets pulled in for deep manual testing during pentest and assessment events.

Capability Community Professional DAST
Burp Scanner (crawl + audit automation) No Yes Yes
Manual proxy / Repeater / Intruder Yes (Intruder throttled) Yes Yes
CI/CD integration (Docker, Jenkins, GitHub Actions, GitLab) No Limited Yes
Multi-site / fleet scanning at scale No No Yes
Burp AI features No Yes Yes
Central console, RBAC, SSO No No Yes
Licensing model Free Per-user seat Server / enterprise

Treat that table as the disambiguator for the rebrand and the Community throttling in one place. The free edition is fine for learning the proxy; it is not a scanner.

Burp AI, Scanner, and the out-of-band problem

Burp AI is real and shipping, not a roadmap promise. It arrived in Pro around the 2025.2 line and is present in DAST. The features cover autonomous investigation of Scanner findings (Explore Issue), plain-language explanation of unfamiliar headers or technologies (Explainer), AI-generated recorded login sequences for authenticated scanning, and false-positive reduction on broken-access-control checks. It runs on a credit model: Pro seats come with a free credit allotment, purchased credits expire after twelve months, and credits are per-user and don’t pool. My read, and this is opinion: the auth-sequence recording is the genuinely useful piece, because authenticated scanning of SSO and MFA apps is the single most painful thing to configure in Burp and anything that reduces that pain earns its keep. The triage and investigation features are evolving, credit consumption surprises people, and I would not bank an assessment on the AI’s accuracy yet. Treat it as a power tool with a metered cord, not a finished feature.

Burp Scanner is the engine both Pro and DAST share. It crawls, then audits, and its strength is injection-class coverage: SQLi, reflected and stored XSS, SSRF, XXE, path traversal, command injection, CSRF. The piece that distinguishes it from cheaper scanners is Burp Collaborator, the out-of-band (OAST) infrastructure that catches blind and asynchronous vulnerabilities by watching for callbacks the target makes to a server you control. For sensitive environments this detail matters: Collaborator can be self-hosted as a private instance, so an air-gapped or classified system isn’t forced to phone home to PortSwigger-hosted infrastructure. If your environment can’t talk out, stand up a private Collaborator or you lose the OAST findings entirely.

Deeper: the scanner finds what it models, the operator finds the rest. Burp Scanner (the automated DAST engine, shared by Pro and Enterprise-tier DAST) and the manual proxy/Repeater/Intruder workbench are not redundant tools; they cover different failure classes. The scanner crawls a target and fires a fixed payload library at the parameters it discovers, so it is strong on injection-class bugs it can pattern-match and weak on anything that requires understanding application intent. The manual workbench is where a tester replays a request in Repeater with a swapped session token to prove broken access control, or fuzzes a workflow step-skip in Intruder that no crawler would ever reach because it never logged in as two roles at once. The Enterprise-tier DAST product is the scanner scaled out across a fleet with CI/CD hooks, a console, RBAC and SSO; what it buys you is coverage cadence and dashboards, not a smarter engine. Buying DAST-in-CI and assuming it replaces a tester driving Pro by hand is the most expensive misread of this product line, because the bugs that sink a federal assessment are precisely the ones the automated engine does not model.

Operational notes and where it bites

DAST deploys as a server with Burp Scanner running from Docker containers in CI: Jenkins, GitHub Actions, GitLab CI, Azure DevOps, TeamCity. It exposes a GraphQL API to drive scans programmatically and pushes issues into Jira or GitLab, with RBAC and SSO on the enterprise console. The honest list of where teams trip:

  • Scope discipline. An unscoped active scan pointed at shared or production infrastructure can do real damage. Active scanning sends malformed and attack traffic; it is not a passive read.
  • Authenticated coverage. Login-sequence recording is fiddly and is a top support burden, especially against SSO and MFA flows. Budget time for it.
  • Collaborator egress. Environments that can’t reach PortSwigger-hosted infrastructure need a private Collaborator, or blind-vuln detection silently goes dark.
  • Evidence handling. Burp produces findings; a human still triages false positives, and those findings feed eMASS and the POA&M as artifacts. Burp is not going to file your POA&M for you.

On compliance reporting, get this right, because the older roadmap oversold it. As of the current DAST documentation, the built-in compliance report templates are OWASP Top 10 (2025) and PCI DSS v4.0.1. The 2023 roadmap floated NIST, FedRAMP, and OWASP ASVS templates; do not state those as shipping features without checking the current docs, because the report list has not landed where the roadmap promised. The accurate framing is that Burp output is evidence you map into your RMF or FedRAMP package, not a button that emits a FedRAMP-formatted report.

And the FedRAMP trap, stated plainly: Burp is self-hosted software. Pro is a desktop app, DAST is server-deployed, and neither is a multi-tenant cloud SaaS. So Burp does not carry a FedRAMP cloud authorization, and you will not find it on the FedRAMP Marketplace as an authorized offering, because that is not what it is. It is the tool you run against a FedRAMP or DoD system to generate assessment evidence. Don’t write “Burp is FedRAMP authorized” in an SSP. Write that Burp produced the DAST scan results supporting the assessment.

Here is the opinion worth arguing about. For most federal web-application ATO work, a competent tester driving Burp Pro by hand will out-find unattended DAST-in-CI on the bugs that actually sink an assessment: broken access control, privilege escalation across roles, business-logic abuse that no automated crawler models. Buying DAST Enterprise for coverage dashboards and then not staffing anyone to triage the output is spending money on a number that goes up. That calculus flips when you have a high-change microservice estate with dozens of services shipping weekly, where automated per-release scanning is the only thing that scales. For a handful of stable applications, the tester beats the pipeline.

Sources

Adjacent material on this site