Most security teams do not set out to run six scanners. They get there one reasonable decision at a time. A vulnerability management tool covers the network. A DAST product handles web applications. SAST and SCA arrive with the DevSecOps push. A network discovery scanner fills a visibility gap. Each tool was bought for a good reason, and each one earns its keep on its own terms. What nobody bought, intentionally, was the sprawl that comes with them. Six consoles, six severity scales, overlapping findings on the same host, and no single answer to the question every executive eventually asks, namely how exposed are we right now.
This is the consolidation problem, and it is different from the question of whether to add a scanner in the first place. If you are still deciding between one scanner and several, that is a separate decision and we cover it in our multi-scanner versus single-scanner comparison. This article is for teams who already run several scanners and want to stop the operational tax that comes with them. It is a vendor-agnostic playbook. If your stack happens to be the common trio, you may also want the more specific walkthrough in consolidating Tenable, Qualys, and Rapid7. The steps here apply regardless of which scanners you run.
The thesis is simple, and it shapes everything below. You do not consolidate scanner sprawl by deleting scanners. You consolidate it by collapsing the consoles into one orchestration layer while leaving the scanners themselves in place. This sits inside the broader security integration layer that connects every external system PMAP speaks to.
How Scanner Sprawl Happens (and Why It Is Normal)
Scanner sprawl is not a sign of a poorly run program. It is usually a sign of a maturing one. Coverage requirements expand across the application lifecycle, and no single engine covers all of it well.
PMAP’s integration domain organizes connectors into archetypes that map directly to these distinct jobs. A ScannerConnector handles remote scan management and results fetch for vulnerability scanners like Nessus, Tenable SC and IO, Qualys, and Rapid7, plus DAST products like Acunetix, Invicti, and Burp. A PullOnlyConnector performs scheduled project-level results pulls for SAST and SCA tools such as Checkmarx, SonarQube, Snyk, Black Duck, and Sonatype. An AssetSourceConnector enumerates repositories and pipelines for CI/CD systems. The point is that these are genuinely different categories of work. The vendor type catalog groups supported scanners across discovery and network, VM, SAST, SCA, DAST, container, and mobile categories. You do not get from a network VM scanner to authenticated web application testing to dependency analysis with one product, so most teams end up with several.
This is the honest version of the story. Sprawl happens because the coverage was real. The mistake is not buying the second or third scanner. The mistake is letting each one keep its own console, its own severity scale, and its own copy of the truth.
The Real Cost of Sprawl
The cost of sprawl is not the license fees. Those were budgeted. The cost is everything that happens after the scans run.
The first cost is duplication. The same host shows up in your network scanner and again in a discovery scan. A web application vulnerability appears in DAST output and again in a manual assessment. Without a deduplication step, every one of those is a separate row a human has to look at, triage, and decide about. That work scales with the number of scanners, not with the number of real problems. Sprawl turns a fixed amount of risk into a growing amount of busywork.
The second cost is conflicting severity. Every scanner vendor scores findings on its own scale, and those scales do not agree. The same weakness can be a high in one console and a medium in another. When a team works out of multiple consoles, severity stops being a reliable basis for prioritization because it depends on which tool you happened to be looking at.
The third cost is the missing single view. When findings live in six consoles, no one can answer a portfolio-level question without manually stitching exports together in a spreadsheet. Reporting becomes a recurring manual project. Trend lines are unreliable because the underlying counts are inflated by duplicates. Leadership gets numbers nobody fully trusts.
These three costs compound. The more scanners you add for coverage, the more duplication, severity conflict, and reporting friction you inherit. That is the trap. The way out is not fewer scanners. It is one place where all of their output lands, gets deduplicated, gets normalized, and gets counted once.
Consolidate the Console, Not the Scanners
The instinct under budget pressure is to rationalize the tool list and cut scanners. Sometimes that is the right call, and we will come back to it. But cutting scanners to solve a console problem is solving the wrong problem. If a scanner provides coverage you need, removing it creates a blind spot. The sprawl you were trying to fix becomes a gap instead.
PMAP’s scan domain is built around the opposite move. It is described as the core orchestration layer, where a scan is a single execution context whether it was launched manually by an analyst, triggered automatically by a cron schedule, or adopted from a remote scanner. The integration domain is described as the universal connector hub that manages the full lifecycle of every external system PMAP speaks to. Together these two domains let every scanner keep doing its job while their results flow into one pipeline.
So the playbook below does not ask you to remove a single scanner. It asks you to point every scanner at one orchestration layer, let that layer adopt and normalize what the scanners already produce, and then run your program from that one place. The scanners stay. The consoles, as your daily workspace, go away.
The Consolidation Playbook
The following seven steps move a sprawling multi-console setup into a single orchestrated pipeline. They are ordered so that each step builds on the last. You inventory what you have, connect it through one layer, adopt the scans that already exist, backfill the history, let correlation collapse duplicates, normalize severity, and keep everything in live sync. Work them in order.
Step 1, Inventory Every Connector You Already Run
You cannot consolidate what you have not counted. Start by listing every scanner in use, including the ones a single team quietly runs that never made it onto the official inventory. Shadow scanners are common in mature programs, and they are a real source of duplicate findings.
PMAP makes this concrete with its type catalog. The GET /types endpoint returns a categorized, schema-driven catalog of every supported vendor type, with auth-field and config-field descriptors. The supported types span discovery and network scanners like Nmap and Masscan, VM scanners including Nessus, Tenable, Qualys, Rapid7, and Nuclei, SAST tools, SCA tools, DAST tools, container scanning, and mobile. Map each scanner you run to its category in the catalog. By the end of this step you should have a complete picture of what archetype each tool falls into and what it covers, which tells you where the overlap and the gaps actually are.
Step 2, Connect Scanners Through One Integration Layer
Once you know what you have, connect each one as an integration. PMAP stores a single integrations record per connector, holding credentials and configuration, and dispatches vendor-specific logic through a registry of connector archetypes. There is no hardcoded switch statement in the core, which is why adding a new connector type does not require re-plumbing the platform.
Two details matter for an operator doing this at scale. First, credentials are handled safely. All password, token, and key credential fields are encrypted at rest in an encrypted_credentials column, and they are decrypted on demand using the platform key. You are not pasting secrets into a config file. Second, you can test before you commit. An inline connection test lets you validate credentials before saving with POST /test, or after saving with POST /{id}/test, and it returns latency, vendor version, license info, and warnings. That means you find the broken credential or the wrong base URL during setup, not during your first failed scan import. The add-integration wizard renders dynamically from the type catalog, so the form for each vendor shows exactly the auth and config fields that vendor needs.
Step 3, Adopt Existing Scans Automatically
This is the step that turns consolidation from a migration project into something closer to a switch you flip. You do not have to manually re-create the scans that already exist on each vendor.
When a scanner integration is created, PMAP triggers an immediate asynchronous sweep that matches any existing vendor scans to PMAP and adopts them without waiting for the regular tick. After that, orphan adoption keeps running on a schedule. A five-minute ticker queries each active integration for its full vendor scan list and automatically creates PMAP rows for scans that exist on the vendor but are not yet in PMAP. The wiki describes the effect plainly, namely that this makes the Scans page a faithful mirror without manual intervention.
There is a guard worth knowing about. When a scan is deleted in PMAP, its integration and external scan ID pair is written to a blocklist, so orphan adoption never re-adopts it. That means a deliberate deletion stays deleted and does not silently reappear on the next sweep. The importable-scan picker also annotates every vendor scan with its adoption status, namely adopted, company, or project, so you can selectively import or reassign auto-adopted scans rather than taking everything blindly.
Step 4, Backfill History So Nothing Is Lost
A consolidation that throws away your scan history is a hard sell to anyone who relies on trend data. PMAP handles the backfill as a first-class onboarding action. The POST /bulk-import-history endpoint queues background import for all completed integration scans that have zero findings imported. The wiki calls this an idempotent backfill for onboarding, and idempotent is the operative word here.
Idempotency is what makes the backfill safe to run. Across PMAP, import pipelines are idempotent by design, so re-importing the same vendor scan produces no duplicates. Findings are matched by fingerprint, and raw payloads are archived in object storage to enable replay without data loss. If a backfill is interrupted, you rerun it, and it hits the same external IDs and upserts rather than duplicating. So you can pull years of completed scans into the consolidated view without worrying that a retry will double your counts.
Step 5, Let Correlation Collapse the Duplicates
This is where sprawl actually shrinks. Up to this point you have connected scanners and pulled in their scans and history. Now the duplicate findings that motivated the whole exercise get collapsed.
Every import runs through the correlation engine. The scan domain’s import pipeline fetches findings from the linked vendor and runs them through correlation for dedup and create, update, or reopen handling, across Nessus, Qualys, Acunetix, Invicti, SonarQube, Tenable.sc, and Rapid7. The result is that the same real issue, reported by two scanners or by the same scanner across two runs, becomes one tracked finding rather than two rows. Findings are matched by fingerprint, so a repeat of the same weakness on the same target is recognized as the same finding.
This is the mechanism behind the single view. You are not deduplicating by hand in a spreadsheet after the fact. The collapse happens at import time, every time, on every connector you wired up in Step 2. The correlation engine itself has more depth than a consolidation playbook needs to cover, and we walk through its internals in the correlation and deduplication engine article.
Step 6, Normalize Severity Across Vendors
Deduplication fixes the count. Severity normalization fixes the priority. These are different problems and consolidation needs both.
PMAP’s severity governance is explicit on this point. Each connector produces a normalized severity through its own vendor-specific mapper, and the wiki states directly that PMAP never uses vendor severity directly. Instead, normalized severity flows through a threshold filter and an optional rule engine override. The import pipeline applies a configured severity threshold, and findings below the configured minimum are discarded rather than imported. So you set one threshold for what is worth tracking, and every scanner’s output is held to it consistently.
The original vendor severity is not thrown away. The mapper produces the normalized value while the connector preserves what the vendor reported, so you retain the evidence trail without letting a single vendor’s scale dictate your prioritization. After consolidation, a high means the same thing whether the finding came from your VM scanner or your DAST product, because severity is governed by one set of rules rather than six vendor opinions.
Step 7, Keep Everything in Live Sync
Consolidation is not a one-time import. The scanners keep running, and the consolidated view has to keep up with them. PMAP handles this with two background loops.
A live status sync runs on a thirty-second ticker. It polls all running, queued, paused, and importing integration-backed scans through the vendor API and writes fresh status, progress, findings count, and per-severity counts. When a scan transitions to completed, the sync loop auto-triggers asset import, findings import, and enrichment in the background, so a finished vendor scan flows into the consolidated view on its own. For the cases where you do not want to wait for the next tick, the POST /sync endpoint fires an immediate vendor status sync plus orphan adoption, optionally scoped to a single integration, and responds immediately while the work happens in the background.
The effect of these two loops together is that the consolidated pipeline stays current without anyone logging into a vendor console to check. New scans get adopted, running scans get tracked, completed scans get imported, and the single view reflects all of it within minutes.
Measuring the Win After Consolidation
A consolidation is only worth doing if you can see that it worked. The win shows up in two kinds of numbers.
The first is the reduction in finding count from deduplication. Before consolidation, your count is inflated by every duplicate across every console. After Step 5, the same real issues are tracked once. The drop between those two numbers is a direct measure of how much duplicate noise the program was carrying. Because per-severity counts are refreshed from the actual findings in the database after every import, the post-consolidation counts are authoritative rather than estimated.
The second is what the consolidated data lets you see that you could not see before. Analytics that were impossible across six consoles become straightforward against one deduplicated dataset. Recurring and chronic findings, the vulnerabilities that keep coming back across scans, are only visible once correlation has tied repeat occurrences to a single tracked finding. Top vulnerability rollups across the whole estate require one normalized dataset to compute. These views are the practical payoff of consolidation. They are the questions that sprawl made unanswerable and that a single pipeline makes routine.
When you report the win, lead with the deduplicated count and the newly possible analytics rather than with tool reduction. You did not remove scanners. You removed duplicate work and restored a single, trustworthy view, and those are the numbers that matter to the people who fund the program.
What Not to Consolidate
A balanced playbook has to be honest about what consolidating the console does not do, because overselling it leads to the wrong follow-on decisions.
Consolidating into one orchestration layer does not change your budget decision. Pointing every scanner at one pipeline does not tell you which scanners to renew, which to drop, or where two products genuinely overlap enough that you could run one. Those are vendor-selection questions, and they depend on coverage analysis, contract terms, and the specific strengths of each product. Consolidation gives you the deduplicated, normalized data that makes a vendor-rationalization decision better informed, but it does not make the decision for you. If your goal is to cut the tool list and not just the consoles, treat that as a separate exercise once the single view is in place.
Consolidation also does not fix a coverage gap. If no scanner in your stack tests a given surface, collapsing the consoles will not surface a finding that no tool ever produced. The single view is honest about what you scanned, which means it is also honest about what you did not. That clarity is useful, but it is not the same as coverage.
And consolidation does not remove the need for triage. Deduplication and severity normalization make triage far more efficient by cutting duplicates and giving you one trustworthy scale, but a human still owns the decisions about what gets fixed, what gets accepted, and what gets a deadline. The pipeline does the mechanical work so that people can spend their attention on the judgment work.
How PMAP Ends Scanner Sprawl
Pulling the playbook together, PMAP ends scanner sprawl by being the one place every scanner reports to rather than the seventh scanner you have to manage. The integration domain is the universal connector hub, holding one record per connector, dispatching vendor logic through archetypes, encrypting credentials at rest, and offering an inline test before anything goes live. The scan domain is the orchestration layer that adopts existing vendor scans automatically, backfills history idempotently, runs every import through correlation to collapse duplicates, applies one severity governance model across every vendor, and keeps the whole picture current with a thirty-second status sync and a five-minute orphan adoption sweep.
None of those behaviors require removing a scanner. That is the heart of the approach. Your VM scanner, your DAST product, your SAST and SCA tools, and your discovery scans all keep running exactly as they do today. What changes is that their output stops living in six separate consoles and starts living in one deduplicated, severity-normalized, continuously synced pipeline. The coverage you paid for stays. The sprawl tax goes away.
If you want to map your current stack against this model before you start, read the multi-vendor scan orchestration datasheet and the correlation and deduplication engine datasheet. Then run the playbook step by step. Inventory, connect, adopt, backfill, correlate, normalize, and sync. Seven steps, no deleted scanners, and one console at the end of it.
