# Usage guide: Application vulnerability management {% hint style="warning" %} This page outlines various ways to use the pack, including use case examples. Administrators can refer to the [Configuration guide: Application vulnerability management ](https://docs.nexthink.com/platform/library-packs/security-and-compliance/application-vulnerability-management/configuration-guide-application-vulnerability-management)to set up and customize the installed content. {% endhint %} 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 {% hint style="info" %} Jump to [Use cases](#use-cases) on this page to see relevant scenario applications. {% endhint %} 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. {% hint style="warning" %} This pack does not cover the removal of vulnerable applications, which should be performed using configuration management tools or custom remote actions. {% endhint %} *** RELATED TOPICS * [Live Dashboards](https://docs.nexthink.com/platform/user-guide/live-dashboards) * [Managing campaigns](https://docs.nexthink.com/platform/user-guide/campaigns/managing-campaigns/managing-campaigns) * [Overview: Application vulnerability management](https://docs.nexthink.com/platform/library-packs/security-and-compliance/application-vulnerability-management) * [Configuration guide: Application vulnerability management](https://docs.nexthink.com/platform/library-packs/security-and-compliance/application-vulnerability-management/configuration-guide-application-vulnerability-management)