The ServiceNow® Container Vulnerability Response application imports container vulnerable items (CVITs) and according to the rules enables you to remediate container vulnerabilities. Vulnerability data is pulled from internal and external sources, such as the National Vulnerability Database (NVD) or third-party integrations.

Starting with version 18.0 of Vulnerability Response, you can monitor and remediate CVITs in Vulnerability Manager Workspace and IT Remediation Workspace respectively. For more information, see Vulnerability Manager Workspace and Exploring the IT Remediation Workspace.

Request apps on the Store

Visit the ServiceNow Store website to view all the available apps and for information about submitting requests to the store. For cumulative release notes information for all released apps, see the ServiceNow Store version history release notes.

Benefits

The Container Vulnerability Response application provides the following benefits:
  • Integrates with third-party container security products, like Prisma Cloud Compute from Palo Alto Networks.
  • Imports vulnerability data for the images that are deployed to runtime, and enriches the vulnerability data with runtime contextual information (hosts, Kubernetes clusters, services, and namespaces).
  • Provides a list of the references created from vulnerabilities to the relevant Kubernetes entities in the Configuration Management Database (CMDB) using ServiceNow Kubernetes Discovery.
  • Offers a comprehensive reporting dashboard, providing insights into the vulnerability and remediation trends.

Key features

The Container Vulnerability Response application manages vulnerabilities detected in the containers. It provides the following features:
  • Point to source Docker Image from CVITs instead of running containers.
  • Configure granularity of CVITs to track at image, Kubernetes cluster, namespace, or service level.
  • Track new image versions to identify fixed vulnerabilities. Any vulnerabilities reported in older versions are automatically resolved in ServiceNow when new image versions are deployed at runtime.
  • Track CVITs in Base images separately from Application images to enable independent remediation.
  • Raise exception requests or false positive requests, which can be reviewed through a multi-level approver process.
  • Define exception rules to defer CVITs automatically.

Use cases

Containers are a great way of deploying and scaling applications on multiple environments with less overhead and increased portability. However, vulnerabilities in container images can pose risk to the underlying host and ultimately to the infrastructure where containers have been launched from these images. While there are many container security products that scan container images for vulnerabilities, there are a few considerations and problems associated with remediation of the vulnerabilities. Container Vulnerability Response can help solve various problems or use cases involved in remediating container image vulnerabilities. Explore ways to take advantage of the Container Vulnerability Response module:
Runtime context
Vulnerabilities in container images can be discovered by scanning the image in the following stages of the application life cycle.
  • Stage 1: When images are being built in the CI/CD pipeline.
  • Stage 2: When images are published to the registry
  • Stage 3: When images are deployed to runtime.
While it’s important to identify vulnerabilities as early as possible in stage 1 and stage 2, performing a scan on those images that are deployed to a runtime environment is equally important. It offers the following benefits:
  • Identifying any new common vulnerabilities and exposures (CVEs) that got published.
  • Providing accurate visibility into the risk posture of applications deployed.
  • Prioritizing of vulnerabilities that must be resolved. The runtime context in terms of the application services or business services impacted due to a vulnerability can help with prioritization.

Container Vulnerability Response integrates with container security products such as Prisma Cloud Compute from Palo Alto Networks to pull the vulnerability data for those images that are deployed to runtime and enriches the vulnerability data with the runtime contextual information such as hosts, Kubernetes clusters, services, and namespaces where these container images are deployed. Customers using the ServiceNow Kubernetes discovery can see the references created from vulnerabilities to the relevant Kubernetes entities in their Configuration Management Database (CMDB). In addition to enriching the metadata, ServiceNow also offers a comprehensive reporting dashboard to provide insights into the vulnerability and remediation trends.Runtime context

Identify ownership
Pre-requisites

  • Kubernetes metadata and references: For Container Vulnerability Response to populate Kubernetes metadata (namespace, cluster, and so on) and references to Configuration Management Database (CMDB) entries, you must implement the Kubernetes discovery from Information Technology Operations Management (ITOM). Kubernetes discovery populates Docker Image, the running Docker Containers, Pods, Kubernetes Clusters, and so on, in the CMDB. Container Vulnerability Response identifies the Docker Image in CMDB based on image ID, and then identifies the related Kubernetes entities and populates the references to those entities from vulnerable items.

  • Cloud metadata and Docker Image labels: Container Vulnerability Response also populates Docker Image labels, cloud account IDs, regions where an image is deployed. This data is maintained in “Discovered Container Image” record associated with the vulnerable item. There are no pre-requisites for this data to be populated. Container Vulnerability Response uses the data returned by container security products (for example, Palo Alto Prisma Cloud Compute) to populate these entries.

