A vulnerability scan is not a single event. It is a small lifecycle with its own states, its own progress signals and its own moment of completion that hands work downstream. In a single-scanner shop you can watch that lifecycle in one vendor console. In a real enterprise you are running Nessus, Qualys, Rapid7, Acunetix, Invicti, SonarQube and Tenable.sc at the same time, and each of those tools tracks scan state in its own language, on its own page, behind its own login. The lifecycle is the same idea everywhere. The place you observe it is fragmented everywhere.
Scan lifecycle management is the discipline of treating that fragmentation as a solvable problem. Instead of one lifecycle per vendor console, you maintain one lifecycle layer that sits above every scanner, normalizes their states into a shared model, and lets you create, monitor, control and delete scans from a single place. This article explains what that layer needs to do, why each behavior matters in practice, and how PMAP implements it as the scan orchestration hub that feeds the rest of its vulnerability management workflow.
If you want the wider context first, this piece sits underneath the broader story of multi-vendor scan orchestration. That pillar covers the orchestration picture end to end. This article zooms into one layer of it, the lifecycle and control plane for an individual scan.
Why One Lifecycle Layer Beats Vendor Console Hopping
Picture a normal Tuesday for a security engineer who owns scanning across an enterprise estate. There are dozens of concurrent scans in flight. Some are scheduled overnight authenticated sweeps in Qualys. Some are ad-hoc Nessus runs an analyst kicked off to confirm a host is patched. A few are DAST runs in Acunetix or Invicti against staging. Each of those scans has a current state, a progress percentage and a result that someone is waiting on.
Without a lifecycle layer, the only way to answer “what is the state of everything right now” is to open every vendor console in turn and reconcile by hand. That context switching is not just slow. It is error prone. A scan that finished in Qualys two hours ago might still look “pending” in your mental model because nobody refreshed that tab. A failed Nessus run might sit unnoticed because the failure lives in a console nobody had open. The cost of fragmentation is not the clicks. It is the blind spots between the clicks.
A single lifecycle layer removes that overhead by giving you one screen that reflects the true state of every scan, regardless of which vendor produced it. The value is threefold. You get a vendor-neutral status model so a scan is “running” or “completed” in the same vocabulary no matter who ran it. You get a single point of control so you can act on a scan without learning each vendor’s button layout. And you get a guarantee that nothing you delete quietly comes back. PMAP builds this layer as its scan orchestration hub, sitting upstream of findings ingestion and downstream of vendor integrations, so the scan is fully managed before its results ever touch a finding.
Manual, Integration-Backed and Sub-Scanner Targeted Scans
The lifecycle has to start somewhere, and not every scan is born the same way. A good lifecycle layer supports several creation paths because real teams use several.
The first path is the manual scan. An analyst authors it directly with a name, a scan type and a set of target assets. This is the quick-create path for a one-off confirmation run or a scoped check that does not need to be tied to a vendor schedule. PMAP exposes this through a New Scan wizard guarded by a scan:create permission, so authoring a scan is a deliberate, role-gated action rather than something any viewer can trigger.
The second path is the integration-backed scan. Here the scan is linked to a vendor integration through an integration_id and an external_scan_id. That linkage is what unlocks the rest of the lifecycle. Because PMAP knows which vendor owns the scan and which external identifier it carries, it can poll that vendor for status, drive remote controls and request a remote delete. A manual scan with no integration link is a record. An integration-backed scan is a live, controllable execution.
The third path matters in larger deployments. Many enterprises do not run a single appliance. They run a fleet, for example several Nessus nodes underneath a Tenable.sc deployment. PMAP lets a scan be pinned to a specific child appliance through a sub_scanner_id, so an assessment lands on the correct node instead of being load-balanced somewhere unexpected. For a security engineer running a multi-node estate, this pinning is the difference between a reproducible assessment and a guess about where the scan actually ran.
There is a fourth dimension worth calling out for pipeline-driven teams. A scan can carry CI and VCS metadata, including commit_sha, branch_name, pr_number, repo_url and triggered_by. This is what makes a pipeline-triggered scan traceable back to the exact code change that caused it. The lifecycle layer does not just track that a scan ran. It records why it ran and what it ran against.
Two guardrails sit on creation itself. A scan name must be unique within the same company, and a duplicate name is rejected with HTTP 409 so you never end up with two indistinguishable “Weekly Prod Sweep” records competing for attention. Scan creation is also blocked entirely when the target company is deactivated, so a paused tenant cannot accumulate new scan work it should not be doing. Both rules keep the lifecycle clean at the moment of birth, which is the cheapest place to keep it clean.
A Vendor-Neutral Status Model
The heart of a lifecycle layer is its status model, and the whole point is that the model is yours, not the vendor’s. Different scanners use different words for the same idea. One vendor says canceled, another says cancelled. One emits error, another leaves the field empty while a scan waits in queue. If your status model is just a passthrough of whatever string the vendor sent, your dashboard becomes a dialect problem.
PMAP solves this with a canonical status set and a translation table. The canonical lifecycle flows from queued to running, into paused and back to running on resume, and then to one of the terminal states. The terminal states are completed, failed and cancelled. There is also an importing state that represents the window where a completed scan’s results are being pulled into PMAP. Every vendor’s raw status string is mapped into this set through a statusMap. A vendor running becomes running, paused becomes paused, completed becomes completed, both canceled and cancelled collapse to cancelled, error becomes failed, queued becomes queued, and an empty Nessus status is treated as queued. The dialect problem disappears because translation happens once, at the boundary.
One subtle behavior is worth highlighting. The first time a scan transitions to running, PMAP stamps started_at automatically if it was previously empty. A resume after a pause re-enters the running state but does not overwrite that original start time, so your duration math stays honest. The clock starts once.
System-Written Status, Not Analyst-Written
There is an important design choice underneath this model. Scan status is written by the system, specifically by the background sync loop and the import pipeline, not by an analyst clicking a dropdown. This is deliberate and it is the right call.
A finding’s status is a human judgment, and PMAP rightly governs that with a state machine, an approval flow and ownership rules. A scan’s status is a fact about an execution. It is “what is the scanner actually doing right now,” and the only authoritative source for that fact is the scanner itself, observed through the vendor API. Letting an analyst hand-edit a scan to “completed” would be letting someone overrule reality. By keeping scan status system-written, PMAP guarantees that the lifecycle layer reflects the world rather than someone’s hope about the world. Notably, PMAP does not impose a rigid validTransitions map on scan status the way it does on findings, precisely because the vendor, not PMAP, owns the truth of where a scan currently sits.
Live Monitoring on the Scan Detail Page
Once a scan exists and has a normalized status, you need to watch it. The Scan Detail page is where the lifecycle becomes observable in real time.
The page opens with a KPI row that summarizes what matters at a glance: total findings, the percentage of findings already imported, asset and target counts, duration and finish time. Below that sits a metadata panel that ties the scan to its context, including its status, scan type, integration link, sub-scanner, assessment run, schedule and timestamps. The working surface is a set of tabs. The Scanner tab shows a live vendor preview with host count, vulnerability count, per-severity chips and a vulnerability table, plus an Import call to action when nothing has been imported yet. The Findings tab holds the imported findings with bulk status actions. The Config tab exposes the raw configuration and target asset list. The Activity tab is a chronological feed of every lifecycle event the scan has been through.
The detail page does not make you press refresh. While a scan is running or importing, the Scanner and Activity tabs auto-refresh every 8 seconds, so progress moves in front of you. That cadence is paired with a 30-second background ticker that pulls fresh status, progress, findings count and per-severity counts from the vendor for all active scans. The combination matters. The 30-second ticker keeps the underlying data current across the whole estate. The 8-second page refresh keeps the detail view you are staring at in step with that data. An analyst can sit on a running scan and watch it progress without a single manual reload, which is exactly the experience you want when you are confirming that a critical host finished its sweep.
Remote Scan Controls Without Leaving PMAP
Watching a scan is half the job. Acting on it is the other half. A lifecycle layer that can only observe is a read-only dashboard. PMAP adds a control plane so engineers can drive the scan itself.
From the Scan Detail action bar, an integration-backed scan exposes launch, pause, resume and stop controls. These are not local state changes. They issue commands to the vendor through the integration layer, so pausing a scan in PMAP pauses the actual run on Qualys or Nessus. This is the behavior that ends console hopping for the most common operational actions. An engineer who needs to pause a noisy scan during a change window can do it from the same screen where they are watching it, instead of logging into the vendor to find the right button.
The control surface is honest about its limits. When a scan lacks an integration_id or an external_scan_id, the remote control buttons are disabled with a tooltip explaining why, because there is no vendor target to send the command to. And the controls respect per-vendor capability differences. Invicti, for instance, does not expose a launch action, so PMAP simply does not show a Launch button for Invicti-backed scans rather than offering a control that would fail. The lifecycle layer adapts to what each vendor can actually do instead of pretending every vendor is identical.
Auto-Import the Moment a Scan Completes
The most valuable moment in a scan’s life is the instant it completes, because that is when its results become actionable. A lifecycle layer earns its keep by not wasting that moment.
When the background sync loop observes a scan transition to completed, PMAP does not wait for a human to remember to pull the results. It automatically triggers asset import, findings import and enrichment in the background. The scan’s completion is the trigger; the ingestion happens on its own. This is the seam where the lifecycle layer hands off to the rest of the platform. The scan stops being a thing you watch and becomes a set of correlated findings you can triage.
This auto-import behavior is the reason the lifecycle layer is described as upstream of findings ingestion. It is also why the importing state exists as a distinct phase. Between “the scanner says it is done” and “the findings are correlated and ready,” there is a real window of work, and the status model makes that window visible rather than hiding it behind a binary done flag. If you want to walk a single vendor through this completion-to-ingestion flow as a hands-on procedure, the import a Tenable Nessus scan end to end guide steps through it concretely. The mechanics of how many scanners feed that pipeline and how their results are correlated are a separate topic covered in multi-vendor scan import.
Orphan Adoption: Never Fall Behind the Scanner
Here is a failure mode that quietly defeats most “single pane of glass” attempts. A scan gets launched directly in the vendor console, by someone who never touched your management layer, or by an automated process the management layer did not initiate. That scan exists in reality but not in your dashboard. Over weeks, the gap between what the scanners did and what your platform knows about grows, and the single pane stops being a faithful mirror.
PMAP closes this gap with orphan adoption. Every 5 minutes, a background sweep queries each active integration for its full vendor scan list and inserts PMAP rows for any scans that exist on the vendor but are not yet in PMAP. The effect is that the Scans page stays a faithful mirror of the scanners without anyone manually registering scans. A scan someone launched in Qualys at lunch shows up in PMAP a few minutes later, fully tracked, with its lifecycle observable from that point forward. If an adopted scan is already complete, PMAP immediately fires its asset import, findings import and enrichment, so you do not just see the orphan, you actually get its results.
Adoption is what turns the lifecycle layer from a place where PMAP-initiated scans live into a place where every scan lives, regardless of who started it. That distinction is the whole promise of a single lifecycle layer, and adoption is the mechanism that makes the promise true. For teams that want to dig into the scheduling and live-sync background machinery that powers adoption and the status ticker, that automation layer is covered separately in the scheduling and live sync deep dive.
The Blocklist Guard: Deleted Stays Deleted
Orphan adoption creates an obvious problem if you are not careful. If PMAP automatically re-creates any vendor scan it does not already have, then deleting a scan from PMAP is pointless, because the next adoption sweep would just bring it back. A naive adoption loop would make deletion impossible.
PMAP solves this with a blocklist guard. When you delete a scan, its (integration_id, external_scan_id) pair is written to a blocklist. The orphan adoption sweep checks that blocklist on every pass and skips any pair it finds there. Deletion therefore means what it says. A scan you remove stays removed, even though the same scan may still exist on the vendor and would otherwise be a candidate for re-adoption. The blocklist is the small piece of state that makes automatic adoption and intentional deletion coexist. Without it, you would have to choose between a self-maintaining mirror and a delete button that works. The guard lets you keep both.
Cascade Remote Delete and Best-Effort Vendor Cleanup
Deletion itself deserves a careful design, because a scan exists in two places at once: the PMAP record and the vendor copy. A lifecycle layer has to decide what “delete” means across that boundary.
PMAP gives you the choice through a cascade flag. A plain delete removes the PMAP scan and writes the blocklist entry, leaving the vendor copy untouched. A cascade delete, requested with cascade_remote=true, additionally asks the upstream vendor to delete its own copy of the scan. This is the option for engineers who want a scan gone everywhere, not just hidden from their dashboard.
The crucial behavior is how PMAP handles the case where the vendor cleanup fails. The local delete is treated as authoritative and always succeeds, and the vendor delete is best-effort. If the vendor call fails, PMAP does not roll back the local deletion. Instead it completes the local delete and includes a warning in the response body about the vendor-side failure. This is the right tradeoff. The alternative, refusing to delete locally because a remote API hiccuped, would mean a vendor outage could hold your own records hostage. By making local deletion unconditional and surfacing vendor failures as warnings rather than hard errors, PMAP keeps your management layer under your control while still being transparent about what happened on the far side.
Tenant-Safe Scan Access
A multi-vendor lifecycle layer is almost always a multi-tenant one. An MSSP or a large enterprise with separated business units needs hard guarantees that one tenant cannot see, touch or even probe another tenant’s scans. The lifecycle layer is only trustworthy if its isolation is airtight.
PMAP enforces scope at every entry point. Every list query applies a scope filter from the authenticated context, so a user only ever sees scans within their own tenancy. The more interesting detail is how PMAP handles direct access to a specific scan. When a user requests a scan, deletes one, imports one or pulls its findings delta, the access check returns HTTP 404 rather than 403 for any scan outside their tenant. This 404-not-403 choice is a deliberate anti-enumeration measure. A 403 would confirm that a scan with that UUID exists, just not for you, which leaks information. A 404 says nothing more than “no such scan here,” so an attacker cannot walk the UUID space to discover which scans exist in tenants they should not know about. Creation and deletion additionally enforce a mutation permission check. Isolation is not a setting you turn on. It is the default behavior of every code path that touches a scan.
How PMAP Becomes Your Scan Orchestration Hub
Step back and the pieces compose into a single claim. PMAP is the place where a scan lives its whole life. It is created there, whether manually authored or adopted from a vendor. It is monitored there, through a normalized status model and a live-refreshing detail page. It is controlled there, through remote launch, pause, resume and stop. It completes there, with automatic handoff to findings ingestion. And it is deleted there, permanently, with a blocklist that prevents resurrection and a cascade option that reaches back into the vendor.
The value of consolidating the lifecycle is measurable. Teams can track scans created per day split by manual versus integration-backed, the orphan adoption rate, average scan duration by vendor, and sync lag defined as the time between a vendor marking a scan complete and PMAP reflecting that status. Those metrics only exist because the lifecycle is observed in one place. You cannot measure sync lag across seven consoles. You can measure it across one hub.
That is the difference between owning a collection of scanners and operating a scanning program. A collection is what you have when each tool manages its own scans in its own console. A program is what you have when one lifecycle layer governs all of them with a shared vocabulary, a shared control surface and shared guarantees about deletion and isolation. For the full orchestration picture that this lifecycle layer plugs into, the multi-vendor scan orchestration pillar ties scan lifecycle together with import correlation, scheduling and the integration fabric underneath.
If you want to see scan lifecycle management running against your own scanners, see how PMAP manages every scan from one console and never lags behind the scanner.
Frequently Asked Questions
What is scan lifecycle management?
Scan lifecycle management is the practice of governing a vulnerability scan through its entire life from a single layer, rather than inside each scanner’s own console. It covers creation, status tracking, live monitoring, remote control actions and deletion. In PMAP, this layer normalizes every connected scanner into one vendor-neutral status model and acts as the orchestration hub that hands completed scans off to findings ingestion.
How does PMAP track scan status across different scanners?
PMAP uses a canonical status set that flows from queued through running and paused to terminal states of completed, failed or cancelled, with an importing phase for the ingestion window. Each vendor’s raw status string is translated into this set through a mapping table, so error becomes failed and both canceled and cancelled collapse to cancelled. Status is written by the system through the sync loop and import pipeline, never hand-edited by an analyst, because the scanner itself is the only authoritative source for what a scan is actually doing.
What is orphan scan adoption and why does it matter?
Orphan scan adoption is a background sweep that runs every 5 minutes, queries each active integration for its full vendor scan list, and creates PMAP records for any scans that exist on the vendor but not yet in PMAP. It matters because scans launched directly in a vendor console would otherwise stay invisible to your management layer. Adoption keeps the Scans page a faithful mirror of every scanner without anyone manually registering scans, and it auto-imports results for any adopted scan that is already complete.
Can I delete a scan from both PMAP and the vendor at once?
Yes. A plain delete removes the PMAP record and leaves the vendor copy untouched, while a cascade delete requested with cascade_remote=true also asks the vendor to delete its own copy. The local delete always succeeds and is never rolled back. If the vendor-side cleanup fails, PMAP still completes the local deletion and includes a warning in the response body about the vendor failure, so a vendor outage cannot block you from managing your own records.
What stops a deleted scan from coming back through orphan adoption?
A blocklist guard. When a scan is deleted, its (integration_id, external_scan_id) pair is written to a blocklist. The orphan adoption sweep checks that blocklist on every pass and skips any pair it finds there, so a scan you remove stays removed even though it may still exist on the vendor. The blocklist is what allows automatic adoption and intentional deletion to coexist without one undoing the other.
Can I control a scan remotely without opening the vendor console?
For integration-backed scans, yes. The Scan Detail action bar exposes launch, pause, resume and stop controls that send commands to the vendor through the integration layer. The controls respect each vendor’s capabilities, so PMAP does not show a Launch button for Invicti because Invicti does not support that action. When a scan lacks an integration link or an external scan identifier, the remote controls are disabled with a tooltip, because there is no vendor target to act on.
How does PMAP keep one tenant’s scans isolated from another’s?
Every list query applies a scope filter from the authenticated context, so users only ever see scans within their own tenancy. For direct access to a specific scan, reads, deletes, imports and findings-delta calls return HTTP 404 rather than 403 for any scan outside the user’s tenant. This 404-not-403 behavior prevents an attacker from enumerating scan UUIDs to discover which scans exist in tenants they should not know about. Creation and deletion additionally enforce a mutation permission check.
