Which assets are covered, and are their scanners actually ready?
Review managed assets, discovered services, scanner assignments, appliance links, profiles, readiness, last scan, and open-finding counts before trusting the posture view.
Capability
Vulnerability and hardening
Vulnerability results, hardening checks, remediation work, and verification evidence stay connected.
Managed asset coverage
Durable scan activity
Grouped findings and provenance
Hardening assignments
Operational need
Vulnerability findings and hardening controls need traceable source evidence, safe remediation boundaries, verification results, and reports that preserve when the evidence was captured.
Teams can distinguish what scanners observed from what hardening automation changed, then verify and report both without losing provenance.
Operating signals
- Scanner output exists, but remediation ownership and follow-up state are unclear.
- Hardening work happens, but evidence is disconnected from the original finding.
- Reports are assembled after the fact instead of reflecting the work path.
What you get
Where it starts
Common starting points.
These examples enter the product surface that owns their state. They do not all become a case, ticket, owner, or shared evidence record automatically.
Is this one isolated observation or the same vulnerability across several assets?
Switch between grouped vulnerabilities and finding instances while retaining CVE, CVSS, severity, scanner, asset, status, first seen, last seen, and source run.
What did the scanner actually observe, and what fix did it recommend?
Open the finding detail for descriptions, affected targets, raw bounded scanner evidence, scan provenance, and scanner-supplied remediation guidance.
Can this hardening benchmark audit only, or can it safely remediate?
Keep executor capability visible, assign the right target, apply global or per-target control state, and require confirmation before a supported remediation changes configuration.
Did remediation reach the desired state?
Review each control status and the recorded operation, target, before value, desired value, after value, outcome, and any precondition, write, or verification error.
What can be reported now without rewriting history later?
Save immutable vulnerability snapshots for executive, technical, or asset views, while generating hardening compliance from the current retained run results.
How it works
How work moves.
The product path below names its inputs, decisions, controls, and output without implying the same lifecycle applies to every capability.
- 01
Discover and enroll
Review discovered hosts and services, promote selected candidates, and attach available scanners and profiles to managed assets.
- 02
Scan and retain
Run scanners manually or by central schedule and keep per-scanner progress, configuration, outcome, and diagnostic history.
- 03
Review findings
Group related issues for prioritization without losing the individual asset observation, evidence, remediation guidance, or source run.
- 04
Audit controls
Apply benchmark scope and overrides to assigned targets, then record pass, fail, skipped, not-applicable, unsupported, permission, authentication, or execution error state.
- 05
Remediate and verify
For supported benchmarks, confirm the change and retain the operation plus before, desired, after, outcome, and verification error evidence.
- 06
Snapshot and report
Create immutable vulnerability snapshots or generate current hardening compliance without confusing one report type for the other.
Product model
Security posture model.
The diagrams show how coverage becomes traceable scanner evidence, how grouped vulnerabilities preserve each affected asset, how supported hardening changes retain verification proof, and why report snapshots state when their truth was captured.
Coverage to finding
A finding starts with a covered asset and a durable run.
Discovery can promote a candidate into a managed asset. Scanner assignment, profile, readiness, and run provenance remain attached when normalized findings appear as grouped issues and individual asset observations.
Finding provenance
Grouping never removes the source observation.
A vulnerability group helps prioritize a shared CVE or matching issue, while each finding keeps its asset, scanner, severity, status, timestamps, raw evidence, remediation guidance, and source run.
Controlled hardening
Supported remediation must prove the after state.
Benchmark capability and effective control state define what can run. After explicit confirmation, supported remediation records operation, target, before, desired, after, outcome, and any verification failure.
Report truth
Snapshots and current compliance answer different questions.
Saved vulnerability reports preserve an immutable point-in-time context for executive, technical, or asset views. Hardening compliance is generated from retained target and control results with excluded states called out.
What it includes
What the record shows.
These parts participate in the workflow. The record shows what was used and why it mattered.
Discovery and managed assets
Discovery candidates, services, promoted assets, scanner assignments, readiness, recent runs, and finding counts form the coverage model.
Discovery targets, candidates, managed assets, services, and assignments
Scanner control plane
Installed scanner availability, reusable descriptor-driven profiles, central schedules, bulk starts, live progress, outcomes, and diagnostic logs stay reviewable.
Appliances, scanner inventory, profiles, schedules, queues, and runs
Vulnerability workspace
Normalized groups and bounded finding instances expose CVE, CVSS, severity, affected asset, status, timestamps, scanner evidence, remediation guidance, and provenance.
Finding groups, instances, canonical identity, and source run links
Hardening catalog and controls
Benchmarks define executor capability, controls, defaults, parameters, global state, and per-target overrides before work is dispatched.
Benchmark catalog, controls, assignments, states, parameters, and overrides
Hardening runs and evidence
Audit and supported remediation retain target, mode, status, per-control results, operation detail, before/desired/after snapshots, and structured failure stage.
Agent or integration executor, result records, and normalized evidence
Security reports
Executive, technical, and asset vulnerability snapshots can be saved and exported; hardening compliance reports summarize applicable control results by target.
Immutable vulnerability snapshots and generated hardening compliance
Control model
Controls stay specific to the workflow.
Integrations, AI assistance, routines, and agents use different permissions and records. The controls below describe this capability rather than a universal approval model.
A scanner finding supplies evidence and remediation guidance; it does not automatically prove that a fix ran or close itself as remediated.
Scanner profiles use scanner-defined fields, and durable runs preserve configuration, progress, outcome, and diagnostic provenance.
Hardening remediation is exposed only when the benchmark executor supports it and requires an explicit confirmation because it changes target state.
Agent-supplied hardening evidence is validated and bounded before storage; unsupported, permission, authentication, and verification failures remain distinct.
Saved vulnerability reports are immutable point-in-time snapshots; current hardening compliance is a separate generated view over retained results.
Value over time
Product path for Hardening.
Observe
Inspect scanner records
Managed assets, scan state, findings, and source provenance remain visible.Assess
Run supported hardening checks
Profiles, targets, checks, and collected evidence remain explicit.Act
Review supported remediation
Applicable remediation returns execution state and output in its own record.Next step
Want to see hardening on your stack?
Book a walkthrough and I will map this workflow to the integrations and controls you already use.