Ownership for patching a vulnerability in a container image can vary from organization to organization. This information may be captured in different places. A few organizations use Docker Image labels as a way of identifying the application teams who own a certain container image while other organizations may use the Kubernetes namespace or the cloud account where a container image is deployed to identify the right owner.

Container Vulnerability Response provides the necessary data model elements to be able to capture and use the Docker Image labels, Kubernetes cluster/service/namespace metadata, or the cloud account metadata (cloud account id, region, provider, and so on) in the ‘Assignment rules’ module and automatically assign vulnerabilities to the right application team based on the metadata of the image or the runtime environment.

Ownership identification

Track vulnerabilities in the base images
Pre-requisites

For ‘Base Image’ property to be populated in Container Vulnerability Response, base images must be configured explicitly in the Vulnerability Response Integration with Palo Alto Networks Prisma Cloud Compute console. For more information on how to configure base images in Prisma Cloud, see https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin- compute/vulnerability_management/base_images.

Container Vulnerability Response enables for the creation of separate vulnerability records for a base layer so that they can be assigned to a different team.

Track vulnerabilities identified in a base OS image such as Alpine from the vulnerabilities detected in other layers of the container image. Many organizations have dedicated teams who are responsible for patching base OS images and making them available for all the application teams.base image

Define granularity for vulnerable items
Pre-requisites

Configure the granularity of CVITs by navigating to All > Container Vulnerability Response > Administration > Configure VI Granularity.

VI granularity

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.

VI granularity

In the example, you can see two vulnerable items created for the same Docker Image and CVE combination. One for the Kubernetes namespace ‘k8s-finservco-loans’ and the other one for ‘k8s-finservco-wealthandinsurance’.

Identify impacted services using tag-based service identification
Pre-requisites
  • Identify various services in your application and define the tags/ key-value pairs that represent those services.
  • Deploy Docker Images and Kubernetes pods with those tags or labels.
  • Deploy ITOM Kubernetes Discovery Define 'Tag-based Services' with the right tags or labels.
  • Deploy ITOM Kubernetes Discovery
  • Define 'Tag-based Services' with the right tags or key-value pairs.
  • Import vulnerability data into ServiceNow using Container Vulnerability Response

Risk calculation for vulnerable items can be done by looking at the CI (Docker Image) and the criticality of associated services in CMDB. However, to make it easier to identify impacted services, Container Vulnerability Response offers tag-based service identification.

When Kubernetes pods or entities are published with key-values or labels matching the key-values defined in any ‘Tag-based Service’ in ServiceNow, Container Vulnerability Response automatically establishes the relationship between a Docker Image, and the impacted application service and uses the criticality of that application service in risk calculation.

The flow is as follows:
  1. Container Vulnerability Response imports vulnerability data from container security product.
  2. For each container vulnerable item, Container Vulnerability Response populates the Docker Image from CMDB that has the vulnerability.
  3. Container Vulnerability Response then looks at the Docker Image labels, or the labels/key-values published with Kubernetes pods where this image is deployed. This image is available in CMDB if you have the Kubernetes discovery running.
  4. Container Vulnerability Response then searches for ‘Tag-based Services’ in CMDB with the same matching key-value pairs defined.Risk calculation

    Risk calculation

  5. Container Vulnerability Response uses the ‘Business criticality’ of the matched ‘Tag-based Service’ (if any found) to calculate the risk of a container vulnerable item.

    Risk calculation

    Risk calculation
Tracking Vulnerabilities
Setting remediation targets

ServiceNow enables vulnerability managers to define ‘Remediation target rules’ to be able to define service level agreements (SLAs) for fixing vulnerabilities found in container images. Remediation target date can be defined based on a condition/criterion on image metadata or vulnerability information. Remediation owners receive email communication on the vulnerabilities that are approaching the due date.Set remediation target

Identifying fixed vulnerabilities

Unlike host vulnerabilities that can be fixed by applying a patch on a host, container vulnerabilities can’t be patched. New versions of container images must be created and deployed to replace the older versions. The new versions have a different identifier (image ID) compared to the previous versions that makes it challenging to keep track which vulnerabilities have been fixed already.

ServiceNow identifies vulnerabilities that were reported in the previous versions of the container images but resolved in the latest version of the image and automatically moves those vulnerabilities to ‘Closed/Fixed’ state so that security teams always have accurate visibility into the latest risk posture.

Manage exceptions

Application teams or remediation owners for the vulnerabilities might need the ability to request for an exception due to the following reasons.

  • A mitigation control is already in place
  • Risk accepted
  • Awaiting maintenance window to push the fix.

ServiceNow enables security admins to define multiple levels of approvers for exception requests. You can also define auto exception rules that can be used to defer automatically vulnerabilities matching a given condition.Exceptions

Exceptions

What's new

To learn more about what's new and what's changed in Washington DC, see the Washington DC release notes.

Get started