PMAP capability
Turn raw scanner output into one clean finding per real issue. PMAP matches every inbound result against what it already knows, updates or reopens the right finding, and backfills the standard references so triage starts from signal instead of noise.
Overlapping scanners report the same weakness many times, in many formats. Without correlation, that becomes a backlog of duplicates that buries the findings that matter.
PMAP collapses that noise on ingest. Each result is checked against existing findings, matched or created deterministically, and enriched with the references your analysts and auditors expect.
The same SQL injection on the same host, reported four ways by four scanners, becomes a single governed finding on ingest.
Matched by reference key, then fingerprint. One finding, full history kept.
Each inbound result is checked against existing findings by scanner reference key first, then by a SHA-1 fingerprint across any status, including closed.
A match updates or reopens a single finding, and a no-match result creates exactly one new finding, so the same issue never lands twice.
Smart Match correlation enriches findings with CVE, CWE and CVSS data, so every record carries the standard references triage and reporting rely on.
Wave-visibility accounting tracks how often a finding recurs across scans, so persistent and reopening issues are obvious instead of hidden.
Every scanner result runs the same path before a finding is written, so the outcome is one governed record instead of another duplicate.
Every inbound scanner result is checked against existing findings before anything is created. PMAP decides whether the vulnerability is new, recurring, or returning, so the write reflects reality rather than raw vendor output.
The scanner reference key is the scanner's own unique identifier for a result. PMAP tries it first, so re-importing the same scan resolves straight to the finding it already produced and never doubles the backlog.
When the reference key finds nothing, a SHA-1 fingerprint over the normalized title, asset, and endpoint takes over. Two scanners that describe the same issue in different words still converge on one finding.
A match on an open finding updates it in place. A match on a closed finding reopens it with full history. Only a result that matches nothing creates a new finding.
Each outcome registers the scan that produced it, so recurrence stays visible. The platform always knows how many scans have seen a vulnerability and which scan saw it last.
On create and reopen, PMAP backfills the standard references and runs your ingest rules inline. A rule that fails never blocks the import, so ingestion always completes.
Overlapping scanners stop turning a single weakness into a dozen tickets. Your analysts triage the real issue once, so the backlog tracks actual exposure instead of scan frequency.
When a closed vulnerability returns, PMAP reopens the original finding with its full remediation record rather than starting over. Auditors see the complete story, and nobody re-investigates from scratch.
Running the same import twice changes nothing, because correlation is idempotent and scoped to your tenant. Teams scan as often as posture demands without drowning the queue or crossing a company boundary.
Because it is the most authoritative and the cheapest match. The scanner reference key is the vendor unique key for a result, so a hit means the same scanner has reported the same thing before. PMAP checks it first and falls back to the content fingerprint only when the reference is missing or matches nothing.
Through the fingerprint, which matches findings in any status, including closed. When a scan re-detects a vulnerability whose finding was closed, PMAP refreshes its fields and reopens it with the importing user as attribution, so it keeps its identity and prior remediation history instead of being recreated.
No. The fingerprint lookup is scoped by company, so a match can only ever land inside the same tenant. Even an identical hash for a similar vulnerability on a similar endpoint stays within the correct boundary and never crosses it.
No. Rules run inline on create and reopen, but they are best-effort. If a rule fails to evaluate, the finding keeps its imported values and the import still succeeds, because ingesting the finding is the primary obligation and rules can be re-run in bulk afterward.
Watch PMAP take overlapping scanner output and resolve it to one finding per issue, live.
