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

[klausschmid]

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

[andy_ojha]

Great dialogue here everyone.

One concept I have not seen mentioned (though similar thoughts shared), is around Classification Rules in VR.  In fact, Classification Rules were introduced to be used as one of the tools for this use-case.

Whether you intend to use CPE strings or simply the Vulnerability Summary - the idea is to classify each Vulnerability, so that you can drive bits like Assignment Rules, Reporting, etc ..  based on your tailored needs.

A common starting point, is to classify the Vulnerability itself (CVE, Tenable Plugin, Qualys QID, etc) -> as either Platform or Application ... Platform being OS related and Application being anything else above that (Java, Web Browser, etc).   This is just one approach but it is flexible and you can define your own.

Once we distinguish the Vulnerability being Platform vs App, you can break that out further with Classification Type.

For example -> each Vuln Entry record could have it's Classification and Classification Type set based on rules we define.  

Then Assignment Rules, Reporting, List queries, etc -> can leverage this, as we can dot-walk from Vulnerable Items to Vuln Entry to the Classification Values.   

Condition	Classification	Classification Type
Vuln.Summary > CONTAINS > Windows Server (or x, or, x)	Platform	Windows Server
Vuln.Summary > CONTAINS > Windows 7, (or x, or x)	Platform	Windows Workstation
Oracle Java, Java (or x, or x)	Application	Java

We can use the output of this in Assignment Rules

• Assign VITs where the Vuln Entry > Classification is Platform & Type is Windows Server > to the CI.Support Group
• Assign VITs where the Vuln Entry > Classification is Application & Type is Java > to App Team 123
• etc

You can also use this for general list queries, reports .. and other bits like Watch Topics, Risk Scoring Calculator inputs, etc.

-----------------------------------------------------------------------------------------------------------------

  @John Gibbons has a good video walk-through with additional examples

This Community Article has additional visuals and examples as well

https://www.servicenow.com/community/secops-articles/secops-resource-library-performance/ta-p/312331...

-> See Section 3) Data Normalization for Improved Performance

https://www.servicenow.com/docs/r/security-management/vulnerability-response/create-classification-r...

[abdulrehmanArif]

Hi Andy,

Thanks for adding this. This is a very helpful clarification, and I agree this is probably the cleaner design pattern for this use case.

My earlier thought was focused directly on Assignment Rules and Remediation Task Rules, but using Classification Rules first makes the model more maintainable.

A better approach would be:

1. Use Classification Rules to classify the Vulnerability / Third-Party Entry first

For example:

• Platform / Windows Server

• Platform / Windows Workstation

• Application / Java

• Application / Adobe

• Application / Browser

• Application / Middleware

The classification logic can use the most reliable available data, such as vulnerability summary, product/publisher details, CPE where available, scanner/plugin data, or other normalized vulnerability fields.

1. Use the classification output in Assignment Rules

Once the vulnerability is classified, Assignment Rules can use that value through dot-walking from the Vulnerable Item to the Vulnerability / Third-Party Entry.

For example:

• Vulnerability Classification = Platform and Type = Windows Server → Central patching / OS team

• Vulnerability Classification = Application and Type = Java → Application support team or CI support group

• Unclassified / fallback → triage or CI support group

1. Use Remediation Task Rules for grouping

For OS/platform vulnerabilities, the Remediation Task Rule can group centrally by vulnerability and assignment group, instead of grouping by individual CI.

For application vulnerabilities, the task rule can keep grouping closer to the responsible owner, such as assignment group, CI support group, vulnerability, product, or application context.

So I would refine the recommendation as:

Classification Rules should be used first to normalize whether a vulnerability is Platform or Application. Then Assignment Rules should use that classification to route ownership, and Remediation Task Rules should control how the actual remediation work is grouped.

This avoids relying only on CPE or long repeated keyword conditions inside every Assignment Rule. CPE can still help, but the classification output becomes the reusable control point for routing, reporting, watch topics, and remediation design.

Thanks again — this makes the design much cleaner.

Abdul Rehman Arif
XAAS Solutions LLC

[klausschmid]

thanks to everyone for these valuable responses!

Does anybody of you leverage the "Part" Attribute in the "Vulnerable Software" 

What I see is that when NVD delivers the CPE info with the Vulnerability, it assigns the Vulnerable Software which is classified. Unfortunately, as already mentioned, NVD seems to be not up to date. 

I also see that MSRC includes the vulnerable software, but does not use CPE code but defined Titles (which somehow matches with the Display Name in Vulnerable Software). 

e.g.

https://msrc.microsoft.com/csaf/advisories/2026/msrc_cve-2026-42993.json

IF at import of MSRC records they'd be matched to vulnerable Software (I don't now the algorithm, but it seems that it only matches based on CPE), we'd have a relation to the "Parts" Attribute in "Vulnerable Software" and could use that as Routing Information within Classification Rules. 

What I would be really happy is that we don't need to manage a defined list of software manually which matches the description. But with your way @Dave Winsor to use a custom table for that, it would at least be manageble.

What are your thoughts on this?