Usage guide: Application vulnerability management
This page outlines various ways to use the pack, including use case examples.
Administrators can refer to the Configuration guide: Application vulnerability management to set up and customize the installed content.
This library pack helps IT and security teams:
Gain clear visibility into vulnerable binaries and where they are being used.
Standardize vulnerability tagging for consistent remediation.
Target devices that actually executed vulnerable binaries, improving efficiency.
Use workflows and campaigns to drive user engagement during vulnerable application removal.
Library pack uses
Jump to Use cases on this page to see relevant scenario applications.
Use the library pack content for the following purposes.
Gaining visibility into vulnerable application usage
With the help of the Application vulnerability management dashboard, and after manually tagging vulnerable products, you can see all endpoints executing vulnerable binaries. The dashboard provides an overview of the number of vulnerable products and devices running them, as well as breakdowns by location, organizational department and more. This information enables you to quickly assess the impact of the vulnerability.
Engaging with users to confirm the removal of vulnerable applications
With the Vulnerable application removal assessment workflow and its associated campaigns, users can be informed of vulnerable products on their devices, alternative or updated products can be suggested where available, and permission to remove the vulnerable products can be requested.
Use cases
In addition to the relevant use cases covered below, you may uncover other troubleshooting scenarios specific to your environment.
Tagging vulnerable applications
In the Application vulnerability management dashboard, on the Overview tab, apply filters to Product name and Versions to indicate the vulnerable product.
Next, check the Vulnerability catalog widget, which displays the product name, the devices running the product, the associated binaries and the versions. From the action menu, select Drill down to binaries.
In the drill-down results, select the vulnerable binaries and click Edit.
Finally, enter the values for the custom fields based on your case.
Vulnerable: This manual custom field indicates whether a specific binary version is considered vulnerable. It should be populated with a Yes value if your vulnerability detection report indicates this.
Vulnerability severity: This manual custom field indicates the severity level of a vulnerability affecting a specific binary version. It should be populated based on information from your vulnerability detection report and can contain one of the following text values: Low, Mid or High.
Vulnerability exploitability: This manual custom field indicates whether the vulnerability affecting a specific binary version is known to be exploitable. It should be populated with Yes or No based on information from your vulnerability detection report. If exploitability is unknown or not specified, the field may remain empty.
Replacement application: This manual custom field is used to indicate whether a replacement application is available for a vulnerable application. The replacement application name should be entered here. If no replacement is available, the field should be left empty.
Replacement application link: This manual custom field may contain a link to an alternative application available on your organization’s internal self-service portal. It is used when a vulnerable application should be replaced rather than updated. The link should be entered without the
https://prefix.Safe version: This manual custom field indicates the version of the application that is considered safe and not affected by the vulnerability. It should contain the version number as text based on your vulnerability detection report. If no safe version is available or specified, the field may remain empty.
Safe version link: This manual custom field may contain a link to the safe version of the application available on your organization’s internal self-service portal. It should be populated when a vulnerable application can be upgraded. The link should be entered without the https:// prefix.
Identifying vulnerable applications
This use case helps security and IT teams identify, prioritize, and assess vulnerable applications in the environment using vulnerability data enriched with Nexthink’s real-time device and usage insights.
Assess overall risk exposure
Start with the Overview tab to quickly understand the current risk level.
This tab highlights:
The number of high-risk applications (severity Mid/High and exploitable)
The number and ratio of devices affected
The trend of exposure over time
It also shows which applications drive the most risk based on device impact and execution activity.
Use this view to determine:
Whether vulnerable applications represent a significant risk
Which applications should be prioritized for investigation
Investigate high-risk applications
Move to the Vulnerability Details tab to analyze the most critical applications.
Focus on the high-risk section to identify applications that are:
Widely deployed across devices
Actively used (high execution activity)
Exposed for long periods of time
These are the applications that should be addressed first.
Understand remediation scope
In the same tab, review all vulnerable applications to understand the full scope of exposure.
This section shows:
How many applications can be upgraded, replaced, or removed
The number of affected devices per application
Use this to:
Estimate the effort required for remediation
Decide on the appropriate remediation strategy
Identifying impacted devices
This use case helps identify devices running vulnerable applications and quickly generate a list of them.
Select the scope
Start from either the Overview or Vulnerability details tab, depending on your objective:
Use the Overview tab to identify devices running high-risk applications
Use the Vulnerability details tab to focus on specific vulnerable applications (high-risk or general)
This allows you to define whether you want a broad high-risk view or a targeted application-level investigation.
Drill down to devices
From the selected widget (for example, Devices running high-risk products), use the Drill down to Devices option.
This opens a list of devices impacted by the selected scope, allowing you to see exactly where vulnerable applications are present.
Use the device list for action
The resulting device list can be used to:
Identify affected users and endpoints
Export data for reporting or further analysis
Create targeted remediation actions, such as:
Configuration management collections
Remote actions.
Engaging with users to confirm the removal of vulnerable products
This use case helps IT and security teams engage end users to confirm remediation actions for vulnerable applications and collect feedback to drive follow-up actions.
Automatically detect vulnerable applications
A scheduled workflow continuously identifies devices running vulnerable applications based on the defined vulnerability tagging fields.
Depending on the available remediation information, the workflow automatically triggers one of the following user campaigns:
Remove the vulnerable application
Replace it with an approved alternative from the self-service portal
Upgrade it to a safe version from the self-service portal
Collect user responses
Users are prompted to confirm their intended action directly through the campaign. They can:
Confirm remediation (remove, replace, or update)
Indicate that remediation is not confirmed
Request IT support
If support is requested, the workflow can automatically create an ITSM ticket and notify the user.
Review responses and plan actions
All responses are aggregated in the Remediation progress tab, where teams can view:
Response rates per campaign type
User-selected actions per application
This allows teams to:
Identify devices where remediation is confirmed and proceed with automated actions (e.g., remote uninstall or update)
Detect cases where remediation is not confirmed and plan follow-up or escalation
Prioritize support requests and handle them through ITSM workflows
Assessing user response
This use case helps IT and security teams monitor and evaluate user responses to remediation actions for vulnerable applications, enabling more effective follow-up and remediation planning.
Review remediation engagement
Start with the 'Remediation progress' tab to understand how users are responding to remediation requests triggered by automated workflows.
When vulnerable applications are detected, users are presented with a campaign asking them to update, replace, or remove the application, or request support.
The Remediation summary provides an overview of:
The total number of responses
The response rate per campaign type
Use this to assess overall user engagement and identify areas where additional communication may be needed.
Analyze user responses
Review the User-selected remediation actions section to understand how users responded.
Responses are categorized as:
Remediation confirmed – users indicated they will take action
Remediation not confirmed – users did not commit to remediation
Support requested – users require assistance from IT
This helps teams identify:
Which devices are ready for remediation actions
Which users may require follow-up or escalation
Where IT support involvement is needed
Plan remediation actions
Use the response data to define next steps:
Remediation confirmed: use the Drill Down to Devices option to generate a list of affected devices, create configuration management collections, and trigger remote actions to complete remediation.
Remediation not confirmed: plan additional communication or escalation
Support requested: review the generated IT support tickets and plan support activities accordingly.
This pack does not cover the removal of vulnerable applications, which should be performed using configuration management tools or custom remote actions.
RELATED TOPICS
Last updated
Was this helpful?