Scanner onboarding and coverage rollout workflow
one engagement record from pilot scope through fleet coverage and steady-state operation

A documented sample (typically 30 to 100 findings depending on the pilot scope) where each finding has been manually reviewed for true-positive status. The ratio is the share of true positives in the sample. The threshold is a programme decision rather than a vendor default; common thresholds sit between 70 and 90 percent depending on the rule class.

The complement of the signal-to-noise read split by rule class. The split surfaces rule classes that drive most of the false positives so the rule-pack tuning targets the right rules rather than disabling the scanner because of a handful of noisy rules. The programme keeps the rule-class breakdown on the engagement record for the fleet rollout phase.

The wall-clock time from the scanner running its first scan in the pilot scope to the first finding the programme accepted onto the open queue with a named owner, a calibrated severity, an asset binding, and a remediation owner who has acknowledged the assignment. The signal that distinguishes a scanner that produced operationally useful work in the pilot from one that produced output nobody acted on.

For an external scanner: the share of the in-scope external surface the scanner reached relative to the documented external attack surface. For a SAST scanner: the share of in-scope repositories the scanner ran against relative to the documented codebase scope. For a KSPM or CSPM scanner: the share of in-scope clusters or cloud accounts the scanner read posture from. The signal that distinguishes a deployed scanner from a configured-but-not-running scanner.

The wall-clock time per finding from the scanner output landing on the engagement to a named owner accepting the assignment with a calibrated severity, an asset binding, and a remediation plan. The signal that distinguishes a scanner whose output is operationally cheap to triage from one whose output requires three operator passes before it becomes useful work.

Vendor severity scales rarely match the workspace policy. The calibration map names the source severity per rule class and the workspace severity per rule class, with cited rationale where the mapping moves the severity (asset criticality of the typical target, exploitability under the typical deployment, blast radius of the typical fix). The calibration lands on the engagement as a versioned configuration so the audit lookback reads the mapping with provenance.

Where the scanner provides a CVSS vector, the calibration preserves the full vector string on the finding so the workspace policy can derive the score from the metrics rather than from the unsourced number. Where the scanner does not provide a vector, the calibration documents the per-rule-class default vector the workspace will apply, with cited rationale for the metric choices.

Scanner output names assets in scanner-native form (a hostname, an IP, a repository URL, a cluster ARN, a cloud-account ID, a container image tag). The asset binding maps those to the workspace identifiers (the verified domain, the repository connection, the engagement scope) so the cross-engagement view groups findings by asset rather than by scanner-native string.

Many scanners ship category taxonomies that do not align with CWE or with the workspace controlled-vocabulary. The calibration map names the scanner category, the workspace category, the CWE reference (where applicable), and the rationale for the mapping. The reporting view reads the workspace category rather than the scanner-native string.

A new scanner that does not deduplicate against the existing catalogue will mint parallel records for findings the workspace already holds. The dedup rules name the identity key (asset plus rule reference, asset plus CWE, asset plus title pattern) the workspace uses to recognise an existing finding so the new scanner attaches its detection as evidence rather than creating a new parallel record.

The SLA breach calculation reads against the calibrated severity rather than the vendor default. The SLA mapping ties the workspace severity to the SLA policy (typically tied to severity bands such as Critical/High/Medium/Low with corresponding day counts) so the breach posture from day one of the fleet rollout reads from the calibrated severity.

For SAST and SCA findings, the repository owner on the workspace repository-connection record inherits the routing. The named owner is responsible for the per-repository disposition: code change, dependency upgrade, accepted-risk override with cited rationale, or false-positive suppression with rule-pack tuning. The owner archetype maps to the application security programme leads and the engineering teams that own the repositories.

For DAST and authenticated DAST findings, the application owner on the engagement scope inherits the routing. The named owner is responsible for the per-application disposition. The owner archetype maps to the application security programme leads, the product security teams, and the engineering teams that own the applications.

For KSPM and cluster-posture findings, the platform team that owns the cluster lifecycle inherits the routing. The named owner is responsible for the cluster-level disposition. The owner archetype maps to the platform engineering teams.

For CSPM and cloud-posture findings, the cloud account owner on the workspace account record inherits the routing. The named owner is responsible for the account-level disposition. The owner archetype maps to the cloud security teams and the platform engineering teams.

For external scanning findings, the attack-surface owner on the verified-domain record inherits the routing. The named owner is responsible for the per-host or per-service disposition. The owner archetype maps to the internal security teams, the AppSec teams, and the platform engineering teams that own the external footprint.

