From vulnerability finding to verified remediation
A validated finding with an affected asset, accountable owner, action and recorded verification result.
Before you start
Exposure discovery becomes useful when a finding reaches the right owner with enough evidence to fix and verify it. A long list of scanner results is only the starting point. The workflow must distinguish an observed condition from a suspected vulnerability and from a completed remediation.
Use this guide for authorized asset assessment and triage. It connects discovery to a response decision without requiring exploit attempts. Start with a small representative scope so the team can check operational impact and result quality before expanding.
Have these ready
- An approved asset scope, exclusions and assessment window.
- Service ownership, business context and a contact for scan-related issues.
- Current scanner configuration, feed information and a place to track remediation.
1. Establish the asset and assessment boundary
List the domains, addresses or services you are authorized to assess, plus exclusions and stop conditions. Confirm ownership before adding assets discovered through shared infrastructure. Include cloud and third-party dependencies only when the assessment scope covers them.
Choose checks appropriate to the service and the approved window. Greenbone documents explicit targets, exclusions, port lists and authenticated checks. Its documentation notes that permissions affect authenticated-scan coverage. A completed job therefore does not establish that every intended check actually ran.
2. Validate the finding and keep the evidence
Retain the asset identifier, observation time, scanner and feed versions, check identifier and supporting response. Distinguish a version inferred from a banner from one established by an authenticated check or the asset owner. Track unreachable hosts, failed authentication and incomplete scans separately from clean results.
For web exposure work, Artemis documents modular checks and generated reports, while its upstream README labels the software experimental. Pilot the checks you need and review the evidence before notifying an owner. A generated report still requires a correct asset-to-owner mapping.
3. Prioritize using exposure and business context
Combine the validated technical finding with internet reachability, affected service, privileges required, compensating controls and credible exploitation information. Record the reasoning for the priority. A severity score should not erase the difference between an exposed critical service and an unreachable test system.
FIRST describes EPSS as an estimate of the probability that a published vulnerability will be exploited in the next 30 days. Treat that as one input, not a statement that your particular asset was attacked or a guarantee that a low-scoring issue is safe. Keep the score date with the assessment.
4. Give the owner a verifiable action
Provide the affected asset, evidence, likely impact and a vendor-supported remediation reference where available. Ask the owner to confirm the affected version and agree a target date or an interim mitigation. If the finding is disputed, record the contrary evidence and who will review it.
OpenCVE documents monitoring vulnerabilities and tracking changes for subscribed vendors and products. Use that kind of change awareness to revisit a finding when an advisory evolves. A product subscription does not establish that the organization has an affected instance; connect it to an accurate asset inventory.
5. Verify the change and preserve the residual gap
Recheck the relevant condition using an approved method after the change. Record the verification time, method and result. When a mitigation reduces exposure without removing the vulnerable component, describe that distinction and set a review point.
A host that disappears from a scan may be offline, moved or blocked from the scanner. Confirm the reason with the owner before closing. Keep the original finding, remediation evidence and final disposition together, so a later reappearance can be assessed without reconstructing the first report.
Handoff checks
Before passing the work on, confirm that:
- The assessed asset and authority to test it are clear.
- Failed or incomplete checks are distinguishable from clean results.
- The priority has evidence beyond a single severity number.
- The owner has a concrete action and verification method.
- Closure says whether the issue was fixed, mitigated, disproved or accepted.
Tools to evaluate
These profiles document different parts of the workflow. Their inclusion is not a ranking or a claim that they form an integrated stack.
OPENVAS SCAN
Evaluate for vulnerability scanning with explicit targets and credentialed checks. Confirm the commercial edition, feed and scan coverage required.
Artemis
Evaluate for modular web checks and reports after a controlled pilot. The upstream project labels its status experimental.
OpenCVE
Evaluate for following relevant CVE and advisory changes. Match subscriptions to your own asset and product inventory.
Sources and review
Primary documentation checked on . The numbered sequence and handoff checks are editorial recommendations. Product behavior and availability may change; this guide does not report hands-on testing.
- Greenbone — OPENVAS SCAN assessment configuration
- Artemis — Project scope and status
- FIRST — Exploit Prediction Scoring System
- OpenCVE — Documentation