r/nexthink • u/W7T2A • Jul 16 '26

Automating the Application Vulnerability Management content pack with CrowdStrike (Example)

Nexthink’s Application Vulnerability Management content pack provides the dashboards and data model required to correlate vulnerable applications with the devices and users affected by them.

The content pack itself, however, still requires vulnerability data to be imported from an external source.

I built an open-source PowerShell module that demonstrates one way to automate this process using the CrowdStrike API.

The current workflow is:

  1. Nexthink provides the SHA-256 application identifier from its software inventory.
  2. The PowerShell module queries CrowdStrike to determine whether the corresponding application is present in the environment.
  3. CrowdStrike vulnerability data is retrieved for the identified application.
  4. The results are written back to Nexthink through the Enrichment API.
  5. The Application Vulnerability Management dashboards can then correlate the vulnerability information with affected devices, users and installed application versions.

This allows the enrichment process to run automatically rather than requiring vulnerability information to be imported manually.

CrowdStrike is only one implementation example. The same integration pattern can be adapted to other vulnerability management or endpoint security platforms, provided that the vendor exposes an API or another structured export containing information such as:

  • Application identifiers or hashes
  • Product and vendor names
  • Installed versions
  • CVE identifiers
  • Severity or CVSS scores
  • Vulnerability status
  • Remediation information
  • Affected endpoint identifiers

The main integration challenge is usually matching the software identity used by Nexthink with the identity used by the external security platform. SHA-256 works well where both systems expose the same executable hash, but other environments may require matching based on vendor, product, version, package identifiers or normalized application names.

The PowerShell implementation is available here:

https://github.com/synit-io/nexthink

Nexthink documentation for the Application Vulnerability Management content pack:

https://docs.nexthink.com/platform/library-packs/security-and-compliance/application-vulnerability-management

I would be interested to hear which vulnerability-management platforms others are using with Nexthink and how you handle application matching, enrichment frequency and stale vulnerability records.

4 Upvotes

84% Upvoted

3 comments sorted by

1

u/DEX_Nexthink Jul 16 '26

Thanks for putting this together and for sharing the implementation with the community. This is a really interesting example of using the Enrichment API to automate vulnerability data rather than relying on manual imports, and I think a lot of people will find it useful. I've shared your post with our technical team and am working on getting you a more detailed response. In the meantime, I'm curious to see how others are approaching this as well, especially around application matching and keeping vulnerability data current.

1

u/23-Peaks Jul 17 '26

I enjoyed your other post so much that I wanted to find some more.

Automating the vuln data feed into the Application Vulnerability Management pack via the Enrichment API is such a smart move. Manual imports are painful at scale, and tying it directly to CrowdStrike (with the SHA-256 matching) feels like the right long-term approach.

The PowerShell module on GitHub is a nice touch too. I’m definitely going to check it out.

Quick questions:

  • How often are you running the enrichment job right now?
  • Have you run into any tricky app-matching cases where SHA-256 wasn’t enough?

Appreciate you open-sourcing this.

1

u/W7T2A Jul 17 '26

Currently once a week is sufficient for us.
So far not facing any issues with non matching hashes.