Key Takeaways:
- Match vulnerability intelligence with current installation evidence to identify affected devices. NVD records become actionable through those connections.
- Assign remediation at the affected-device level. One vulnerability can require different owners and maintenance windows across the environment.
- Prioritize using exploitation evidence, business impact, exposure, and technical severity. Record why each finding needs its assigned response time.
- Confirm each fix took effect before recording remediation. Keep temporary mitigations, unresolved deployments, and approved exceptions distinguishable in reporting.
The vulnerability management lifecycle is the recurring process of identifying, prioritizing, and addressing security weaknesses. IT teams verify each response and reassess as devices and software change. A vulnerability can remain open after a patch has been deployed. An offline device may miss the update, or an outdated software record may obscure its current state. IT teams need to connect the finding, corrective action, and verified result.
Accurate IT asset records give that process a reliable starting point. They connect the affected installation with its device, responsible owner, and lifecycle state, helping IT teams target corrective work.
When evaluating vulnerability tracking, follow those connections through the full lifecycle. The chosen platform should help IT teams investigate findings, carry out the response, and check whether it worked.
What the vulnerability management lifecycle covers
For managed endpoints, the lifecycle starts with defining which devices and software to assess. Each finding stays in scope until IT teams verify the fix or document how they will manage the remaining risk. The National Institute of Standards and Technology (NIST) maintains the National Vulnerability Database, or NVD. It enriches published Common Vulnerabilities and Exposures (CVE) records with vulnerability information.
NVD records describe known flaws and affected products. Endpoint assessments establish which installations in the managed environment match those conditions.
Start with managed endpoints and their software. Record verified remediation or a separate risk decision, then reassess as systems change. Application code and specialized infrastructure require assessment methods suited to those systems.
Prepare the records and access needed for remediation
Agree on responsibilities before the first assessment. Identify who investigates findings, implements fixes, and approves changes to business services.
Confirm access to:
- Device records, installed software versions, and recent assessment results.
- Approved scanning or assessment tools and authorized target scope.
- Vendor advisories, installation packages, and change records.
- Deployment permissions, representative test devices, and recovery procedures.
- A tracking system for assignments, deadlines, verification evidence, and exceptions.
In AssetSonar, open “Settings > Patch Management,” select “Enable,” then “Update.” Install the supported ITAM Agent on Windows, macOS, and Linux devices being assessed and patched.
Distinguish the device’s user from its remediation owner. Assign a service owner for shared systems.
How to manage the vulnerability management lifecycle
Work through these eight steps for each assessment cycle. Keep the initial scope available throughout execution so missed devices remain visible.
Step 1: Establish an accurate device and software baseline
Define the devices covered by the cycle, including remote endpoints and systems awaiting replacement. Compare hardware discovery results with the expected device list to identify missing endpoints.
Match each endpoint to its record using a valid serial number or another trusted identifier. Check its lifecycle state, responsible administrator, assessment date, and relevant software versions. Investigate duplicates or records that stopped updating.
Keep a separate list of devices without recent assessments. A laptop’s earlier results do not establish its current state when it remains unreachable.
In AssetSonar, review the IT Asset Accuracy indicators for device-record issues. Check assessment coverage separately, since an accurate record does not establish that vulnerability assessment succeeded.
Proof: A dated device list identifies assessed endpoints, coverage gaps, and assigned follow-up owners.
Step 2: Discover vulnerabilities against current installations
Assess the baseline using authorized endpoint agents or vulnerability scanners suited to the systems involved. Confirm that collection completed successfully and that credentials worked where authenticated scanning is required.
Connect findings to the observed product, version, and device. Software discovery supplies installation details; vulnerability assessment determines which known weaknesses apply to those installations.
AssetSonar uses its ITAM Agent to match discovered software against NIST NVD vulnerability data. In AssetSonar, open “Patch Management > Vulnerabilities” to review detected CVEs and affected devices.
Preserve the first observation and latest assessment time to distinguish recurring findings from unresolved ones. Retain assessment errors for investigation.
Proof: Each finding links to device evidence, with incomplete assessments listed separately.
Step 3: Validate whether each finding applies
Review the vulnerability’s affected products, version ranges, and vendor advisory before selecting a fix. Check architecture, installed edition, and configuration requirements when they change applicability.
A similar product name alone is insufficient evidence. Confirm the installed build against the vendor’s affected and fixed releases, especially when packages use distribution-specific versioning.
AssetSonar’s vulnerability management connects CVEs with device and software context. Select a CVE ID to open its “Vulnerability Details” page and review its linked references.
If version evidence conflicts with the advisory, assign the finding for technical review. Record the reviewer’s decision and supporting evidence before classifying a false positive.
Proof: Each reviewed finding has an applicability decision or assigned investigator.
Step 4: Prioritize the exposure and assign remediation ownership
Use technical severity as one input to the patching priority. The Common Vulnerability Scoring System, or CVSS, describes severity; local exposure and business consequences determine operational urgency.
Check the CVE against the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities catalog. Where useful, consult FIRST’s Exploit Prediction Scoring System, which estimates exploitation probability over the next 30 days.
Combine those signals with internet reachability, service importance, sensitive access, and existing protective controls. An exploited flaw on an exposed service may warrant action before a higher-scoring issue on an isolated test device.
Assign an implementing owner and a target date under the organization’s risk policy. Record the decision basis and escalation contact.
Proof: The work queue has justified priorities, accountable owners, and reviewable deadlines.
Step 5: Select and test the corrective action
Choose the response that addresses the affected condition. Depending on the advisory, that may involve patching, upgrading, changing configuration, removing software, or replacing an unsupported system.
Acquire packages through trusted vendor channels. Check their signatures or vendor-published checksums before testing. Test on devices representing the operating systems and business applications in the deployment scope.
Document installation requirements, required restarts, a functional test, and the recovery route. Connect production work to the organization’s change management process, including approvals appropriate to the risk.
For an urgent exposure, use the emergency change process and document the reason for accelerated deployment. If a permanent fix is unavailable, record the temporary mitigation, assign responsibility for the remaining risk, and set a review date. NIST SP 800-40 Rev. 4 treats preparation, deployment, verification, and monitoring as connected maintenance activities.
Proof: A tested response identifies target devices, expected results, approval, and recovery arrangements.
Step 6: Deploy the fix to the intended devices
Apply the approved action to the selected scope. Review the target list against the baseline so similarly named devices or stale groups do not receive unintended changes.
AssetSonar supports patch deployment and scheduling against affected devices. Add the tested package to the relevant CVE, then select “Deploy Patch” or “Schedule Patch.” Choose the package and target devices; set the deployment time when scheduling.
For staged deployment, begin with the approved pilot subset and expand after reviewing its results. Record installation outcomes for every targeted endpoint, including pending execution, failed attempts, and required follow-up.
Keep failed devices assigned to their implementing owner. If compatibility problems require rollback, preserve the deployment history and return affected findings to the response plan. Recovery restores service, but the resulting exposure still needs an approved next action.
Proof: Every target has an execution result or an assigned follow-up action.
Step 7: Verify remediation using fresh endpoint evidence
Reassess the affected installation after the change has taken effect. Confirm any required restart, check the resulting version or configuration, and repeat the relevant vulnerability assessment.
Verify that the endpoint was reachable and that the assessment performed the required checks. A finding disappearing from an incomplete or unauthenticated assessment cannot establish remediation.
In AssetSonar’s patch workflow, “Success” includes successful agent execution and verification of the version or CVE closure. Review outcomes per affected device and investigate failed verification.
Retain the before-and-after evidence, assessment time, and reviewer or responsible administrator. For configuration changes, validate the condition described by the advisory and confirm the service still functions. For temporary mitigations, record the control’s tested effect while preserving its separate risk disposition.
Proof: Fresh assessment evidence supports every device-level closure.
Step 8: Report the result and schedule reassessment
Publish the cycle’s outcomes using the same defined population. Separate verified remediation, unresolved findings, approved mitigations, and devices that could not be assessed.
Show unique CVEs separately from affected-device instances. For example, label one CVE affecting 40 endpoints as 40 device-level findings.
Include overdue findings and explain changes in assessed-device counts. Use IT asset reporting to check whether fewer findings reflect fixes or missing endpoints.
Set the next review according to exposure, change frequency, and internal policy. Reassessment should also follow relevant new advisories and significant software changes. Route signs of exploitation into the incident response process rather than handling them solely as maintenance work.
Proof: A dated report identifies verified outcomes, remaining risks, and the next review.
Handle exceptions without losing the remaining risk
Some findings cannot follow the normal deployment path. Record the specific blocker and the authority responsible for deciding what happens next.
| Exception | Responsible role and next action | How the remaining risk is handled |
|---|---|---|
| No permanent fix is available | Security evaluates vendor-recommended mitigations; the service owner approves residual risk and a review date. | A permanent response is verified, or an authorized risk decision remains actively reviewed. |
| A device remains unreachable | Endpoint administrator arranges connectivity, recovery, or an investigation into its whereabouts. | The device is assessed, or its actual disposition is established. |
| A system is beyond vendor support | Service owner funds an upgrade, replacement, or isolation plan with a deadline. | The agreed action is completed and its security effect verified. |
| Approval misses the response deadline | Change owner escalates to the designated risk authority. | An approved action or explicit risk decision replaces the stalled request. |
Track unsupported systems through their replacement work. An exception changes how risk is handled; it does not establish a successful fix.
How software connects discovery with corrective work
Decide where records will be maintained across tools. Keep device identity, findings, tasks, and outcomes connected.
Test those connections with a representative finding. Check that its history remains available after device ownership changes.
AssetSonar’s Patch Management places vulnerability and patch activity alongside managed device records. Its overview provides vulnerability and deployment indicators, while alerts surface activity needing attention.
When exchanging records, preserve finding identifiers and source timestamps. Test how a later assessment reopens an issue without erasing earlier work.
Platform comparison for vulnerability management
Compare how each platform connects vulnerability intelligence with device records and corrective work. The options below differ in their data sources, deployment workflows, and verification methods.
| Product | Operational fit | How work is managed | How results are checked |
|---|---|---|---|
| AssetSonar | Managed endpoint remediation within ITAM | Agent-based patch actions | Device-linked deployment history |
| Lansweeper | Discovery-led vulnerability investigation | External remediation tooling | Post-change asset reassessment |
| Tenable One Vulnerability Management | Dedicated assessment and remediation coordination | Assigned remediation projects | Targeted follow-up scan results |
| Qualys VMDR with Patch Management | Prioritized findings connected to patch jobs | Additional patching module | Assessment and job records |
AssetSonar: Connect NVD findings with managed endpoints
AssetSonar suits IT teams managing remediation alongside device assignments, software installations, and lifecycle changes. Device context helps administrators distinguish active employee equipment from systems awaiting replacement.
Patch records remain associated with their CVEs and selected devices. Administrators can investigate affected installations, plan staged work, and review outcomes using the same endpoint context. This connects vulnerability assessment with the asset records IT teams already use for operational decisions.
Lansweeper: Enrich discovered assets with vulnerability intelligence
Lansweeper correlates discovered products with vulnerabilities using standardized product identifiers. VulnCheck supplies its primary intelligence, incorporating NIST information alongside other sources.
Administrators examine patch information or references, apply the response through the appropriate tool, and rescan the affected assets. That reassessment updates the CVE associations. Vulnerability Insights supports investigation and prioritization; patch execution takes place outside that feature. The workflow is available on Pro and Enterprise plans and suits IT teams retaining an established deployment platform.
Tenable One Vulnerability Management: Organize remediation projects
Tenable One Vulnerability Management lets administrators define remediation scope and assign project owners. Projects track fixed deadlines or ongoing response periods. It fits IT teams coordinating assessment findings across multiple implementing groups.
For eligible network-scan findings, a remediation scan rechecks selected targets and detection plugins. Configure the required credentials and ports before relying on its result. This targeted scan workflow supports specified network sensors; agent-origin findings require a different reassessment route.
Qualys VMDR: Move prioritized findings into patch jobs
Qualys VMDR provides a prioritization report linking affected assets, vulnerabilities, and available patches. With the separately enabled Patch Management add-on, administrators can start patching from that report.
In Qualys, “Patch Now” opens Patch Management, where administrators complete a new or existing job for the selected patches. Review deployment records alongside subsequent vulnerability assessments. This approach fits IT teams already operating within Qualys who want to connect assessment with patching.
Best practices for improving repeatability at scale
Once the core procedure works, improve the conditions that repeatedly create remediation work. Use recurring patterns to select changes with a lasting operational effect.
- Correct deployment images. Update source images or packages when vulnerable releases return on newly provisioned devices. Measure recurrence afterward.
- Preserve release detail during normalization. Use software normalization for consistent product naming while retaining the version evidence needed for vulnerability decisions.
- Measure delays at each stage. Track time awaiting assignment, approval, deployment, and verification separately. Approval delays and deployment delays require different corrective actions.
- Check vendor support before purchasing. Review update mechanisms and support periods before acquiring software or hardware. Assign responsibility for lifecycle changes.
- Test recovery arrangements periodically. Use controlled rehearsals to identify missing recovery permissions or dependencies. Correct those gaps before an urgent change.
- Review repeatedly accepted risks. Short exceptions can conceal a permanent support problem. Escalate that pattern into replacement planning or a longer-term decision.
Check the evidence before closing the cycle
Use the evidence below for an independent spot check. Ask someone outside the implementing group to trace a completed finding.
| Check | Retrievable evidence |
|---|---|
| Coverage is accounted for | Baseline and unassessed-device queue |
| The response was authorized | Linked approval or emergency decision |
| The outcome is reproducible | Successful post-change assessment |
| Remaining risk has accountability | Exception owner, decision, and review date |
| Results can be interpreted | Dated report with counting definitions |
Plan the next vulnerability remediation cycle
After the first pass through the vulnerability management lifecycle, compare new findings with verified closures. Separate recurring weaknesses from new exposures, and look for patterns in failed installations, delayed approvals, and unassessed devices. These patterns reveal whether the next cycle needs better device coverage, faster decisions, or additional deployment capacity.
Review these findings with security and service owners before expanding the scope. Reserve maintenance windows for high-priority endpoints and assign follow-up work for devices that missed earlier deployments. Revisit accepted risks according to their review dates. Use fresh assessment evidence to measure progress so improvements reflect resolved vulnerabilities rather than gaps in detection.
