Understanding Vulnerability Response and Configuration Compliance for Containers

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 (additional Q&A will be posted next week)

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 playtform 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-response/concept/vr-exception-management.html
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 IntegrationRapid7 InsightCloudSec VR IntegrationThese 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%5Farticle%5Fview&sysparm%5Farticle=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 insighthttps://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerability-response/reference/cvr-landing.htmlBy 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 Pagehttps://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerability-response/reference/cvr-landing.htmlBy 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 viewinghttps://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/vulnerability-response/concept/vr-wkspace-overview-v16.html
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-response/concept/vr-assignment-rules.html
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 Docshttps://www.servicenow.com/docs/bundle/yokohama-security-management/page/product/container-vulnerability-response/concept/working-with-exception-rule-cvr.html
Is there a Qualys CVR connector?	Yes - there is a Store App for Qualys Cloud Vulnerability Response..https://store.servicenow.com/sn%5Fappstore%5Fstore.do#!/store/application/393122561b960210950a10e58d4bcb97/1.0.1?referer=%2Fstore%2Fsearch%3Flistingtype%3Dallintegrations%25253Bancillary%5Fapp%25253Bcertified%5Fapps%25253Bcontent%25253Bindustry%5Fsolution%25253Boem%25253Butility%25253Btemplate%25253Bgenerative%5Fai%25253Bsnow%5Fsolution%26q%3Dqualys&sl=sh
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/prisma/concept/exploring-cvr.html