Most security teams do not have a scanning problem. They have a scanner-count problem. A typical enterprise runs Tenable or Qualys for infrastructure, Rapid7 for another business unit, a DAST product for web applications, a SAST engine in the build pipeline and an SCA tool for open-source dependencies. Each one produces results in its own format, on its own schedule, with its own severity scale and its own idea of what counts as a unique vulnerability. The output is real coverage. The experience is fragmentation.
This article is about the layer that fixes that fragmentation. Scan orchestration is the practice of pulling every scanner into a single pipeline, then normalizing, correlating and deduplicating what comes out so that analysts work against one consistent finding set instead of many disconnected exports. It is the intake and ingest layer of a vulnerability management program, and it determines how trustworthy everything downstream will be.
PMAP treats scan orchestration as a first-class domain rather than a side effect of integrations. The platform owns the entire scan lifecycle, runs every scanner result through a single correlation engine and keeps remote scans in sync without manual intervention. The sections below walk through why scanner sprawl breaks programs, what orchestration actually means inside PMAP, how the correlation pipeline produces one finding set from many scanners, and how scheduling, live sync and coverage tracking keep the whole thing current. This is the ingest companion to the broader vulnerability management lifecycle pillar, which covers what happens to a finding after it lands.
Why Scanner Sprawl Breaks Vulnerability Programs
Scanner sprawl is not caused by bad decisions. It accumulates because every part of the organization makes a reasonable local choice. Infrastructure standardizes on one vendor. Application security picks a DAST tool that fits its workflow. The platform team adds SAST and SCA inside the CI/CD pipeline because that is where code lives. A recent acquisition arrives with a different scanner already in production. None of these choices is wrong on its own. Together they leave the vulnerability management team holding five or six consoles that do not talk to each other.
The first symptom is duplicate work. The same host can be scanned by an infrastructure scanner and a network discovery tool. The same web application can show up in both a DAST product and a SAST engine through different lenses. Without a layer above the scanners, a single real weakness can appear as three or four separate records, each demanding triage, each consuming analyst attention. Teams spend their time reconciling exports instead of fixing problems.
The second symptom is inconsistent severity. Each scanner has its own severity language. One vendor calls something high, another calls the same class of issue medium, and a third reports a raw CVSS value with no qualitative label at all. When findings live in separate tools, there is no shared scale, so prioritization becomes a negotiation rather than a decision. Leadership cannot answer a simple question like how many critical issues are open right now, because critical means something different in every console.
The third symptom is stale visibility. Scanners run on their own cadence. A scan that finished overnight in the vendor portal does not exist in the vulnerability management view until someone remembers to export and upload it. The gap between what the scanner knows and what the program tracks is where risk hides. By the time the export reaches the analyst, the data is hours or days old, and the team is reacting to a snapshot of the past.
PMAP is built as a vulnerability management platform and multi-vendor scan orchestrator precisely because these three symptoms share one root cause. There is no layer above the scanners that owns the result. Orchestration is that layer. It does not replace the scanners. It consolidates what they produce into a single, correlated, continuously refreshed finding set so the program works from one source of truth.
For deeper background on the cost of running each scanner in isolation, see the cluster article on multi-scanner versus single-scanner programs (placeholder internal link). The rest of this article focuses on what orchestration replaces sprawl with.
What Scan Orchestration Means in PMAP
In PMAP, a scan is a single execution context for vulnerability scanning. That definition is deliberately broad, because the platform treats every origin of scan results the same way once the result exists. A scan can be launched manually by an analyst, triggered automatically by a cron schedule, or adopted from a remote scanner that ran entirely outside PMAP. Whatever the origin, the scan record owns its full lifecycle: creation, status tracking, progress sync, findings import and deletion.
The Scan domain sits at the center of the orchestration story. It is upstream of findings and assets, because importing a scan feeds new findings and new assets into those domains. It is downstream of the integration layer, which provides the actual vendor connectivity. And it is a peer of the assessment-run layer, which groups multiple scans into a named campaign. This position is what makes orchestration possible. The scan record is the single object that every downstream consumer, including reporting, analytics and notifications, can attribute results to.
A scan in PMAP carries far more than a status. The record holds per-severity counters, a progress value from zero to one hundred, host counts, the linked integration and its type, an external scan identifier from the vendor, optional sub-scanner identity, and a full set of CI and version-control fields for pipeline-triggered runs. It also carries resolved display names for the company, project, assessment run and creator, so the scan list reads as a human-friendly view rather than a wall of identifiers. The point is that a scan is a complete, queryable object, not a transient job.
Crucially, PMAP does not enforce a rigid state machine that analysts must drive by hand. Scan status is written by the system. The sync loop and the import pipeline move a scan through its states based on what the vendor reports and what the import does. An analyst does not click a button to mark a scan completed. The platform observes the vendor, translates the vendor’s status into a canonical PMAP status, and advances the lifecycle automatically. The canonical states run from queued through running, paused, importing and completed, with failed and cancelled as terminal outcomes. When a scan transitions to completed, the platform automatically triggers asset import, findings import and enrichment in the background.
This is what orchestration means in practice. The analyst’s job is to decide what matters among the results. The platform’s job is to make sure the results arrive, get normalized, and stay current. The cluster article on the full scan lifecycle goes deeper on each state transition (placeholder internal link).
One Correlated Finding Set From Many Scanners
The heart of orchestration is the moment many scanners become one finding set. PMAP achieves this with a dedicated correlation engine that every scanner importer calls for each result it produces. The engine is a pure library inside the platform. It has no user interface and no separate console. It runs silently during every import, and the only visible trace of its work is the outcome: a finding created, updated or reopened.
The correlation engine answers exactly one question for every inbound scanner result. Does this vulnerability already exist in the platform, or is it new? That question sounds simple, but answering it consistently across Nessus, Qualys, Rapid7, Acunetix, Invicti, Nuclei, SonarQube and Tenable.sc is the entire challenge of multi-vendor consolidation. Each scanner names things differently, formats endpoints differently and assigns its own identifiers. The engine has to see through those differences to the underlying vulnerability.
It does this with a two-stage lookup. First it tries the scanner’s own unique reference key, the value the scanner uses to identify a specific result on a specific target. If a finding already carries that exact key, the engine knows it is looking at a repeat of a result it has already seen, and the re-ingestion is idempotent. Running the same scan twice produces no duplicates. Second, if no scanner reference matches, the engine falls back to a content fingerprint. The fingerprint is a SHA-1 hash built from a normalized title, the asset identifier and a normalized endpoint, with optional template or definition identifiers added for finer granularity. Because the fingerprint is computed from the meaning of the finding rather than from any one scanner’s identifier scheme, it enables cross-scanner deduplication. Two different scanners reporting the same weakness on the same asset produce the same fingerprint, and the engine recognizes them as one finding.
Normalization is what makes the fingerprint stable. Before hashing, the engine lowercases and trims the title and rewrites the endpoint into a clean host and port form, stripping the scheme prefix and the URL path. Without this step, the same vulnerability described as HTTPS colon slash slash host slash login by one scanner and host colon four four three by another would hash to different values. With normalization, they converge. This is the quiet machinery that lets a Tenable result and a Qualys result for the same issue collapse into a single record.
The result of all this is the single most valuable property of an orchestration layer. One record per real issue. The duplicate noise that scanner sprawl creates is removed at the moment of intake, before any analyst sees it. The cluster article on the correlation engine internals covers the fingerprint construction in more depth (placeholder internal link), and the correlation and deduplication engine datasheet documents the engine as a product capability.
The 4-Case Correlation Pipeline at Ingest
The two-stage lookup feeds a four-case decision that runs for every single result. Understanding these four cases is the clearest way to see how PMAP keeps a multi-vendor finding set both deduplicated and accurate over time.
Case one is a scanner reference match. The inbound result carries a scanner reference key, and a finding with that exact key already exists. The engine refreshes the existing finding’s fields rather than creating a new one. This is the path that makes repeated scans of the same target idempotent. The fifth weekly scan of a server does not multiply its findings by five.
Case two is a fingerprint match. The result has no scanner reference, or its scanner reference does not match anything, but its content fingerprint matches an existing finding in the same company. The engine treats this as the same vulnerability and updates the existing record. This is the cross-scanner path. It is how a finding first reported by Qualys gets recognized when Rapid7 later reports the same issue.
Case three is a closed-finding reopen. The lookup, whether by scanner reference or fingerprint, matched a finding that had already been closed. Rather than silently updating a closed record or creating a misleading new one, the engine updates the finding’s fields and explicitly reopens it. This preserves the finding’s history while accurately reflecting that the vulnerability has recurred. A weakness that was fixed and verified, then reappeared after a regression, shows up as a reopen with its full prior timeline intact, not as a brand-new finding with no context.
Case four is a new finding. No scanner reference and no fingerprint matched anything in the platform. This is a genuinely new vulnerability, and the engine creates a fully populated finding. The new record carries every field the scanner provided, including the extended source fields that matter for application security: file path, line numbers, code snippet, taint flow, rule key, dependency path, component version and license. Nothing is lost between the scanner and the finding.
Two business rules tie the pipeline together. The scanner reference lookup always takes priority over the fingerprint lookup, so the most precise match wins when both are available. And the platform’s rule engine is evaluated immediately, at ingest time, but only when a finding is newly created or reopened, not on a plain update. That means severity overrides and auto-assignment rules apply the instant a finding enters the system, so the result that reaches an analyst is already governed and routed. The cluster article on the correlation engine expands on the rule-evaluation step (placeholder internal link).
Manual, Integration-Backed and Pipeline-Triggered Scans
Orchestration only works if it covers every way a scan can begin. PMAP supports three origins, and treats the resulting scan record consistently regardless of which one created it.
A manual scan is analyst-authored. The analyst gives it a name, a scan type and a set of target assets, and optionally links it to a vendor integration. This is the path for ad-hoc work, for one-off assessments and for situations where a human wants explicit control over what runs and against what. Manual scans still flow through the same import and correlation pipeline as everything else, so they benefit from the same deduplication.
An integration-backed scan is linked to a vendor connector through an integration identifier and an external scan identifier. This is the workhorse of multi-vendor orchestration. The scan record points at a real scan living on Nessus, Qualys, Rapid7, Tenable.sc or a DAST vendor, and PMAP polls that vendor for status and pulls its results. Because the link is explicit, PMAP can launch, monitor and import the remote scan, and it can even ask the vendor to delete its copy when the PMAP scan is deleted. Integration-backed scans can also be pinned to a specific child appliance, for example one Nessus node under a Tenable.sc deployment, through a sub-scanner identity, so large distributed scanner estates remain addressable.
A pipeline-triggered scan originates from CI/CD. When code is pushed or a pull request is opened, the integration layer normalizes the event and can fan it out to SAST and SCA scans automatically. Scans created this way carry the source context that DevSecOps teams need: commit SHA, branch name, pull request number, repository URL and the actor that triggered the run. This turns a scan from an isolated security event into a record tied to a specific change, which is what makes pull-request gating and per-commit security feedback possible. The cluster article on CI/CD-triggered scans covers the orchestrator fan-out in detail (placeholder internal link), and the broader connector ecosystem is the subject of its own pillar on the security integration layer.
The common thread is that all three origins produce the same kind of scan record and feed the same correlation engine. An analyst reviewing the finding set does not need to know whether a finding came from a manual scan, a scheduled vendor pull or a pipeline run. The orchestration layer erases that distinction at the point where it stops mattering.
Live Status Sync and Orphan Adoption
The difference between a scan importer and a scan orchestrator is what happens between scans. An importer waits for someone to hand it a file. An orchestrator keeps itself current. PMAP does this with two background mechanisms that run continuously: live status sync and orphan adoption.
Live status sync runs on a thirty-second ticker. Every thirty seconds, the platform polls every integration-backed scan that is currently running, queued, paused or importing, asks the vendor for its latest state, and writes fresh status, progress, host count, total findings count and per-severity counts back to the scan record. This is why a PMAP scan list reflects what the scanners are actually doing right now rather than what they were doing the last time someone checked. When a scan transitions to completed during one of these polls, the sync loop does not stop at updating the status. It automatically triggers asset import, findings import and enrichment in the background, so a completed vendor scan becomes a correlated, enriched finding set without an analyst lifting a finger.
Orphan adoption solves a harder problem. A scan can run entirely on the vendor side, started by someone using the vendor’s own console, with PMAP never told about it. Without orchestration, that scan is invisible to the program. PMAP closes this gap with a five-minute ticker that queries each active integration for its complete list of vendor scans and automatically creates PMAP rows for any scan that exists on the vendor but does not yet exist in PMAP. The platform adopts the orphan. If an adopted scan is already completed, PMAP immediately imports its assets and findings and runs enrichment. The effect is that the PMAP scan list becomes a faithful mirror of the vendor, even for scans that no one launched through PMAP. Teams that have used the vendor console for years do not have to change their habits for the program to capture their work.
Adoption is guarded so it never becomes a nuisance. When a scan is deleted in PMAP, its vendor identity is written to a blocklist, so orphan adoption never re-adopts a scan an operator deliberately removed. A deletion stays a deletion. There is also a backfill mechanism for onboarding: a bulk history import queues background import for every completed vendor scan that has zero findings imported, which lets a new deployment pull in a vendor’s existing scan history in one idempotent pass.
When an analyst needs an immediate refresh rather than waiting for the next tick, an on-demand sync fires both a vendor status sync and an orphan adoption pass right away, optionally scoped to a single integration. The request returns immediately and the work runs in the background, so the interface stays responsive. Together these mechanisms mean PMAP’s view of the scanner estate is never more than a few minutes stale and usually current to the last thirty seconds. The scheduling and live-sync cluster article covers the tickers in more operational detail (placeholder internal link).
Severity Governance Across Vendors
A finding set is only as trustworthy as its severities, and severity is exactly where multi-vendor consolidation is most likely to go wrong. Every scanner has its own severity scale, and if the platform simply copies each vendor’s label, the consolidated view inherits all of their inconsistencies. PMAP refuses to do that.
The principle is that PMAP never persists a vendor’s severity as authoritative. Each connector produces a normalized severity through its own mapper, translating the vendor’s native scale into PMAP’s common scale. From there, the import pipeline applies a configurable severity threshold so that findings below a chosen minimum are discarded at ingest rather than cluttering the program. A team that does not want informational results from a particular scanner can set the threshold and never see them. After that, the rule engine can override severity further based on context the scanner could not know, such as the criticality of the affected asset or the exposure of the environment.
This layered approach means severity in PMAP is a governed value, not a raw vendor opinion. The original severity that the scanner reported is preserved so the chain of reasoning stays auditable, but the working severity that drives prioritization is one the platform has normalized and the program can control. The result is a single coherent scale across Tenable, Qualys, Rapid7 and every other connected scanner. When leadership asks how many critical findings are open, the answer means the same thing no matter which scanner found them.
At the scan level, this governance shows up as the per-severity counters that every scan carries. After every import, and during the live-sync loop, PMAP refreshes the critical, high, medium, low and informational counts from the actual findings in the database. These are not estimates copied from the vendor. They are authoritative post-import values computed from the correlated finding set, so the severity breakdown on a scan card reflects what PMAP actually persisted after deduplication and threshold filtering. The broader treatment of severity as a governance control across the lifecycle lives in the vulnerability management lifecycle pillar.
Scheduling Scans and Keeping Them in Sync
Orchestration that depends on someone remembering to run things is not orchestration. PMAP makes scanning a scheduled, self-maintaining activity through two complementary scheduling mechanisms.
The first is per-scan cron scheduling. A scan can carry a cron expression, and the platform’s scheduler registers it as a recurring job. The scheduler reloads its set of scheduled scans every five minutes, so a newly scheduled scan starts running on its cadence without a restart, and at each scheduled time it triggers the import pipeline. Scheduled imports run under a system actor identity so the activity log clearly distinguishes automated runs from analyst-initiated ones. This is the mechanism that turns a one-time scan into a continuous control. A weekly infrastructure scan or a nightly application scan runs on its own, imports its results, deduplicates them and updates the program without anyone scheduling the work by hand each time.
The second is the per-integration schedule that drives the vendor side. At the integration layer, each connector can carry its own cron schedule and enabled flag, with a background scheduler that ticks every minute and fires any integration whose cron is due. This is how PMAP auto-imports completed vendor scans on a regular cadence. Every scheduled run writes a log entry recording its status, the number of findings imported and the duration, so operators have an audit trail of what the scheduler did and when. A run-now control lets an operator trigger a scheduled import immediately without waiting for the next tick.
Between the per-scan cron, the per-integration schedule, the thirty-second status sync and the five-minute orphan adoption, PMAP maintains four independent timing mechanisms that together keep the finding set current. The team configures the cadence once. The platform keeps it running. The scheduling and live-sync cluster article walks through configuring cron expressions and reading the schedule log (placeholder internal link).
Findings Delta: Knowing What Changed Between Waves
Running scans on a schedule produces a stream of waves, and the question that matters after each wave is not how many findings exist in total. It is what changed. A scan that surfaces two hundred findings tells an analyst nothing about urgency if one hundred and ninety-eight of them were already known and being worked. The two that are new, or the five that regressed after being fixed, are where attention belongs.
PMAP answers this with a findings delta. Each scan exposes a delta view that returns a breakdown of new versus regression versus total findings, sliced by severity. This powers the “what changed” widget on the scan detail page. New findings are vulnerabilities that did not exist in the platform before this scan. Regressions are findings that had been closed and have now reappeared, surfaced through the correlation engine’s reopen path. Total is the full count for context. By presenting these as distinct numbers, the delta turns a raw scan result into an actionable summary.
This matters most in a multi-vendor program running scheduled waves. When a scanner runs every week, the value of each run is in its delta against the last. The delta is what lets an analyst open a freshly completed scan and immediately see that three new critical findings appeared and one high-severity issue regressed, without manually comparing this wave against the previous one. It is the difference between scanning for the sake of compliance and scanning to drive remediation. Combined with the activity log that records every lifecycle transition on a scan, the delta gives a complete picture of what each wave contributed.
The delta is a direct product of correlation. Because the engine knows whether each result was a create, an update or a reopen, it can attribute every finding in a scan to the right bucket. Without deduplication, a delta would be meaningless, because every result would look new on every run. With it, the delta is precise.
Scan Coverage and the Wave Matrix
A finding set answers what is wrong. Coverage answers a question that is just as important and easier to overlook: what got looked at. A vulnerability program that scans the same forty servers every week while two hundred others go untouched has excellent finding data and a dangerous blind spot. Orchestration has to track coverage, not just results.
PMAP connects scans back to assets so the program can see which assets have been covered by which scans and when. Because every imported scan attributes its findings to specific assets, the platform can reason about scan coverage across the asset inventory. This is what surfaces the gaps. An asset that has never appeared in any scan is a coverage gap regardless of whether it has findings, because the absence of findings on an unscanned asset is not reassurance. It is ignorance.
The wave matrix is the structured view of this over time. It lays out assets against successive scan waves, so a team can see at a glance how coverage has evolved, which assets are consistently scanned, and which fall in and out of scope. In a multi-vendor program this is especially valuable, because different scanners cover different parts of the estate. The matrix is where the team verifies that, taken together, the scanner portfolio actually covers what it is supposed to cover, and where it exposes the seams between vendors.
Coverage is the orchestration angle on the asset inventory. The asset-centered treatment of inventory, ownership and risk scoring belongs to the attack surface and asset inventory pillar, which approaches the same wave matrix from the inventory side rather than the scan side. Here the point is narrower. Orchestration is not finished when results are imported. It is finished when the team can prove what was scanned, what was not, and how that picture moves wave over wave. For a product-level summary of the orchestration capabilities described across this article, the multi-vendor scan orchestration datasheet collects them in one place.
How PMAP Orchestrates Across Many Connectors
Everything above depends on the breadth and depth of the connector layer underneath it. Orchestration is only as good as its coverage of the scanners a team actually runs, so it is worth being concrete about what PMAP connects to and how.
The integration domain is PMAP’s universal connector hub. It manages the full lifecycle of every external system PMAP speaks to, and it dispatches vendor-specific logic through a registry of connector archetypes rather than hardcoded branches in the core. Four archetypes cover the landscape. Scanner connectors handle remote scan creation and results fetch for the vendors that expose a scan API. Pull-only connectors handle scheduled project-level results pulls for tools that do not model scans the same way. ITSM connectors handle ticket creation and status sync. And asset-source connectors handle repository and pipeline enumeration with CI fan-out. Each vendor package self-registers, so adding a connector does not mean rewriting the orchestration core.
The vendor coverage spans the categories a real program needs. For vulnerability management and infrastructure scanning, PMAP connects to Nessus, Tenable.io, Tenable.sc, Qualys VMDR, Rapid7 InsightVM and Nuclei. For DAST, it connects to Burp, Invicti and Acunetix. For SAST, it connects to Checkmarx SAST, Checkmarx One, SonarQube and Fortify. For SCA, it connects to Snyk, Black Duck and Sonatype Lifecycle. It covers container scanning through Prisma Cloud, mobile through MobSF, and network discovery through Nmap and Masscan. Beyond scanners, it integrates ITSM platforms such as Jira, ServiceNow and ManageEngine, and CI/CD systems including GitHub, GitLab, Azure DevOps, Jenkins, Bamboo and Bitbucket. This is the multi-vendor breadth that makes a single orchestrated pipeline realistic rather than aspirational.
Three product behaviors hold this together as an orchestration layer rather than a list of connectors. First, every import path is idempotent. Re-importing the same vendor scan produces no duplicates, because findings are matched by fingerprint and assets by IP, hostname or external identifier. Second, every connector’s credentials are encrypted at rest, and the platform supports an inline connection test that verifies credentials and reports vendor version, license information and any warnings before a scan ever runs. Third, raw vendor payloads are archived so an import can be replayed without data loss, which matters for audit and for recovering from a vendor-side change.
For scanner connectors, creating an integration triggers an immediate orphan-adoption sweep, so a newly connected scanner’s existing scans appear in PMAP right away rather than waiting for the next five-minute tick. From the moment a connector is added, its scans flow into the same lifecycle, the same correlation engine and the same coverage tracking as every other scanner. That is what one pipeline for every scanner means in practice. The full connector ecosystem, including ITSM ticketing and credential handling, is the subject of the security integration layer pillar, and the eBook on unifying multi-vendor scan data is the long-form companion to this article.
Frequently Asked Questions
What is multi-vendor scan orchestration?
Multi-vendor scan orchestration is the practice of running every vulnerability scanner a team uses through a single pipeline that normalizes, correlates and deduplicates the results. Instead of exporting findings from Tenable, Qualys, Rapid7, DAST, SAST and SCA tools into separate consoles, the orchestration layer pulls them into one place, recognizes when different scanners report the same vulnerability, and produces a single correlated finding set. In PMAP this means owning the full scan lifecycle, keeping remote scans in sync automatically, and presenting one consistent view across every connected scanner.
Which scanners does PMAP import findings from?
PMAP’s import pipeline correlates findings from Nessus, Qualys, Rapid7, Acunetix, Invicti, Nuclei, SonarQube and Tenable.sc through its correlation engine. The broader integration layer connects to a wider set of vendors across categories, including Tenable.io, Qualys VMDR, Burp, Checkmarx SAST and One, Fortify, Snyk, Black Duck, Sonatype Lifecycle, Prisma Cloud, MobSF, Nmap and Masscan, plus ITSM and CI/CD systems. Each connector self-registers through a connector archetype, so the orchestration core does not change when a vendor is added.
How does PMAP avoid duplicate findings across scanners?
PMAP runs every scanner result through a correlation engine that uses a two-stage lookup. It first checks the scanner’s own unique reference key, which makes re-importing the same scan idempotent. If that does not match, it falls back to a content fingerprint, a SHA-1 hash built from a normalized title, the asset identifier and a normalized endpoint. Because the fingerprint is computed from the meaning of the finding rather than any one scanner’s identifiers, two different scanners reporting the same weakness on the same asset produce the same fingerprint and collapse into one finding. The result is one record per real issue.
What is orphan scan adoption?
Orphan scan adoption is how PMAP captures scans that were launched outside the platform, for example from a vendor’s own console. Every five minutes the platform queries each active integration for its full list of vendor scans and automatically creates PMAP rows for any scan that exists on the vendor but not yet in PMAP. If an adopted scan is already completed, its assets and findings are imported and enriched immediately. Deleted scans are blocklisted so they are never re-adopted, which means a deliberate deletion stays deleted.
How often does PMAP refresh scan status?
PMAP polls every running, queued, paused or importing integration-backed scan every thirty seconds and writes fresh status, progress, host count and per-severity counts back to the scan record. A separate orphan-adoption pass runs every five minutes to discover scans launched outside the platform. Analysts can also trigger an immediate sync on demand, which fires both a status refresh and an adoption pass right away and runs the work in the background.
Can PMAP schedule scans automatically?
Yes. PMAP supports per-scan cron scheduling, where a scan carries a cron expression and the scheduler triggers its import pipeline at each scheduled time. It also supports a per-integration schedule that auto-imports completed vendor scans on a cadence, with every run writing a log entry that records status, findings imported and duration. A run-now control lets an operator trigger a scheduled import immediately. Scheduled runs are attributed to a system actor so they are distinguishable from analyst-initiated scans.
How does PMAP handle different severity scales from different scanners?
PMAP never persists a vendor’s severity as authoritative. Each connector maps the vendor’s native severity into a common PMAP scale, the import pipeline applies a configurable threshold that discards findings below a chosen minimum, and the rule engine can override severity further based on context the scanner could not know. The original vendor severity is preserved for auditability, but prioritization runs on a single normalized scale, so a critical finding means the same thing regardless of which scanner produced it.
Ready to unify your scanners? Read the multi-vendor scan orchestration datasheet and see how PMAP turns every scanner into one correlated pipeline. For the broader program context, start with the vulnerability management lifecycle pillar, and for the long-form treatment of consolidating scan data, read the eBook on unifying multi-vendor scan data.
Authoritative external references for the standards mentioned in this article: NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, the CISA Known Exploited Vulnerabilities catalog, and the MITRE CVE program.
