Run, watch, adopt, and import every vendor scan from one console, with one status model and one deduplicated finding queue.
A scan in PMAP is a single execution context for vulnerability scanning, whether an analyst launched it, a cron schedule triggered it, or it was adopted automatically from a remote scanner. The scan domain owns it end to end; the integration domain sits beneath as the universal connector hub.
PMAP collapses that into one console, one vendor-neutral status model, and one deduplicated finding queue. The design is deliberately a faithful mirror: background loops adopt any vendor scan not yet in PMAP, and a blocklist guard ensures a deleted scan is never silently re-adopted.
The problem at enterprise scale is not running one scanner. It is running many, concurrently, across VM, DAST, SAST, SCA, and network discovery.
At a glance
- Backend domains: internal/scan and internal/integration (Go modular monolith)
- Connectors: 30 vendor subpackages: VM, DAST, SAST, SCA, container, mobile, network, ITSM, CI/CD
- Status model: Vendor-neutral, system-written; vendor strings mapped through statusMap
- Live sync: 30-second status ticker, 5-minute orphan adoption, 5-minute meta backfill
- Import pipeline: Four-case correlation (scanner_ref, fingerprint, reopen, create), idempotent
- Scheduling: In-process robfig/cron, reload every 5 minutes, 10-minute job timeout
- Multi-tenancy: ScopeFilter on every list; 404-not-403 scope check on item paths
How it works
Many scanners, one orchestration layer. PMAP mirrors every vendor scan list, normalises status to one model, and feeds a single deduplicated finding queue, so coverage is managed in one place instead of a dozen consoles.
Scan status is not an analyst-driven state machine. It is written by the system, by the 30-second sync loop and the import pipeline, and always reflects vendor reality plus PMAP’s import phase. Vendor strings enter the model in exactly one place: statusMap.
Three background loops, all started at boot, keep the inventory current on independent tickers so time-critical work stays responsive while expensive work runs less often. Long operations never block the request.
Key capabilities
- Scheduled imports. A scan carrying schedule_cron is registered with an in-process cron (robfig/cron, 5-field), reloaded every 5 minutes. Each job runs the full pipeline under a 10-minute timeout, attributed to a fixed system user.
- On-demand sync. A sync endpoint fires an immediate vendor status poll plus orphan-adoption pass in a detached goroutine, returns HTTP 202, and survives the HTTP request being cancelled. The Refresh button is wired to it.
- Intentional deletion. Delete writes the integration and external scan ID to a blocklist so adoption never re-creates the scan. A cascade flag also asks the vendor to delete, best-effort, with a warning on failure rather than a rollback.
- History backfill. Onboarding a scanner with years of history queues import for every completed, zero-imported scan. It is idempotent: only zero-imported scans are eligible, so re-running once imported returns zero.
Use cases
- Consolidate a multi-vendor estate. A CISO needs one view across Nessus, Qualys, Rapid7, and a DAST tool. PMAP adopts every vendor scan list, normalises status, and presents one grid instead of four consoles.
- Watch a wave land and triage once. A vulnerability manager imports a completed Qualys scan. Four-case correlation deduplicates recurrences and reopens what came back; per-severity counts refresh from real findings.
- Automate recurring imports. A SOC lead sets a nightly cron on a Nessus-backed scan. The scheduler fires under a system user with a bounded timeout and emits the completion event, no console needed.
One console for every vendor scan, one deduplicated finding queue.
