Automate Aqua Responses with Webhooks and API (2026)

Aqua Security’s vulnerability scanner can tell you what’s wrong, but it doesn’t automatically fix it. That’s where webhooks and the Aqua API come in, turning a passive report into an active response.

Let’s see this in action. Imagine you’ve just scanned an image, and Aqua found a critical vulnerability in openssl.

{
  "scanId": "a1b2c3d4-e5f6-7890-1234-abcdef123456",
  "findings": [
    {
      "id": "CVE-2023-1234",
      "severity": "Critical",
      "package": "openssl",
      "version": "1.1.1t-1ubuntu1.3",
      "description": "A buffer overflow vulnerability in the SSLv3 \"handshake\" state could allow an attacker to crash the server or, in some cases, execute arbitrary code.",
      "fixedVersion": "1.1.1u-1ubuntu1.4"
    }
  ],
  "status": "Success"
}

This JSON payload, representing the scan results, is what Aqua sends out via a webhook. Your webhook listener, a simple HTTP endpoint you control, receives this. It then needs to process this data and decide on an action.

The most common action is to use the Aqua API to trigger a rebuild of the image with the vulnerability fixed. This involves a few steps:

1. Identify the image: The webhook payload usually includes the image name and tag.
2. Find the fix: The findings array tells you the package and its fixedVersion.
3. Trigger a rebuild: Use the Aqua API to initiate a new scan or build process for a patched version of the image.

Here’s a conceptual flow:

• Aqua Scanner: Scans my-app:latest. Finds openssl:1.1.1t is vulnerable (CVE-2023-1234), fix is openssl:1.1.1u.
• Webhook: Aqua sends scan results to http://my-webhook-listener.com/aqua.
• Webhook Listener: Receives JSON. Parses it. Sees "Critical" severity for openssl.
• Listener Logic: Decides to trigger a rebuild. It might:
  • Add a RUN apt-get update && apt-get install -y openssl=1.1.1u-1ubuntu1.4 command to the Dockerfile.
  • Or, more commonly, trigger a new image build in your CI/CD pipeline (e.g., Jenkins, GitLab CI, GitHub Actions) that already has logic to update specific packages during the build.
• CI/CD Pipeline: Detects the rebuild trigger, fetches the latest base image, applies the openssl update, rebuilds my-app:latest (or a new tagged version like my-app:v1.2.3-fixed-openssl), and pushes it.
• Aqua API: The listener could also directly call the Aqua API to, for instance, mark the original image as "risky" or add it to a watchlist if the rebuild fails.

The mental model here is that Aqua is the detection engine, and your webhook/API integration is the action engine. You’re essentially building a feedback loop. Aqua tells you there’s a fire, and your system automatically dispatches the fire department (or, in this case, a patch).

The Aqua API is a RESTful interface, meaning you interact with it using standard HTTP methods (GET, POST, PUT, DELETE) and JSON payloads. You’ll need an Aqua API token, typically generated from the Aqua UI under Settings -> API Keys.

Let’s say you want to trigger a scan for a specific image using the API. You’d make a POST request to an endpoint like:

POST https://<your-aqua-server>/api/v2/scans

with a JSON body specifying the image to scan:

{
  "imageName": "my-registry.com/my-org/my-app",
  "tag": "latest",
  "scanType": "image"
}

This API call is what your webhook listener might execute after receiving a critical vulnerability alert. It’s not just about knowing there’s a problem; it’s about doing something about it programmatically.

The most surprising truth about automating responses is that the webhook payload itself is often just a trigger. The real intelligence and action reside in the system receiving the webhook. Aqua provides the alert; you build the automated remediation. This means you can integrate Aqua with virtually any system that can receive an HTTP POST request – from simple scripts to complex enterprise CI/CD orchestrators.

The next step after automating vulnerability patching is often automating the process of preventing vulnerable images from being deployed in the first place, using Aqua’s admission control features.