Dynamic application security testing finds the vulnerabilities that only appear when an application is running. It crawls live endpoints, submits crafted requests, follows authentication flows and reports what a real attacker would actually reach. The problem is rarely a single scanner. Most security programs run more than one DAST tool, inherited from acquisitions, team preferences or coverage gaps, and each tool ships its own console, its own scheduling model, its own severity scale and its own webhook format.
Once a program crosses a few dozen web applications, that fragmentation becomes the bottleneck. An AppSec engineer logs into Acunetix to check one set of targets, into Invicti to check another and into Burp Suite Enterprise for a third, then exports three spreadsheets and reconciles them by hand. The scans run, but the program does not scale, because no one has a single view of which applications were tested, how recently and what the live findings are.
This article looks at DAST from the vendor ecosystem angle. It covers which dynamic scanners PMAP connects to, how authenticated scanning and scope control work across vendors, how remote scans are launched and stopped from one place, and how findings from different DAST tools land in one normalized model. The goal is a DAST program that grows with your application portfolio instead of fracturing along vendor lines.
Why DAST Tools Multiply and Coverage Fragments
DAST adoption rarely starts as a single platform decision. One team buys Acunetix for a customer-facing web app. Another inherits Invicti through a merger. A penetration testing group standardizes on Burp Suite Enterprise because it matches the manual tooling their testers already use. Each choice was reasonable in isolation. Together they create a coverage map that no one can read at a glance.
The fragmentation shows up in concrete ways. Severity is the first. Each vendor assigns its own risk label to a finding, and those labels do not line up. A finding that one scanner calls high another might call medium, so a portfolio-wide ranking built from raw vendor output is misleading before triage even begins. Scheduling is the second. Every tool has its own recurring-scan configuration, which means there is no single answer to the question of when each application was last tested. Identity is the third. Authenticated scanning is configured per tool, so the login sequence that lets a scanner reach the post-login attack surface lives inside whichever console set it up, invisible to everyone else.
PMAP addresses this through its universal connector hub. The integration domain manages the full lifecycle of every external system the platform speaks to, and dynamic scanners are one category inside that hub alongside VM scanners, SAST, SCA and the rest. A single integration record stores the credentials and configuration for each DAST tool, and the platform dispatches vendor-specific logic through a registry of connector archetypes. That design means adding a second or third DAST vendor does not add a second or third operating model. It adds another connector to the same hub.
For the broader picture of how this connector layer is built and why it matters, see the pillar on the security integration layer. This article stays focused on the dynamic testing slice of that layer.
The DAST Connectors PMAP Speaks To
PMAP groups its integrations into categories, and the DAST category contains three connector types: acunetix, invicti and burp_dast. These are the three dynamic application scanners the platform speaks to natively. Each is a distinct vendor with its own API surface, and each gets its own connector package inside the integration domain so vendor quirks stay isolated from the core.
All three are built as ScannerConnector archetypes. In PMAP’s design, a ScannerConnector is a connector that supports remote scan create, read, update and delete plus a results fetch. That archetype is shared with the VM scanners such as Nessus, Tenable and Qualys, which is the technical reason a DAST scan and a VM scan can be driven through the same wizard and the same control surface. The connector type differs. The operating model does not.
Because the connectors self-register through the platform’s registry, the type catalog that drives the add-integration wizard is generated rather than hardcoded. When you open the wizard, the DAST category appears with its three vendor options, each carrying its own auth-field and config-field descriptors. There is no separate, bespoke screen per DAST vendor. The same schema-driven form renders Acunetix, Invicti and Burp from their respective definitions.
Acunetix and Invicti as Remote Scan Connectors
Acunetix and Invicti are both first-class remote scan connectors in PMAP. The platform’s remote scan management capability, the V2 vendor-agnostic scan wizard, explicitly covers DAST vendors alongside the VM scanners. That means the same operations exist for a dynamic scan as for a network scan: list scans on the vendor, create a scan, update it, copy it, launch it, pause it, resume it, stop it, delete it and poll its status.
The practical effect is that an AppSec engineer manages an Acunetix scan and an Invicti scan from the same controls. There is no need to learn two separate scan lifecycles. PMAP creates a remote scan record on its side when a scan is launched, and that record tracks the vendor scan through to completion. When a scan finishes, its findings can be imported into a chosen PMAP project, respecting the severity threshold configured on the integration. The acunetix and invicti connector packages hold the vendor-specific client and mapper logic that makes this uniform behavior possible without flattening the differences between the two tools.
Where Burp Suite Enterprise Fits
Burp Suite Enterprise is the third DAST connector, registered as burp_dast. It is one of the external systems PMAP connects to in the DAST category, and it sits in the same ScannerConnector family as Acunetix and Invicti. For teams whose manual penetration testing already runs on the Burp ecosystem, this matters: the automated Burp Suite Enterprise scans feed into the same normalized model as the other two scanners, so dynamic findings from Burp do not live in a separate silo from the rest of the AppSec program.
The shared archetype is the point. Whether a finding originated in Acunetix, Invicti or Burp, it arrives through a ScannerConnector, flows through a vendor-specific mapper and lands as a normalized finding. The console you triage in does not change based on which scanner ran.
Authenticated Scanning With Login Sequences
Most of an application’s real attack surface lives behind a login. An unauthenticated DAST scan sees the front door and little else. To test the account pages, the admin panels and the privileged workflows where the serious vulnerabilities hide, the scanner has to authenticate first, and that is what a login sequence does. It is a recorded set of steps that drives the scanner through the login flow so it can reach the post-login surface.
PMAP exposes login sequences as a dedicated DAST capability. For a DAST integration, the platform can list the recorded login sequences available on the vendor, and it can attach a specific login sequence to a specific scan for authenticated scanning. That second action is the operational hinge. It connects an existing credentialed flow to the scan you are about to run, so the scan tests the authenticated application rather than stopping at the login wall.
Handling login sequences at the platform level, rather than inside each vendor console, has a direct coverage benefit. The decision about which scans run authenticated and against which login flow becomes visible in one place. An AppSec lead can see that the customer portal scan is authenticated and the marketing site scan is not, and reason about whether that matches the risk. When authenticated scanning is buried in three separate consoles, that reasoning is impossible to do quickly. OWASP’s Web Security Testing Guide treats authenticated testing of session management, access control and authorization as core to dynamic testing, and login-sequence handling is what makes that testing reachable at scale.
Controlling Scan Scope on the Vendor Side
A DAST scan is only as good as its scope. Point a scanner at too narrow a target and it misses live endpoints. Point it too broadly and it wanders into third-party domains, staging systems or destructive actions it should never touch. Scope is the control that keeps a dynamic scan both thorough and safe, and it has to be managed per scan because every application has a different boundary.
PMAP reads and writes DAST scan scope on the vendor side. The capability exposes the URL scope for a given scan as an include list and an exclude list, and it supports both reading the current scope and updating it. The read path lets you confirm what a scan will actually cover before you launch it. The write path lets you adjust the boundary, adding URL patterns that must be tested and excluding URL patterns that must be left alone, without leaving the platform to do it inside the vendor console.
Doing this from one place changes how scope is governed. Instead of scope living as tribal knowledge inside whichever tool configured a given application, the include and exclude lists for every DAST scan are reachable through the same surface. When a new section of an application ships, the team updates the scope for that scan in one action. When a sensitive endpoint must be kept out of automated testing, the exclusion is set and visible. NIST SP 800-115 on technical security testing emphasizes that test scope and rules of engagement should be defined and documented, and platform-level scope control is the operational form of that guidance for an at-scale DAST program.
Vendor Schedules vs PMAP-Side Schedules
There are two distinct ways a DAST scan can be scheduled in PMAP, and they answer different questions. Understanding the split is what keeps an at-scale program from double-scanning or, worse, silently not scanning at all.
The first is the vendor-side schedule. PMAP provides full create, read, update and delete control over recurring scan schedules that live inside the DAST vendor itself, and this supports the recurring scan configurations of Acunetix, Invicti and Burp. A vendor schedule means the scanner runs the scan on its own cadence using its own engine, exactly as it would if configured directly in the vendor console, except that the configuration is now managed from PMAP. This is the right model when you want the scanner to own the recurring execution and you simply want central visibility and control over that recurrence.
The second is the PMAP-side schedule. Every integration has its own cron schedule that drives PMAP’s background scheduler, which auto-imports completed scans. The scheduler ticks every minute, evaluates each integration’s cron expression and fires the import pipeline for any integration whose schedule is due, writing a schedule-log entry each time. A PMAP-side schedule does not run the scan on the vendor by itself in the way a vendor schedule does; it governs when PMAP pulls and imports completed results on its own cadence, and it gives you a run history with findings-imported counts.
The practical guidance is to be deliberate about which layer owns recurrence for each application. Use vendor schedules when the scanner’s own engine should drive the cadence. Use the PMAP-side schedule and its log to govern import timing and to keep an auditable record of what was imported when. Mixing the two without intent is how teams end up with redundant scans or stale findings.
Launching, Pausing and Stopping DAST Scans Remotely
The day-to-day of a DAST program is not configuration. It is control. A scan needs to start before a release, pause when it is hammering a fragile staging environment, resume once that environment recovers and stop entirely when a test window closes. If those controls live in three different vendor consoles, the program is slow by construction.
PMAP’s remote scan management capability gives one control surface for all of this. The V2 scan wizard supports list, create, update, copy, launch, pause, resume, stop, delete and poll across the supported scanners, and that set explicitly covers the DAST vendors. So an engineer launches an Acunetix scan, pauses an Invicti scan and stops a Burp scan from the same place, with the same verbs, without context-switching between three tools.
This matters most under time pressure. When a release is waiting on a clean scan, the engineer who can launch and watch the scan from one console moves faster than the one juggling vendor logins. When an automated scan starts overloading a shared environment, the engineer who can pause it in one click contains the blast radius immediately. Centralized scan control is not a convenience feature for an at-scale program. It is what lets a small AppSec team operate a large DAST footprint.
To work through the hands-on sequence of connecting a DAST tool and running a scan end to end, the practitioner guide on running a DAST scan with Acunetix and Invicti walks through it step by step.
Normalizing DAST Findings Into One Severity Model
When three scanners report on the same application, they will not agree on how serious anything is. Acunetix, Invicti and Burp each assign severity using their own internal logic, and a portfolio view built from raw vendor labels mixes three incompatible scales. The result is a ranking that cannot be trusted, because a high from one tool does not mean the same thing as a high from another.
PMAP resolves this with severity governance. Each connector produces a normalized severity through its own mapper, and PMAP never persists the vendor severity as authoritative. Every DAST finding flows through the connector’s mapper into a single severity model, and from there through a threshold filter that discards findings below the configured minimum on import. After import, an optional rule engine can override severity further based on context. The vendor’s opinion is an input, not the verdict.
The payoff is a finding set you can rank across vendors. A critical web finding is a critical web finding whether Acunetix, Invicti or Burp reported it, because all three were mapped into the same scale before they reached your triage queue. That is what makes the question of which scanner caught more useful findings actually answerable, and it is what lets remediation prioritize by genuine risk rather than by which tool happened to shout loudest. Aligning severity to a shared model also makes it practical to relate dynamic findings back to frameworks like the OWASP Top 10, where the category matters more than any single vendor’s label.
Deduplicating Web Findings Across DAST Tools
Severity normalization solves the ranking problem. It does not solve the volume problem. When two DAST tools scan overlapping parts of the same application, they will both report the same underlying issue, and without deduplication every triage queue inflates with copies of findings the team has already seen.
PMAP’s import pipelines are idempotent and deduplicate by design. Findings are matched by a fingerprint, and re-importing the same vendor scan produces no duplicates. The same fingerprint matching applies when findings overlap across tools, so the same real web vulnerability collapses toward one tracked issue rather than spawning a copy per scanner and per re-scan. Raw vendor payloads are archived in object storage so the original evidence is preserved for replay and audit even after deduplication.
For an at-scale DAST program this is the difference between a manageable backlog and an unmanageable one. Scans run on a recurring cadence, applications are tested by more than one tool, and without idempotent imports each cycle would pile fresh duplicates onto the queue. Because the pipeline dedups on import, the backlog reflects distinct issues, and the team spends its time on real vulnerabilities instead of clearing repeated noise.
Choosing Where DAST Sits Next to SAST and SCA
DAST is one of three application security testing categories PMAP treats as peers, alongside static application security testing and software composition analysis. Each answers a different question. DAST tests the running application from the outside and finds what an attacker can actually exercise. SAST analyzes source code and finds flaws before the application runs. SCA examines dependencies and finds known vulnerabilities in the open source components an application ships. None of the three replaces the others, and a mature program runs all three with each owning the part of the attack surface it is best at.
Where DAST fits is determined by what it sees that the others cannot. It catches runtime-only issues: misconfigurations that only exist in the deployed environment, authentication and session weaknesses that depend on live behavior, and injection points that depend on how inputs flow through the running system. It also validates that a flaw flagged in code is actually reachable in production, which is something static analysis alone cannot confirm. That makes DAST the testing category that grounds an AppSec program in real exploitability.
This article owns the DAST vendor ecosystem. The head-to-head decision of when to lean on dynamic testing versus static analysis versus composition analysis belongs in its own comparison. For that, see SAST vs DAST vs SCA, which works through the trade-offs as a category choice. The point here is that PMAP places all three in one connector hub, so the decision is never about tooling silos. It is purely about which testing technique covers which risk.
How PMAP Runs DAST at Scale
Bringing the pieces together, scaling DAST in PMAP rests on one structural idea: the dynamic scanners are connectors inside a universal hub, not separate platforms bolted together. Acunetix, Invicti and Burp Suite Enterprise each register as a ScannerConnector, so they share the same remote scan lifecycle, the same authenticated-scanning and scope controls, the same normalized severity model and the same idempotent import pipeline.
In practice, an at-scale DAST program in PMAP looks like this. Each DAST tool is added once as an integration, with credentials encrypted at rest and a connection test confirming the link before anything runs. Login sequences are attached to the scans that need authenticated coverage, and scope is set per scan with explicit include and exclude lists. Recurrence is assigned deliberately to either the vendor schedule or the PMAP-side schedule. Scans are launched, paused, resumed and stopped from one control surface. Completed findings are normalized into one severity scale, deduplicated by fingerprint and imported into the right projects. From there they enter the same triage and remediation flow as findings from every other scanner category.
The result is a DAST program whose effort scales sublinearly with the application portfolio. Adding a fifth application or a second customer’s environment does not multiply the operational overhead, because the operating model is fixed at the platform level and only the targets change. That is what it means to run DAST at scale, and it is what the connector hub is built to deliver. For where this dynamic testing layer sits inside a DevSecOps practice and how it pairs with shift-left analysis, the broader treatment lives in DevSecOps vulnerability management, and the management of the connectors and credentials behind all of it is covered in integration management.
Frequently Asked Questions
Which DAST scanners does PMAP integrate with?
PMAP integrates with three dynamic application security testing scanners natively: Acunetix, Invicti and Burp Suite Enterprise. All three sit in the platform’s DAST category and are built as remote scan connectors, so they share the same scan lifecycle, scope and authentication controls, and normalized finding model.
Can PMAP run authenticated DAST scans?
Yes. PMAP exposes login sequences as a DAST capability. The platform can list the login sequences recorded on a DAST vendor and attach a specific login sequence to a specific scan, which lets the scanner authenticate and test the post-login attack surface rather than stopping at the login page.
How do I control what a DAST scan covers?
PMAP reads and updates DAST scan scope on the vendor side through include and exclude URL lists. You can confirm the current scope before launching a scan and adjust the boundary by adding URL patterns to test or excluding patterns that should be left untouched, all without leaving the platform.
What is the difference between a vendor schedule and a PMAP-side schedule?
A vendor schedule is a recurring scan configuration that lives inside Acunetix, Invicti or Burp, managed from PMAP through full create, read, update and delete control, and the scanner’s own engine drives that recurrence. A PMAP-side schedule is a per-integration cron that drives PMAP’s background scheduler to auto-import completed scans on its own cadence, with a schedule log recording what was imported when.
How does PMAP keep DAST severities consistent across scanners?
Each DAST connector produces a normalized severity through its own mapper, and PMAP never treats the raw vendor severity as authoritative. Every finding flows through that mapper into one severity model, then through a threshold filter, with an optional rule engine override after import. That gives a finding set that can be ranked consistently whether Acunetix, Invicti or Burp reported it.
Will running two DAST tools on the same app create duplicate findings?
No. PMAP’s import pipelines are idempotent and match findings by fingerprint, so re-importing a scan produces no duplicates and overlapping findings across tools collapse toward one tracked issue. Raw vendor payloads are archived for audit and replay, so the original evidence is preserved even after deduplication.
How is DAST different from SAST and SCA in PMAP?
DAST tests the running application from the outside and finds runtime-only issues an attacker can actually reach. SAST analyzes source code before the application runs, and SCA examines open source dependencies for known vulnerabilities. PMAP treats all three as peer categories in one connector hub. For the head-to-head decision between them, see the SAST vs DAST vs SCA comparison.
