Best practice for routing OS vs. application vulnerabilities in ServiceNow VR (Defender + NVD / CVE

klausschmid
Tera Contributor

Thursday

Hi community,

we are currently implementing ServiceNow #Vulnerability Response and would like to get your input on a routing / assignment challenge.

 

Our setup

  • Vulnerabilities are detected via Microsoft Defender and imported into VR
  • Additional enrichment sources: NVD, MSRC, CISA, EPSS
  • Vulnerabilities are mapped to Server CIs via CMDB

 

Organizational model

  • OS layer (e.g. Windows OS, RDP client, system DLLs, etc.)
    → handled by a central patch management team (via Microsoft Update)
  • Middleware / runtime / application layer
    → handled by dedicated support teams per CI

 

The challenge

When large numbers of vulnerabilities are imported:

  • We want to route OS-related vulnerabilities centrally
    → ideally grouped into one remediation task (not per CI)

  • While application-related vulnerabilities should still be
    → assigned to the responsible support group of each affected CI

Initial idea

We considered using CPE information to distinguish:

  • OS vs. application layer (based on vendor/product classification)

👉 However, with NVD as primary data source, we see:

  • missing or incomplete CPE data
  • delayed enrichment availability

At the same time, it looks like CVE.org (CVE JSON / GitHub) provides:

  • more complete / faster metadata (in some cases)

Example (CVE-2026-42993):
https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/42xxx/CVE-2026-42993.json

 

Our questions

  1. How do you differentiate OS vs. application layer vulnerabilities in VR for routing/assignment?
  2. Are you using CPE as reliable indicator, or something else (e.g. CI class, software model, publisher)?
  3. Has anyone:
    • integrated CVE.org (cvelistV5) directly
    • or used CSAF / alternative enrichment sources for better classification?
  4. Any best practices on:
    • remediation task rules to centrally group OS patching
    • while keeping application-level tasks CI-specific?

What we aim for

  • Clean separation of responsibilities
  • Avoid thousands of CI-specific tasks for OS patching
  • Still keep precise ownership for application vulnerabilities

 

 

0 Helpfuls
  • 129 Views
1 REPLY 1

abdulrehmanArif
Giga Expert

yesterday

Hi Klaus,

Good question. I would handle this by separating the routing logic from the grouping logic.

ServiceNow does not provide one single documented OS-vs-application routing blueprint, but the supported pattern is to implement this separation using Vulnerability Assignment Rules and Remediation Task Rules, backed by CMDB, software, and Microsoft Defender / TVM context.

For OS-level vulnerabilities, I would create higher-priority Vulnerability Assignment Rules that identify the OS patching scope and assign those Vulnerable Items to the central patch management group.

Examples could include conditions based on:

  • CI operating system / platform

  • CI class

  • software product or publisher

  • vulnerability product information

  • Microsoft Defender / TVM machine tags

  • patch or solution information, where available

The important point is that OS-level vulnerabilities should match these rules before the generic CI Support Group rule. Assignment Rules are order-based, so the more specific OS patching rule should run before the fallback owner-based rule.

Then I would create a matching Remediation Task Rule for those OS vulnerabilities. In that rule, avoid grouping by individual CI if the goal is to prevent thousands of CI-specific tasks. Instead, group by fields that make sense for the patch team, such as vulnerability, solution, assignment group, severity, or patch window logic.

For application, middleware, runtime, and product-specific vulnerabilities, I would keep the ownership closer to the application or service owner. In that case, the Assignment Rule can use the CI support group, CI assignment group, business application, application service, product model, software model, or other CMDB/CSDM ownership data.

So the model would look like this:

OS vulnerabilities:

  • Assignment Rule sends them to the central patch management group

  • Remediation Task Rule groups them centrally by vulnerability, solution, severity, or assignment group

  • Avoid grouping by CI if the patch team wants centralized patching tasks

Application / middleware vulnerabilities:

  • Assignment Rule sends them to the CI support group, application owner, or service owner

  • Remediation Task Rule groups by owner plus vulnerability, product, or application context

  • This keeps remediation with the team that actually owns the affected application or runtime

I would be careful about using CPE as the only decision point. CPE is useful enrichment, especially with NVD/software data, but in practice it may not always be complete, timely, or detailed enough to drive operational ownership by itself. I would treat CPE as supporting evidence, not the only routing control.

For Microsoft Defender / TVM specifically, machine tags can be useful because ServiceNow imports them and they can be used in Assignment Rule and Remediation Task Rule filters. If your Defender assets are already tagged by ownership, environment, platform, or patching group, those tags can help make the routing more reliable.

I would also avoid building a custom CVE.org / cvelistV5 integration unless there is a clear data gap that is not covered by ServiceNow-supported sources. ServiceNow already supports several enrichment and remediation intelligence paths, including NVD/CWE, CISA KEV, EPSS, MSRC Solution Integration, Vulnerability Solution Management, and CSAF import. I would start with those first.

So my recommendation would be:

Use Vulnerability Assignment Rules to decide who owns the Vulnerable Item, and use Remediation Task Rules to decide how the work is grouped. Use CMDB/software/Defender context to separate OS patching from application ownership. Do not rely on CPE alone as the routing mechanism.


Regards,
Abdul Rehman Arif
XAAS Solutions LLC