The pilot ran for two weeks against one application, the team enabled the scanner against the full fleet on a Friday afternoon, and Monday morning brought 4,000 open findings most of which were false positives or duplicates of records the existing catalogue already held. The fix is the documented phase plan with named expansion criteria, the phase-gate review with the named approver before the scope widens, and the rollback condition that returns the scanner to the prior phase if the next-phase criteria do not hold.

The CSV import accepted the scanner output as is, the asset reference was a hostname the scanner emitted but the workspace inventory does not recognise, and the owner-routing rules could not match the finding to a named owner. The fix is requiring the asset binding to resolve against the verified domain list, the repository connections, or the engagement scope before the finding opens on the open queue. Imports that do not resolve land in a hygiene queue rather than corrupting the operational view.

The scanner classified every detection as High because the vendor scale defaults to High for any rule fire, the workspace SLA policy then treated every finding as a 30-day SLA, and the queue blew past breach within a cycle. The fix is the explicit severity calibration map on the engagement record: the source severity per rule class, the workspace severity per rule class, the rationale where the mapping moves the severity, the named approver of the mapping, and the activity-log capture so the audit lookback reads the calibrated severity with provenance.

Findings the programme accepted as a risk last quarter with a documented expiry landed again from the new scanner, opened on the queue as new records, and the team re-debated whether to accept. The exception register was invisible to the new scanner intake path. The fix is wiring the exception register filter into the new scanner intake from phase one so findings that match an active acceptance, deferral, or false-positive suppression inherit the existing record and the existing expiry rather than minting a new ticket the team has to dismiss.

The scanner produced findings across SAST rule classes, the scanner finding output did not carry an owner field, and the routing rule defaulted to the AppSec lead inbox where everything queued behind everything else. The fix is the per-finding-class routing rule documented on the engagement record before the fleet rollout: which finding classes route to repository owners, which to AppSec leads, which to platform owners, which to cluster owners. The named owner on the asset record is the routing anchor; the routing rule resolves the class-to-owner mapping at intake.

The pilot logged false positives in chat, no rule-pack tuning was recorded, and the fleet rollout brought the same false positives onto a 50x larger surface. The fix is the documented false-positive review during the pilot: a manually validated sample, a structured tuning record per rule, the rule-pack overrides the programme is willing to maintain, and the named owner of the rule-pack tuning so the fleet rollout starts from a tuned baseline rather than the vendor default.

Findings imported as bulk records with no scanner name, no rule reference, no rule-pack version, and no scan ID. Six months later the audit assessor asked which scanner produced which finding and the answer was a folder of CSV files in shared storage. The fix is the structured source-attribution capture on every import: the scanner name, the rule reference, the rule-pack version, the scan ID, the scan timestamp, the engagement reference. The activity-log chronology reads from the import event through the closure event without gaps.

The programme moved off a scanner after the quarterly review, the replacement tool was already in fleet rollout, and the old scanner findings sat on the queue without a documented disposition. Six months later the audit asked who owned a five-year-old open finding from a scanner the company no longer ran. The fix is the documented sunset engagement that closes or migrates every open finding produced exclusively by the sunsetting scanner, captures the named approver of the sunset, and exports the activity-log chronology so the historical record stays defensible.

The view that distinguishes a scanner ready to expand from one that needs calibration adjustment before the next phase. The trend lives on the engagement record and the manually validated sample feeds the read.

The proportion of the in-scope surface the scanner is configured against versus the documented eventual perimeter. The view that distinguishes a scanner in active rollout from one that is configured for a perimeter but not running against it.

The proportion of new scanner findings that resolve to a named owner at intake without manual handoff. The view that distinguishes a calibrated owner-routing rule set from one that defaults to a shared inbox.

The proportion of new scanner findings whose severity carries the calibration rationale and the named approver on the activity log. The signal that distinguishes a scanner whose severity is reproducible from one whose severity reads as the unsourced vendor default.

The proportion of new scanner findings that match an active acceptance, deferral, or false-positive suppression and inherit the existing record. The signal that distinguishes a scanner intake that respects the exception register from one that reopens accepted risks every cycle.

The proportion of imported scanner findings that carry the scanner name, rule reference, rule-pack version, scan ID, and scan timestamp. The signal that distinguishes a defensible audit trail from a folder of CSV files in shared storage.