Container Vulnerability Response
Summarize
Summary of Container Vulnerability Response
The ServiceNow Container Vulnerability Response application enables customers to import container vulnerable items (CVITs) from various sources such as the National Vulnerability Database (NVD) and third-party container security products like Palo Alto Networks Prisma Cloud Compute. It helps ServiceNow users manage, monitor, and remediate container image vulnerabilities by enriching vulnerability data with runtime context (hosts, Kubernetes clusters, services, namespaces) and linking vulnerabilities to Kubernetes entities within the Configuration Management Database (CMDB).
Show less
Key Features
- Runtime Context Integration: Enhances vulnerability data with deployment environment details for accurate risk assessment and prioritization.
- Granularity Configuration: Allows defining vulnerable items at image, Kubernetes cluster, namespace, or service level to match organizational structure and ownership.
- Tracking Fixed Vulnerabilities: Automatically closes vulnerabilities resolved by deploying new container image versions.
- Base Image Vulnerability Tracking: Separates vulnerabilities in base OS images from application images to assign remediation responsibilities correctly.
- Exception Management: Supports multi-level approval workflows for exception requests and auto-deferral rules for vulnerabilities.
- Ownership Identification: Uses Docker Image labels, Kubernetes metadata, or cloud account information to assign vulnerabilities to the correct application teams via assignment rules.
- Tag-Based Service Identification: Establishes relationships between Docker Images and impacted services using tags or labels to enhance risk calculation based on service criticality.
- Remediation Target Rules: Enables defining SLAs and remediation deadlines for container vulnerabilities, with automated notifications for owners.
Practical Use and Benefits for ServiceNow Customers
Container Vulnerability Response addresses challenges in detecting and remediating vulnerabilities across container lifecycles, especially at runtime where new CVEs may emerge. It provides customers with:
- Comprehensive visibility into container vulnerability status enriched with deployment context.
- Automated workflows to assign vulnerabilities to the right teams based on metadata and runtime environment.
- Accurate tracking of vulnerability resolution through image versioning, ensuring security teams focus on current risks.
- Robust exception handling and SLA-driven remediation management to align with organizational policies.
- Integration with Kubernetes discovery and CMDB to maintain authoritative references and improve impact analysis.
- Advanced reporting dashboards for monitoring vulnerability trends and remediation progress.
Prerequisites and Configuration Considerations
- Implement Kubernetes discovery from IT Operations Management (ITOM) to populate Kubernetes metadata and CMDB references.
- Configure base images in integrated container security products (e.g., Prisma Cloud) to track base layer vulnerabilities separately.
- Define tag-based services with appropriate key-value pairs to leverage enhanced service impact and risk scoring.
- Adjust granularity settings to suit team structures and deployment scenarios for more precise vulnerability tracking.
Next Steps for Customers
Customers can begin by configuring Container Vulnerability Response within their ServiceNow Security Operations instance, integrating their container security product data, and enabling Kubernetes discovery to enrich vulnerability data. Defining assignment rules, exception workflows, and remediation targets will streamline vulnerability management processes. Utilizing the built-in dashboards and reports will provide actionable insights into vulnerability trends and remediation effectiveness.
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.
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
- 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
- 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
- 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.
- 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.
- 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.
- Define granularity for vulnerable items
- Pre-requisites
Configure the granularity of CVITs by navigating to .
-
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.
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:- Container Vulnerability Response imports vulnerability data from container security product.
- For each container vulnerable item, Container Vulnerability Response populates the Docker Image from CMDB that has the vulnerability.
- 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.
- Container Vulnerability Response then searches for ‘Tag-based Services’ in CMDB with the same matching key-value pairs defined.
- 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.
- 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.
- 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.
What's new
To learn more about what's new and what's changed in Zurich, see the Zurich release notes.
Get started
- For an overview about Security Operations in your ServiceNow AI Platform instance, see Understanding Security Operations.
- For information about all the Security Operations applications available for download from the ServiceNow Store, see Security Operations and the ServiceNow Store.