Understanding Vulnerability Response and Configuration Compliance for Containers

Eliz Skogquist · ‎02-27-2025

Continuing the "Success with VR" webinar series, this webinar highlights how Container Vulnerability Response and Configuration Compliance is configured, as well as how end users will remediate and have oversight on container vulnerabilities.

John Gibbons, Principal Product Success Architect, and I introduce a container's lifecycle, the support of vulnerability findings and how you configure the container vulnerability data to load the ServiceNow Vulnerability Response for Containers solution. The demonstration highlights set-up, end user interfaces and Security Leader's oversight of remediating container vulnerabilities across the enterprise.

Agenda:

Container Lifecycle
ServiceNow's Vulnerability Response and Configuration Compliance for Conainer
Configurations
Demo (including for the user personas)

The webinar recording can be viewed here:

Resource Links:

ServiceNow Documentation

Learning Bytes

Container Vulnerability Response: Prisma Cloud Compute Integration

Support

Q&A (Questions appended)

The Qualys integration wasn't mentioned in the slide deck. Was that an oversight or has there been a version compatibility issue lead to it being deprecated?	An oversight - Qualys Containver Vulnerability Response Integration is still very much available.
As a following up, for like OS / Gold Image vulns, would this module create ONE vuln per image, OR one vuln for each vuln found in each running container?	Container VR creates Container Vulnerable Items (CVIT). CVIT is a combination of a finding and a CI. Creation of CVIT's can be configured using the VI granularity feature. CVIT's can be split based on (Image name + CVE + (additional fields - like repo, repository, registry etc..)
CC part of cloud is feeding to same test result table unlike seperate CVR tables right ?	Correct, the misconfigurations for cloud loads the CC Test Results table. You would look for source to determine which are for cloud.
If so, what would be the "source" value for these?	The source here would be dependent on the scanner in question - e.g. Prisma, Wiz, etc. On those Test Results (similar to the Container Vulnerable Item / CVIT Source as well)
Is there any plans/current methods to ticket base image lag to assignment groups. Such as, your base image is N-2 from or 30 days behind the most recent base image version?	Currently this capability is not available. If the image versions are properly maintained, there can be an interesting solution for this. This is good feedback for us to review internally as an enhancement. Thank you
How does the platform determine image versions for the closure of older version VIs? Or is this just handled on the scanner side?	For now the CVIT's on the older versions have to be auto closed based on a recommended threshold of 90 days. Since the scanner does not come back with data to signal these older imported findings should be resolved
Host configuration issues for the hardware or the VMs running the orchestration environment?	Generally the VMs - as a reference we have the Host vulnerabilities import with Prisma today to gather the VM or Host layer detections
Is best practice to ingest vulns from images into SNOW or from runtime? How to you make sure the vulns inside the CVR module are only for container (images) that are deployed?	Good question. Today, we support both, gathering the vulnerabilities from the base images themselves - and additionally the vulnerabilities from runtime (on the deployed container images). Addressing vulnerabilities in both areas can be supported in Container VR today. I understand the concern of volume and noise, but the goal would be leveraging findings the scanner reports for running containers, where additional components may have been added onto the base image.
I request a lot of info for an exception submission via tasks, sure would be great to not have to repeat myself. if I had a questoinairre pop up with required info	You can do this, take a look at https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-respo...
For CI Matching, does the Plugins just create entries in the Docker CMDB table and Docker Container CMDB table? There is no concept of Unmatched CI tables like IVR ?	Cloud Resources is the primary table used during the CI Lookup Process, where we insert CIs into Cloud Resources when no matching CI is found
Do you have connectors for Rapid7 or is it on the Roadmap?	Rapid7 has the following available on the store: Rapid7 InsightCloudSec CC Integration Rapid7 InsightCloudSec VR Integration These are built by Rapid7.
is Crowdstrike container vuln/cc supported in this module?	Nope, we only support CrowdStrike Falcon Exposure Management for Vulnerability Response, not Container.
is CrowdStrike container vuln/cc supported?	Nope, we only support CrowdStrike Falcon Exposure Management for Vulnerability Response, not Container.
We were talking about cleaning tables earlier, how do we clean the discovered items table for unclassed hardware items that have now been discovered properly? its not possible to just delete, - i was wondering what the thoughts were for those Dicovered items?	Pls refer to this kb. https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1349923
For Images and the various versions, how are they discovered and tracked in CVR?	Similar to Discovered Items in Host VR, in Container VR we have Discovered Container Image, where we store these as records with respective metadata we get from the 3rd party scanner
Can you please explain how CVIT relates to the Container Findings Related Records, how is that connection i.e. is it that all Container Vulnerabilities for the same image with vulnerability rolled up to one CVIT ?	The aggregation of the Container Findings to CVIT, can be tailored and configured for the environment. Suggest checking out this Docs page for more insight https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerabi... By default, a vulnerable item is created for every unique combination of CVE and the Docker Image version (reference + tag). However, a few Docker Images may be deployed in more than one Kubernetes namespace and each namespace could be owned by different business units or teams. Each team may follow their own cadence for rolling out new versions of container images to fix vulnerabilities. To accommodate this scenario, Container Vulnerability Response enables you to define granularity for vulnerable items: Whether one vulnerable item should be created for each Kubernetes namespace/cluster/service even for every unique combination of Docker Image version and vulnerability.
I notice that there are many Image Findings on a single CVIT. Is this by design, and what is the benefit for having it this way vs 1 CVIT with 1 Image Finding?	The granularity here is configurable. Suggest reviewing this Docs Page https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerabi... By default, a vulnerable item is created for every unique combination of CVE and the Docker Image version (reference + tag). However, a few Docker Images may be deployed in more than one Kubernetes namespace and each namespace could be owned by different business units or teams. Each team may follow their own cadence for rolling out new versions of container images to fix vulnerabilities. To accommodate this scenario, Container Vulnerability Response enables you to define granularity for vulnerable items: Whether one vulnerable item should be created for each Kubernetes namespace/cluster/service even for every unique combination of Docker Image version and vulnerability.
Does the questionaire apply to the VIT module too?	Yes, the Questionaire capability is available for all VR applications, IVR, AVR, CVR and CC
Are the workspaces configured based on roles (OOTB) or we need to configure anything in specific?	The workspaces are already configured, assign roles for viewing https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-respo...
Regarding containers, do you have the ability to separate / identify which vulns come from a Gold Image vs Application code?	There is a field that illustrates whether a finding is associated to a base image. This can be used as a signal for what risks are on the gold/base image versus a deployed container (runtime)
Are remediation targets and risk calculators the SAME for VR - or just look the same but are maintained separate?	They look the same, but are maintained differently for the CVIT (Container Vuln Items) table. The rules are managed separately from Host VR, App VR, etc.
Can you explain more about this module being different and creating CIs in the CMDB?	Today, the CIs would be created in the Cloud Resource table if no matching CI is found. The Docker Images are in the Docker Image table, and Image Repositories in the Container Repository table.
Do you have any other container integration partners in the pipeline?	We do have an integration with Tenable Cloud coming up soon.
what about Anchore Container Securitry scanner, its supported	We don’t currently offer integration with Anchore
Are there best practice guides for assignment rules? As an example, using Discovered Container Image.Image Label for assignment rules?	We don’t have container-specific best practices documented, but Image Label is definitely one of the fields we saw as our first use case for assignment. You can find general vulnerability assignment rule resources here: https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-respo...
do you have plans to have an integration between AWS Inspector and container VR?	We have started discussions with AWS for Security Hub integration. More to come on this later in the year but no target date at the moment
IS cloud native operations needed for the VIT records to have a CI and ownership?	Where we have data to consume in CMDB (e.g. via ITOM Cloud Discovery) we would be in a position to leverage that data if it aligns with how we assign remediation work. That said, there are configurations we have in Container VR to address for tailored situations (e.g. Assignment Rules) - which can be driven by the data we get from the 3rd party scanner and our insights into our organization/processes - e.g. who addresses risks at different layers for certain flavors of vulnerabilities
Can exceptions rules be created by vulnerabilities? Example dev teams would want to create an exception for CVE-2025-1234. Is this possible?	Yes - here is a reference to this on Docs https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerabi...
Is there a Qualys CVR connector?	Yes - there is a Store App for Qualys Cloud Vulnerability Response.. https://store.servicenow.com/sn_appstore_store.do#!/store/application/393122561b960210950a10e58d4bcb...
Where can we download the documentation for container?	You can download a pdf of all the CVR documentation from docs at this location: https://www.servicenow.com/docs/bundle/xanadu-security-management/page/product/secops-integration-vr...
Is there anything in the solution that would help to not only track the remediation of the image vulnerabilities, but ensuring that running containers/workloads actually pull the updated image (particularly in the base-layer vuln situation)? Or would the only OOB option be utilizing Change Management etc to track that effort?	For now, tracking the change reqest is the suggested workflow. Track deployment via the change request, ensure the updated image is deployed, a rescan is triggered to confirm updated image is deployed to production.
Do you have suggestions for customers with multiple container scanning sources? i.e. custom and store integration	Integrations to load the scanner findings will go into the same tables, and be differentiated by source.
Can you get CVIT ownership from tagging if you are creating the CI yourself?	Prisma can detect the CVE in an image and provide tags as metadata. If manual creation of CI is refering to the IRE method of creating the CI, tags can be mapped to the CI fields, and then create business rules to auto assign ownership
If the CVIT is for an image, but the container self-installs new software post-deployment, will that new runtime vulnerability be found?	It depends on the capability of the sacnners. If the scanner can scan these self installed applications, detect CVE's, push them to SN via the API, these CVE's are considered just like any other vulnerabiltiies and corresponding CVIT's and workflows can be executed.
Which field in the Discovered Container Image, please what field keeps track of the Image Versions, so we know how they are tracked ?	Image versions are not supported out of the box, however if tags are properly maintained on the cloud resource or the docker image,
Are there any discussions to bundle findings from the context of base images, so that application developers are not engaged in remediating packages that have been introduced by the base image, and all they need to do is update the version of the base being used?	There is a Prisma Base Image integration that creates CVITs for base images, allowing them to be assigned to the central admin team responsible for them. However, the container integration also flags these vulnerabilities because, even if the base image has been fixed, the application developer may still need to rebuild their image using the updated base image.
Is there a known issue with duplicate CVITs? All items in the CVIT are identical and there is no difference except the CVIT number?	Not aware of any such issue. Please log a support case for the support team to review this issue.
What is the risk score changes in notes job mentioned?	Starting with version 2.10 of Container Vulnerability response, when the risk score on a CVIT changes, the following details document in worknotes: Calculator group name, Calculator name, Filed values that have a weightage greater than 1 and their risk score contribution, final risk score. For Vulnerability Severity risk rule, the following details document in worknotes: calculator group name, calculator name. Starting with v2.12.2 of CVR the system property sn_sec_cmn.risk_score_changes_add_worknotes is inactive by default. See details at: https://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerabi...
Is there a future capability being addressed to simplify the different VR roles?	Not in the roadmap as of yet.
Clarification: managing the different roles for VR can get messy, is there a way to manage the roles and who they are granted to in a 'single' pane. something that can be accessed by a vuln admin without having to have full blown admin access.	Not in the roadmap as of yet.
Are you demoing something around image SBOM? If so would Acqua scans be integrated into that functionality for CC and CVR?	No this demo is limited to Container VR
Does the twistlock integration aka prisma cloud compute produce both CTRs in the sn_vulc_result table as well as CVITs in the container result table?	Prisma Cloud Compute integration loads CVIT table , with the Prisma Host API integration loading IVR. Prisma Cloud integration loads test results into CC test results table. You can differentiate cloud misconfigurations by looking at the source field on the test result record.