Burp Suite DAST 2026.10 Adds Persistent Triage Rules and API Retesting

PortSwigger has released Burp Suite DAST 2026.10, an update for teams that include dynamic application security testing in their software quality process. The stable release arrived on October 8, 2026. Its main focus is a familiar problem for security and QA teams: handling recurring findings after the first scan. ([portswigger.net](https://portswigger.net/burp/releases/dast-2026-10))

The release adds issue management rules. When a tester marks an issue as a false positive, accepts the risk, or changes its severity, Burp Suite DAST can apply that decision at one of three scopes: the individual issue, the same issue type at a specific URL, or the same issue type anywhere on the site. It then creates a rule that carries the decision into future scans. ([portswigger.net](https://portswigger.net/burp/releases/dast-2026-10))

Why persistent triage matters to QA teams

Automated security scanners are intentionally sensitive, so they can report findings that a team has already reviewed over and over. Without a lasting record of the decision, testers may revisit the same accepted risk or false positive during every scan cycle. The result is dashboard noise and less visibility into new regressions.

These rules turn a one-time triage decision into reusable scan behavior. Human review still matters, but the process becomes more consistent, and security engineers get a clearer audit trail showing why particular findings receive different treatment.

Scope requires care. A site-wide rule can cut noise quickly, yet it may also suppress a legitimate issue after the application changes. Teams should start with narrow, URL-specific rules and review broader rules regularly through their vulnerability-management process.

GraphQL retests bring verification into CI workflows

Burp Suite DAST 2026.10 can also trigger issue retests through the GraphQL API. Teams can check whether a reported vulnerability was fixed without starting a complete scan or opening the DAST interface. ([portswigger.net](https://portswigger.net/burp/releases/dast-2026-10))

That fits development teams that already connect test results with issue trackers and deployment pipelines. Once a developer submits a fix, an automation job can request a targeted retest and attach the result to the relevant ticket. Verification then happens sooner, without the cost and delay of running a full application scan for every small change.

For QA engineers, this makes the definition of done more concrete. Changing the code does not, by itself, close a security defect. The team can require a successful retest, alongside functional tests and regression checks, before moving the issue to a verified or resolved state.

Performance and coverage improvements

PortSwigger says the release reduces scan time and disk usage. It also improves coverage on HTTP/2 sites by retrying requests when a server closes a connection during scanning. ([portswigger.net](https://portswigger.net/burp/releases/dast-2026-10))

These changes can affect day-to-day operations. Shorter scans make DAST easier to run against pull-request environments and short-lived staging systems. Lower disk usage helps teams operating scanners in containerized or self-hosted infrastructure. The revised retry behavior should reduce misleading gaps in results for applications that depend heavily on HTTP/2 connection handling.

Other fixes worth checking

The release fixes several edge cases involving OpenAPI and SOAP definitions. OpenAPI paths without a leading slash are now scanned at their declared path. Very large numeric bounds no longer cause scans to fail, and WSDL files with unusable service addresses can still expose operations for scanning. Jira integration rules that use the same custom field also receive a correction. ([portswigger.net](https://portswigger.net/burp/releases/dast-2026-10))

What teams should do next

• Review triage policy: Decide who can create broad issue-management rules and how often the team will review them.
• Connect retests to remediation: Use the GraphQL API to trigger targeted verification after fixes reach a test environment.
• Measure scan efficiency: Compare scan duration, storage use, and repeated findings before and after the upgrade.
• Test API definitions: Re-run scans for OpenAPI and SOAP services that previously had incomplete coverage or failed unexpectedly.

Burp Suite DAST 2026.10 is not a sweeping redesign. It addresses a costly part of security testing at scale: handling decisions that would otherwise be repeated scan after scan. By preserving triage decisions and exposing remediation checks through an API, the release makes DAST more useful as a repeatable quality gate instead of a standalone security report.