Unpacking Common Questions on Application Vulnerability Response (AVR) and CMDB

andy_ojha
ServiceNow Employee
ServiceNow Employee

on ‎05-01-2025 04:40 AM - edited yesterday

Hey SecOps Community,

 

🤔 Have you been curious about Application Vulnerability Response, and where CMDB fits into the picture?

 

⚡ Are you interested in SBOM Response, and wondering about connections to Configuration Items in CMDB?


👀  Heard about CSDM and Application Vulnerability Response have a relationship, and want to learn more?

 

This Article aimed to help you get started and hopefully answer some of the initial questions that come to mind.

Please drop your questions/comments below.

Is Having a Populated CMDB a Requirement for Application VR?

 

Specifically, for Application VR with an integration to a scanner and for Application VR with SBOM - the essence of CMDB dependency aligns with what we traditionally see with Host/Infrastructure VR

  • Not having a populated CMDB, is not necessarily a blocker 

  • We can consume (best effort) from specific CMDB tables - and where data does not exist, we have tools and configurations to accommodate for that 

Where Does CSDM Come Into Play with Application VR?

 

  • CSDM (Common Service Data Model), was released several years ago as a framework for managing data in CMDB

  • Prior to CSDM, customers may have been using the Application Class (cmdb_ci_appl) table to manage applications 

  • CSDM (Crawl Phase), promotes a migration from Application to Business Application / Application Service 

ServiceNow Enterprise Architecture (Formerly Application Portfolio Management aka APM) - helps this process of managing and classifying Applications within the Enterprise in the ServiceNow CMDB.

This is a notable difference between Host/Infrastructure VR and Application VR - where we may have to consider where Customers are managing their applications in ServiceNow, based on their alignment to CSDM or their CSDM journey.

The good news is, with the CI Lookup Rules we have in SecOps, when we import data from a 3rd party scanner we can configure and tailor CI Lookup rules to accomdate for the scenario at hand (using legacy tables for Applications versus using modern CSDM tables for Applications).

 

Just like in Host/Infrastructure VR, within Application VR when a Scanner is used (e.g. Veracode), we have CI Lookup Rules that can be configured and tailored to match to a target record to consume from in ServiceNow, automatically as data is ingested and processed.

  • If we cannot find a matching CI or record in ServiceNow, we create a new entry to track that asset against 

  • Where this record is created, depends on a decision and critical configuration around CSDM (Common Service Data Model)

  • Application VR can be configured in one of two ways 

    • 1) Leverage Product Model (CSDM)

    • 2) Do not leverage Product Model (CSDM), and instead use local VR Scanned Application 

  • This process is automatic and driven by the configurations that are setup

Help Me Understand Where We Consume Data from in Application VR with a Scanner Integration

 

Let’s first start with Application VR with a 3rd party scanner (VeraCode, GitHub, BlackDuck, etc).

 

The process to lookup a target Application or Record in ServiceNow, is automated here through CI Lookup Rules that are configured.

 

AVR Scanner - Option 1, Use Product Model

    • Here we align with CSDM 
    • We try to match to an existing entry in ServiceNow Product Models using CI Lookup Rules
    • If a version is provided by the scanner -> lookup against Software Model
    • If no version provided by scanner -> lookup against Application Model  

AVR Scanner - Option 2, Use Scanned Application 

    • Here we use the old method of not aligning to CSDM 
    • We try to match to an entry in the App VR Scanned Application table 
    • This table houses CIs created by a ServiceNow App VR Scanner (when we do not find a matching CI)
    • This might be useful if we imported Applications from an App VR Scanner, in an older version before the AVR + Product Model (CSDM) feature came out

AVR Scanner - Option 3, Scripted Rule 

    • Here we can configure our lookup rules to match to a record on a table that we specify 

    • This can be useful if we have a custom table to track applications or might be using older legacy tables to track applications (e.g. CMDB_CI_APPL)

Note: A record is automatically created in the AVR "Discovered Applications" table, and will contain a reference to the matched record in ServiceNow, the matching rule and other metadata from the App VR Scanner.

What Happens When No Matching CI Is Found w/ Application VR + Scanner Integration?

 

This is going to depend on whether we have configured Application VR to be compatible with CSDM or not.

 

Path 1 - AVR Enabled to use Product Model 

  • When no matching CI is found for an Application with the CI Lookup Rules 

  • If the Scanner provides the Application AND Version, a new CI is created in the "Software Model" table 

  • If the Scanner does not provide Version, a new CI is created in the "Application Model" table  

