1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Alerts
    6. Webhook alerts
    End-of-Life (EoL)

    Webhook alerts

    Prisma Cloud offers native integration with a number of services, including email, JIRA, and Slack. When no native integration is available, webhooks provide a mechanism to interface Prisma Cloud’s alert system with virtually any third party service.
    A webhook is an HTTP callback. When an event occurs, Prisma Cloud notifies your web service with an HTTP POST request. The request contains an JSON body that you configure when you set up the webhook. A webhook configuration consists of:
    • URL
    • Custom JSON body
    • Credentials
    • CA Certificate

    Custom JSON body

    You can customize the body of the POST request with values of interest. The content of the JSON object in the request body is defined using predefined macros. For example:
    {
  "type":#type,
  "host":#host,
  "details":#message
}
    When an event occurs, Prisma Cloud replaces the macros in your custom JSON with real values, and then submits the request.
    {
  "type":"ContainerRuntime",
  "host":"host1",
  "details":"/bin/cp changed binary /bin/busybox MD5:XXXXXXX"
}
    All supported macros are described in the following table. Not all macros are applicable to all alert types.
    Rule
    Description
    Audit alert type. For example, 'Container Runtime'.
    Audit alert time. For example, 'Jan 21, 2018 UTC'.
    Impacted container.
    Impacted image.
    Hostname for the host where the audit occurred.
    Fully qualified domain name for the host where the audit occurred.
    Serverless function where the audit occurred.
    Region where the audit occurred. For example 'N. Virginia'.
    Language runtime in which the audit occurred. For example, 'python3.6'.
    Serverless or Function name.
    Rule which triggered the alert.
    Associated alert message.
    All fields in the audit message as a single JSON object.
    All subsequent alerts that occurred during the aggregation period, in JSON format.
    API link to download the forensics data for the incident.
    The cloud account ID in which the audit was detected.
    The cluster in which the audit was detected.
    A list of the alert labels of the resource in which the audit was detected.
    A list of the associated collections for the resource where the issue was detected.
    The compliance issues detected in the latest scan of the resource.
    A single alert includes compliance issues for a single resource.
    The new vulnerabilities detected in the latest scan.
    A single alert includes vulnerabilities for all resources where new vulnerabiltiies were found, so the vulnerabilities macro includes the data about the resources as well. All other macros, except type and time, will be empty.
    The #vulnerabilities and #complianceIssues macros include inner structures. Below is an example of their content. Notice that the structure is subject to minor changes between versions.
    {
    "vulnerabilities": [
    {
      "imageName": "ubuntu@sha256:c95a8e48bf...", [only for image vulnerabilities]
      "imageID": "sha256:f643c72bc25212974c1...", [only for image vulnerabilities]
      "hostname": "console.compute.internal", [only for host vulnerabilities]
      "distribution": "Ubuntu 20.04.1 LTS",
      "labels": {
        "key1": "value1",
        "key2": "value2"
      },
      "collections": [
        "All",
        "collection1",
        "collection2"
      ],
      "newVulnerabilities": [
        {
          "severity": "High",
          "vulnerabilities": [
            {
              "cve": "CVE-2020-1971",
              "severity": "high",
              "link": "https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-1971",
              "status": "Fixed in: 1.0.1f-1ubuntu2.27+esm2",
              "packages": "openssl",
              "packageVersion": "1.0.1f-1ubuntu2.27"
            },
            ... more vulnerabilities
          ]
        },
        {
          "severity": "Low",
          "vulnerabilities": [
            {
              "cve": "CVE-2019-25013",
              "severity": "low",
              "link": "https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-25013",
              "status": "needed",
              "packages": "libc-dev-bin,libc6-dev,libc6,libc-bin",
              "packageVersion": "2.31-0ubuntu9.1",
              "sourcePackage": "glibc"
            },
            ... more vulnerabilities
          ]
        }
      ]
    },
    ... more images/hosts
  ]
}
    {
    "complianceIssues": [
    {
      "title": "(CIS_Docker_v1.2.0 - 4.1) Image should be created with a non-root user",
      "id": "41",
      "description": "It is a good practice to run the container as a non-root user, if possible...",
      "type": "image",
      "category": "Docker",
      "severity": "high"
    },
      "title": "Private keys stored in image",
      "id": "425",
      "description": "",
      "type": "image",
      "category": "Twistlock Labs",
      "severity": "high",
      "cause": "Found: /usr/share/npm/node_modules/agent-base/..."
    },
    ... more compliance issues
  ]
}

    Configuring alert frequency

    You can configure the rate at which alerts are emitted. This is a global setting that controls the spamminess of the alert service. Alerts received during the specified period are aggregated into a single alert. For each alert profile, an alert is sent as soon as the first matching event is received. All subsequent alerts are sent once per period.
    1. Open Console, and go to
      Manage > Alerts
      .
    2. In
      Aggregate audits every
      , specify the maximum rate that alerts should be sent.
      You can specify
      Second
      ,
      Minute
      ,
      Hour
      ,
      Day
      .