Integrating Container Vulnerability Response with other applications

  • Release version: Washingtondc
  • Updated February 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Integrating Container Vulnerability Response with Other Applications

    This guide outlines how to enhance Container Vulnerability Response by integrating it with various applications, enabling you to gather and analyze vulnerability data for deployed container images in runtime environments. The integration enriches vulnerability data with contextual information from ServiceNow’s Kubernetes discovery, allowing visibility into relevant Kubernetes entities within your Configuration Management Database (CMDB).

    Show full answer Show less

    Key Features

    • Integration with container security products for real-time vulnerability data retrieval.
    • Enrichment of vulnerability data with runtime context including hosts, Kubernetes clusters, services, and namespaces.
    • Comprehensive reporting dashboard for insights into vulnerability and remediation trends.
    • Integration capabilities with applications such as Palo Alto Networks Prisma Cloud Compute, Atlassian Jira, and Tenable Vulnerability.
    • Ability to create and track agile issues for remediation of Container Vulnerability Indicator Threats (CVITs) and Remediation Tasks (RTs) in the Vulnerability Manager Workspace.

    Key Outcomes

    By integrating Container Vulnerability Response with other applications, you can achieve a streamlined process for vulnerability management, enabling quicker identification and resolution of vulnerabilities. You can expect improved data processing with periodic heartbeats to monitor integration status, and better handling of potential timeouts through the Last Record Processed field, ensuring efficient data flow and management.

    Extend the capabilities of Container Vulnerability Response by integrating with other applications.

    Container Vulnerability Response integrates with container security products to pull vulnerability data for those images which are deployed to runtime. It then enriches the vulnerability data with the runtime contextual information such as hosts, Kubernetes clusters, services, and namespaces where these container images are deployed. With ServiceNow’s Kubernetes discovery, you can see the references created from vulnerabilities to the relevant Kubernetes entities in your 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.

    Container Vulnerability Response provides integrations with the following applications:

    Additional notes for integrations

    During integration execution, multiple processes are generated, and data is received in the form of pages. Each process can contain one or more import queue entries with attached data in pages. These entries must process the data within the one-hour time limit. However, if the payload size is large, the processing time may exceed one hour or get stuck, resulting in an integration timeout error. The integration continues to process the data despite the timeout error. To avoid this miscommunication, starting from version 2.1.2 of Container Vulnerability Response, timestamps (heartbeats) are sent periodically to indicate if the queue is active and processing data. The Last Record Processed field in the Import Queue Entry page is updated based on the count of records the import queue creates or updates. In case an import queue entry exceeds the one-hour time limit, the system checks the Last Record Processed field to see if it is also older than one hour. If it is, this indicates that the import queue entry is stuck, and it is timed out to prevent any further delays in processing.
    Note:
    The Last Record Processed field is updated based on what is defined in the following system properties:
    • sn_sec_cmn.record_threshold_heartbeat: Defines the number of processed records, after which the heartbeat (timestamp) is sent to the import queue entry.
    • sn_sec_cmn.maximum_heartbeat_delay: Defines the time after which the import queue entry must be timed out.