Path 2 - AVR Configured to Not Use Product Model 

  • When no matching CI is found, a new entry is created in the “Scanned Application” table 

Reference:
Note: A record is automatically created in the AVR "Discovered Applications" table, and will contain a reference to the CI that was created by the AVR scanner, and other metadata from the AVR scanner.

What about SBOM, where does CMDB fit in with SBOM and Application VR?

 

There are currently two primary paths to upload SBOM files into ServiceNow

  • Manually through the User Interface in the SBOM Workspace 

  • Through the ServiceNow API

Today, SBOM file uploads do not use the SecOps CI Lookup Rules to correlate/map to a CI in the CMDB.

When you manually upload an SBOM file through the User Interface, the User can at that point, can optionally​ pick the target records in ServiceNow for CI Mappings:

  • Business Application

  • Product Model 

By manually associating the SBOM File to a Business Application and/or Product Model - when the BOM Entity is created (or updated) in ServiceNow, the corresponding Business Application or Product Model will then be set on that BOM Entity record in ServiceNow.

 

Alternatively, SBOMs can be uploaded to ServiceNow via API.  

  • In this manner, when SBOM files are uploaded to ServiceNow via API, the ServiceNow [sys_id] of the Business Application or Product Model can also be supplied 

  • This way (like manually uploading the SBOM) - the target BOM Entity in ServiceNow can be associated to the Business Application or Product Model

Reference: 

What Else Should we be Aware of or Plan for?

Let’s consider a few paths:

  • We matched to an Application CI in ServiceNow, but it does not have the data we need to route Remediation activities 

  • We do not match to an Application CI in ServiceNow, but we want to automatically route tasks and Remediation activities to the right Teams 

 

Within Application Vulnerability Response, Assignment Rules are configured to determine how to route vulnerability findings to the appropriate Teams for Remediation.

  • These rules can be structured in a few ways to meet your needs 

  • Dynamic Rules: Consume data from ServiceNow, to dynamically determine which Team should be assigned the vulnerability findings 

  • Static Rules: We may have to define our own conditions and scenarios to explicitly define the Team the work should be assigned to, still data driven but what we configure for the rule conditions, but the target Team we use is manually coded into the rule 

    • This is useful, when we do not have the data we need in ServiceNow, so that we can automatically assign the Remediation activities to the appropriate Teams based on the data we have from the Vulnerability at hand, the Application (or any other data point from the scanner at hand), and possibly from the target Application CMDB CI record 

This is all great - but tell me what I need in ServiceNow CMDB to make Application VR or SBOM work

There is no hard dependency for a fully hydrated and populated CMDB to make Application VR, SBOM or VR operational.

That said, when we are implementing VR, we are primary consumers of the data in CMDB and would tailor our configurations (CI Lookup Rules, Assignment Rules, Risk Scoring Calculators, etc.) based on the data we have.

So, if we do not have a great deal of data in ServiceNow CMDB, we primarily would leverage data from the Vulnerability integrations (e.g. Web App Scanner, NVD, CISA KEV, etc.) to drive prioritization, and then the Assignment Rules we setup to route work, to the right Remediation Teams.

If we do have some of the key data in ServiceNow, perhaps derived from Discovery, Enterprise Architecture (formerly Application Portfolio Management), or Service Mapping - this may offer more data for us to consume in many cases - but this is not a requirement.

Summary - Where do we reference data within Application VR and SBOM Response

  

App VR Area

(CMDB) Application Reference

(CMDB) Application + Version Reference

(SecOps) Tracking Method

SBOM

Business Application (cmdb_ci_business_app)

Product Model
(cmdb_model)

SBOM Component (sn_sbom_component)

AVR Scanning Integration

Application Model (cmdb_application_product_model)

Software Model
(cmdb_software_product_model)

Discovered Applications (sn_vul_app_release)
  • 1,131 Views
Comments
mn-snyk-sn
Tera Contributor
‎05-01-2025 01:20 PM

Thanks Andy! In terms of using either the Software Model or the Application Model, I don't see the "Managed by Group" designations within either of these models. For our existing Vuln. Assignment rules, we assign to the managed by group. Is that an inheritable field from Business Apps?

0 Helpfuls
Version history
Last update:
yesterday
Updated by:
ServiceNow Employee
Contributors