Author: Ben Lang

Through the Looking Glass: A Mad Tea-Party

This is post 3 in a seven-part series on what the Anchore Enterprise API makes possible for container security teams. 

The fastest way to react to a new Critical CVE is to not have to ask. When a vulnerability is disclosed, a policy evaluation fails, or a container image finishes analysing, you want your tooling to respond on its own — the moment Anchore knows about it, not the next time your cron job wakes up. Anchore Enterprise’s webhook notifications make that loop fast and direct.

Anchore Events are the platform’s internal log of everything notable that happens — image analyses completing, policy evaluations changing, vulnerabilities being identified, system errors being logged — and webhook notifications are how you subscribe to the slice that matters to you. Events don’t arrive on your schedule — they arrive on theirs. The Mad Tea-Party in Wonderland is the canonical scene for this: Alice walks up to a table already in progress, where things happen when they happen and not before. Anchore’s notifications work the same way, and your job as the receiver is to be ready when the cup is passed.

Anchore Enterprise supports outbound webhooks that fire when key events occur. This makes it straightforward to build event-driven workflows that connect Anchore to the rest of your tooling — ticket systems, deployment pipelines, Slack channels, SIEMs, or anything else that accepts an HTTP request.

Setting the Table: Configuring a Webhook

Before any guest can sit down, the Hatter has to set out the cups. Webhooks in Anchore Enterprise are managed through the notifications API and work the same way: first register a webhook endpoint configuration (the cup), then attach a selector that defines which events should be delivered to it (who gets a seat at that end of the table).

Register your webhook endpoint configuration:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/notifications/endpoints/webhook/configurations" \
  -H "Content-Type: application/json" \ 
  -d '{
    "name": "tea-party-receiver",
    "url": "https://hatter-table.wonderland.example.com/anchore/webhook",
    "verify_ssl": true
  }'

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/notifications/endpoints/webhook/configurations" \
  -H "Content-Type: application/json" \ 
  -d '{
    "name": "tea-party-receiver",
    "url": "https://hatter-table.wonderland.example.com/anchore/webhook",
    "verify_ssl": true
  }'

The response will include a uuid for the newly created configuration. Use that to attach a selector that maps policy evaluation events to this endpoint:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/notifications/endpoints/webhook/configurations/<uuid>/selectors" \
  -H "Content-Type: application/json" \
  -d '{
    "scope": "account",
    "event": {
      "level": "*",
      "resource_type": "image_digest",
      "type": "user.image.policy_eval.*"
    }
  }'

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/notifications/endpoints/webhook/configurations/<uuid>/selectors" \
  -H "Content-Type: application/json" \
  -d '{
    "scope": "account",
    "event": {
      "level": "*",
      "resource_type": "image_digest",
      "type": "user.image.policy_eval.*"
    }
  }'

The event filter uses a structured <category>.<subcategory>.<event> format and supports wildcards, so user.image.policy_eval.* captures all policy evaluation outcomes for images in your account. You can retrieve the full list of supported event types from the /v2/event_types endpoint on your deployment. The scope field controls breadth — account limits events to your own account, while global (admin only) captures events across the entire system.

Anchore will POST to your registered URL whenever a matching event fires. Before putting it into production, you can verify your endpoint is reachable using the built-in test endpoint:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/notifications/endpoints/webhook/configurations/<uuid>/test"

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/notifications/endpoints/webhook/configurations/<uuid>/test"

What’s in the Cup: Understanding the Payload

Before you write logic against the events, it’s worth looking at what’s actually in the cup. When Anchore fires a webhook, it POSTs a JSON payload to your registered URL with the following structure:

{
  "id": "211c5fff5641456d935e60f905c46a66",
  "type": "user.image.analysis_update",
  "level": "info",
  "message": "Image analysis complete",
  "details": {},
  "timestamp": "2025-10-01T09:08:54.749806",
  "resource": {
    "account_name": "mad-hatter-team",
    "type": "image_digest",
    "id": "sha256:<digest>"
  },
  "source": {
    "request_id": null,
    "service_name": "catalog",
    "host_id": "anchore-enterprise-catalog-5654fb8d84-5ln8r",
    "base_url": "http://anchore-enterprise-catalog.anchore.svc.cluster.local:8082"
  }
}

{
  "id": "211c5fff5641456d935e60f905c46a66",
  "type": "user.image.analysis_update",
  "level": "info",
  "message": "Image analysis complete",
  "details": {},
  "timestamp": "2025-10-01T09:08:54.749806",
  "resource": {
    "account_name": "mad-hatter-team",
    "type": "image_digest",
    "id": "sha256:<digest>"
  },
  "source": {
    "request_id": null,
    "service_name": "catalog",
    "host_id": "anchore-enterprise-catalog-5654fb8d84-5ln8r",
    "base_url": "http://anchore-enterprise-catalog.anchore.svc.cluster.local:8082"
  }
}

The key fields for building a receiver are type (the event that fired, matching the pattern you set in your selector), level (info, warn, or error), and resource.id (the identifier for the affected resource — for image events, this will be the image digest). The details object carries event-specific additional data that varies by event type.

Is Your Watch Right? Testing Your Receiver

The Hatter’s watch was two days wrong, even with butter in the works. Before wiring real logic to the events Anchore sends, prove your receiver is reachable and the payloads look the way you expect.

For a one-off smoke test, point your webhook configuration at webhook.site — it gives you a disposable URL and a live view of every request that arrives, no code required. That’s enough to confirm the event is firing and to eyeball the payload shape.

When you need to run logic against the events — for example to see exactly what details contains across multiple event types, since its content varies and isn’t fully enumerated in the documentation — stand up a minimal local logger. Here’s a Flask service that accepts any POST and logs the full payload:

import json
import logging
from flask import Flask, request, jsonify

app = Flask(__name__)
logging.basicConfig(level=logging.INFO)

@app.route("/anchore/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    logging.info(json.dumps(payload, indent=2))
    return jsonify({"status": "received"}), 200

if __name__ == "__main__":
    app.run(port=5000)

import json
import logging
from flask import Flask, request, jsonify

app = Flask(__name__)
logging.basicConfig(level=logging.INFO)

@app.route("/anchore/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    logging.info(json.dumps(payload, indent=2))
    return jsonify({"status": "received"}), 200

if __name__ == "__main__":
    app.run(port=5000)

Point your webhook configuration at this endpoint, trigger a few events, and inspect what arrives before writing production logic against it.

Pouring the Tea: Building a Webhook Receiver in Python

Once you know what’s in the cup, doing something with it is straightforward. The example below routes events by type, extracts the image digest from resource.id, and queries the API for the full vulnerability list:

import logging
import requests
from flask import Flask, request, jsonify

>app = Flask(__name__)
logging.basicConfig(level=logging.INFO)

ANCHORE_URL = "https://wonderland.example.com/v2"
AUTH = ("_api_key", "<your-api-key>")

>def get_vulnerabilities(digest):
    resp = requests.get(
        f"{ANCHORE_URL}/images/{digest}/vuln/all",
        auth=AUTH,
    )
    resp.raise_for_status()
    return resp.json().get("vulnerabilities", [])

@app.route("/anchore/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    event_type = payload.get("type", "")
    level = payload.get("level", "")
    resource = payload.get("resource", {})
    digest = resource.get("id")

    if not digest or resource.get("type") != "image_digest":
        logging.info(f"Ignoring non-image event: {event_type}")
        return jsonify({"status": "ignored"}), 200

    logging.info(f"Event: {event_type} | Level: {level} | Digest: {digest}")

    if "analysis_update" in event_type and level == "info":
        vulns = get_vulnerabilities(digest)
        critical = [v for v in vulns if v.get("severity") == "Critical"]
        if critical:
            logging.warning(
                f"{len(critical)} Critical vulnerabilities in {digest}"
            )
            # open a ticket, page on-call, block promotion, etc.
        else:
            logging.info(
                f"No Critical vulnerabilities in {digest} "
               "— eligible for promotion"
            )
            # trigger promotion pipeline, notify Slack, update CMDB, etc.

    return jsonify({"status": "received"}), 200

if __name__ == "__main__":
    app.run(port=5000)

import logging
import requests
from flask import Flask, request, jsonify

>app = Flask(__name__)
logging.basicConfig(level=logging.INFO)

ANCHORE_URL = "https://wonderland.example.com/v2"
AUTH = ("_api_key", "<your-api-key>")

>def get_vulnerabilities(digest):
    resp = requests.get(
        f"{ANCHORE_URL}/images/{digest}/vuln/all",
        auth=AUTH,
    )
    resp.raise_for_status()
    return resp.json().get("vulnerabilities", [])

@app.route("/anchore/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    event_type = payload.get("type", "")
    level = payload.get("level", "")
    resource = payload.get("resource", {})
    digest = resource.get("id")

    if not digest or resource.get("type") != "image_digest":
        logging.info(f"Ignoring non-image event: {event_type}")
        return jsonify({"status": "ignored"}), 200

    logging.info(f"Event: {event_type} | Level: {level} | Digest: {digest}")

    if "analysis_update" in event_type and level == "info":
        vulns = get_vulnerabilities(digest)
        critical = [v for v in vulns if v.get("severity") == "Critical"]
        if critical:
            logging.warning(
                f"{len(critical)} Critical vulnerabilities in {digest}"
            )
            # open a ticket, page on-call, block promotion, etc.
        else:
            logging.info(
                f"No Critical vulnerabilities in {digest} "
               "— eligible for promotion"
            )
            # trigger promotion pipeline, notify Slack, update CMDB, etc.

    return jsonify({"status": "received"}), 200

if __name__ == "__main__":
    app.run(port=5000)

The notification tells you something happened and which container image it happened to; the API call tells you what was found. The logic in the if critical branch is entirely yours — open a Jira ticket, post a formatted message to Slack, block a deployment pipeline, or trigger a rollback. Anchore fires the event and holds the data; your service decides what happens next.

“Move Down, Move Down!”: Transforming and Forwarding to a SIEM

Whenever the Hatter ran out of clean cups, everyone shifted one seat to the right and used the next person’s place. A natural extension of the webhook receiver follows the same idea: take the enriched data — the Anchore event combined with the vulnerability findings you’ve just fetched — and pass it along to a SIEM or other downstream system in a normalized format. This is the transform-and-forward pattern: receive the raw event, enrich it with context from the API, reshape it into the structure your tooling expects, and send it on.

The transformation step is where you decide what the downstream system needs to know. A SIEM doesn’t need the full Anchore vulnerability object for every finding — it typically needs a structured event with enough context to correlate, alert, and drive investigation. Here’s a function that builds that normalized event from the Anchore webhook payload and vulnerability data:

from collections import Counter
from datetime import datetime, timezone

def build_siem_event(payload, vulns):
    resource = payload.get("resource", {})
    severity_counts = Counter(
        v.get("severity", "Unknown") for v in vulns
    )
    critical_findings = [
        {
            "cve": v.get("vuln"),
            "severity": v.get("severity"),
            "package": v.get("package"),
            "package_version": v.get("package_version"),
            "fix_available": v.get("fix") not in (None, "None"),
            "fix_version": (
                v.get("fix") if v.get("fix") not in (None, "None") else None
           ),
        }
        for v in vulns if v.get("severity") == "Critical"
    ]
    return {
        "event_id": payload.get("id"),
        "event_type": payload.get("type"),
        "level": payload.get("level"),
        "timestamp": payload.get("timestamp"),
        "forwarded_at": datetime.now(timezone.utc).isoformat(),
        "image": {
            "digest": resource.get("id"),
           "account": resource.get("account_name"),
        },
        "vulnerability_summary": {
            "total": len(vulns),
            "critical": severity_counts.get("Critical", 0),
            "high": severity_counts.get("High", 0),
            "medium": severity_counts.get("Medium", 0),
            "low": severity_counts.get("Low", 0),
            "negligible": severity_counts.get("Negligible", 0),
        },
        "critical_findings": critical_findings,
        "source": payload.get("source", {}),
    }

from collections import Counter
from datetime import datetime, timezone

def build_siem_event(payload, vulns):
    resource = payload.get("resource", {})
    severity_counts = Counter(
        v.get("severity", "Unknown") for v in vulns
    )
    critical_findings = [
        {
            "cve": v.get("vuln"),
            "severity": v.get("severity"),
            "package": v.get("package"),
            "package_version": v.get("package_version"),
            "fix_available": v.get("fix") not in (None, "None"),
            "fix_version": (
                v.get("fix") if v.get("fix") not in (None, "None") else None
           ),
        }
        for v in vulns if v.get("severity") == "Critical"
    ]
    return {
        "event_id": payload.get("id"),
        "event_type": payload.get("type"),
        "level": payload.get("level"),
        "timestamp": payload.get("timestamp"),
        "forwarded_at": datetime.now(timezone.utc).isoformat(),
        "image": {
            "digest": resource.get("id"),
           "account": resource.get("account_name"),
        },
        "vulnerability_summary": {
            "total": len(vulns),
            "critical": severity_counts.get("Critical", 0),
            "high": severity_counts.get("High", 0),
            "medium": severity_counts.get("Medium", 0),
            "low": severity_counts.get("Low", 0),
            "negligible": severity_counts.get("Negligible", 0),
        },
        "critical_findings": critical_findings,
        "source": payload.get("source", {}),
    }

With a normalized event in hand, forwarding it is a straightforward HTTP POST to whatever endpoint your tooling exposes. The example below targets an Elasticsearch index using the _doc endpoint — a common SIEM ingestion pattern — but the same approach applies to Microsoft Sentinel, Datadog, or any platform that accepts JSON over HTTP:

import os
import requests

ES_URL = "https://looking-glass-search.wonderland.example.com:9200"
ES_INDEX = "anchore-events"
ES_API_KEY = os.environ["ELASTIC_API_KEY"]

def forward_to_siem(event):
    resp = requests.post(
        f"{ES_URL}/{ES_INDEX}/_doc",
        json=event,
        headers={"Authorization": f"ApiKey {ES_API_KEY}"},
        timeout=5,
    )
    resp.raise_for_status()
    logging.info(f"Forwarded event {event['event_id']} to SIEM")

import os
import requests

ES_URL = "https://looking-glass-search.wonderland.example.com:9200"
ES_INDEX = "anchore-events"
ES_API_KEY = os.environ["ELASTIC_API_KEY"]

def forward_to_siem(event):
    resp = requests.post(
        f"{ES_URL}/{ES_INDEX}/_doc",
        json=event,
        headers={"Authorization": f"ApiKey {ES_API_KEY}"},
        timeout=5,
    )
    resp.raise_for_status()
    logging.info(f"Forwarded event {event['event_id']} to SIEM")

Bringing it all together, the updated webhook route chains the full pipeline — receive, enrich, transform, forward:

@app.route("/anchore/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    resource = payload.get("resource", {})
    digest = resource.get("id")

    if not digest or resource.get("type") != "image_digest":
        logging.info(
            f"Ignoring non-image event: {payload.get('type')}"
        )
        return jsonify({"status": "ignored"}), 200

    # Enrich: fetch vulnerability data from Anchore
    vulns = get_vulnerabilities(digest)

    # Transform: build a normalized SIEM event
    event = build_siem_event(payload, vulns)

    # Forward: send to SIEM
    try:
        forward_to_siem(event)
    except Exception as e:
        logging.error(f"Failed to forward event to SIEM: {e}")

    return jsonify({"status": "received"}), 200

@app.route("/anchore/webhook", methods=["POST"])
def webhook():
    payload = request.get_json(force=True)
    resource = payload.get("resource", {})
    digest = resource.get("id")

    if not digest or resource.get("type") != "image_digest":
        logging.info(
            f"Ignoring non-image event: {payload.get('type')}"
        )
        return jsonify({"status": "ignored"}), 200

    # Enrich: fetch vulnerability data from Anchore
    vulns = get_vulnerabilities(digest)

    # Transform: build a normalized SIEM event
    event = build_siem_event(payload, vulns)

    # Forward: send to SIEM
    try:
        forward_to_siem(event)
    except Exception as e:
        logging.error(f"Failed to forward event to SIEM: {e}")

    return jsonify({"status": "received"}), 200

The try/except around the forwarding call is intentional — you always want to return 200 to Anchore regardless of what happens downstream. If your SIEM endpoint is temporarily unavailable, that shouldn’t cause Anchore to retry the notification indefinitely.

This pattern — receive, enrich, transform, forward — is the foundation for connecting Anchore to virtually any downstream system. Swap out forward_to_siem for a function that opens a Jira ticket, posts to a Slack channel, or writes to an S3 bucket, and the rest of the pipeline stays the same.

Up Next

Anchore’s notifications API turns a system you query into a system that talks back. Combined with the SBOM and vulnerability data from the previous post, you have everything you need to build container security workflows that are both deeply informed and fully automated.

Next in the series: Humpty Dumpty — Custom Reporting and GraphQL via the API. Where REST gives you what each endpoint chose to hand back, GraphQL lets you ask for exactly the shape of data you want — “when I use a word,” said Humpty Dumpty, “it means just what I choose it to mean.” We’ll work through Anchore’s embedded GraphQL subsystem and build custom reports against it.

If you’re an Anchore Enterprise customer looking to build with the API, the Customer Success team is the fastest way to get unblocked — reach out through the Anchore Support Portal. If you’re not a customer yet but want to see what any of this looks like against your own container images, request a demo and we’ll walk you through it.

Through the Looking Glass: A Caucus-Race and a Long Tale

This is post 2 in a seven-part series on what the Anchore Enterprise API makes possible for container security teams. 

Who Are You? Why SBOMs Matter

The Caterpillar’s first question to Alice was “Who are you?” — and Alice, who had changed size three times that morning, struggled to answer. When a Critical CVE drops, that’s exactly the question a security team needs to answer about every container image in their fleet: who is in here, at what version, where. Without a reliable inventory, the answer comes from guessing, grepping, or manually inspecting images one at a time. With a complete Software Bill of Materials (SBOM), it becomes a query.

An SBOM is exactly what it sounds like — a complete, structured inventory of every component that makes up a piece of software. For container images, that means every OS package, every language-ecosystem library, every binary, every framework — regardless of how it got there or which layer of the image it lives in. It’s the answer to the Caterpillar’s question, for software.

Beyond vulnerability response, SBOMs underpin license compliance, supply chain attestation, regulatory requirements, and informed conversations with development teams about what they’re actually shipping. The value compounds quickly once you have SBOM data that’s accurate, current, and — critically — accessible programmatically.

Anchore Enterprise generates a detailed SBOM for every container image it analyzes, covering more than 35 package ecosystems. All of that data is available through the API, which means it can flow into whatever workflows, tooling, and processes your organization already relies on.

Retrieving SBOM Content

Like the Mouse’s Long Tale, the list of ecosystems Anchore understands runs on and on — but you query them all through the same shape of request. The /images/{imageDigest}/content endpoint returns the package inventory for an analyzed image, scoped to a single ecosystem at a time. Retrieving OS packages with curl looks like this:

curl -s -u _api_key:
   "https://wonderland.example.com/v2/images/sha256:/content/os" \
   | jq .

Substitute the content type for any of the ecosystems Anchore understands — OS packages, Java, Python, Go, npm, NuGet, Ruby gems, Rust crates, and many more, along with non-package content types like files (a complete file inventory, useful for secret detection and configuration auditing) and malware. A single image digest can yield package data spanning dozens of ecosystems, all queryable through the same endpoint pattern. For the canonical list of supported content types, see the Anchore content-types reference in the official documentation.

Exporting SBOMs in Standard Formats

Alice spent her time in Wonderland trying bottles labelled Drink Me and cakes labelled Eat Me — same Alice, different containers, different effects. Downstream consumers of SBOM data are similar: same image inventory, different format expected. If you need to share SBOM data with external tools, auditors, or downstream systems, Anchore can pour the same SBOM into whichever bottle the asker brought — three industry-standard formats, directly from the API.

SPDX JSON — widely used for license compliance and supply chain documentation:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images/sha256:<digest>/sboms/spdx-json" \
  | jq .

CycloneDX JSON — commonly used for vulnerability exchange and DevSecOps toolchains:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images/sha256:<digest>/sboms/cyclonedx-json" \
  | jq .

Native Anchore JSON — the full internal representation, useful when you want every detail Anchore captured:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images/sha256:<digest>/sboms/native-json" \
  | jq .

Having these available programmatically means generating and delivering a compliance artifact for any image in your fleet is a one-liner — no manual export step required.

License Data

The Queen’s gardeners spent Chapter 8 hastily painting white roses red because they’d planted the wrong colour and an audit was imminent. License compliance is the equivalent in container land — much easier to catch a copyleft component before it ships than to repaint the roses after the fact. Anchore surfaces per-package license information through a dedicated endpoint:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images/sha256:<digest>/content/licenses" \
  | jq .

The response includes each package alongside its identified license or licenses. With that data in hand you can build automated checks for licenses incompatible with your distribution model, flag images that include packages under copyleft licenses, or generate license manifests for your legal and compliance teams — all without manual inspection.

Vulnerability Data

The /images/{imageDigest}/vuln/{vuln_type} endpoint returns vulnerability findings for an analyzed image. To retrieve all vulnerabilities:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images/sha256:<digest>/vuln/all" \
  | jq .

You can narrow the scope by replacing all with os or non-os depending on what you’re interested in. The response includes CVE IDs, severity ratings, affected package names and versions, and fix information where available.

With vulnerability data accessible via the API you can do things the UI isn’t designed for: correlate findings across your entire image fleet, track which vulnerabilities have fixes available and which don’t, filter by severity thresholds, or extract the data into whatever system your security team uses to manage their work.

In Python, pulling Critical and High findings for an image looks like this:

import requests

ANCHORE_URL = "https://wonderland.example.com/v2"
AUTH = ("_api_key", "<your-api-key>")

def get_vulnerabilities(digest, min_severity=("Critical", "High")):
    resp = requests.get(
        f"{ANCHORE_URL}/images/{digest}/vuln/all",
        auth=AUTH,
    )
    resp.raise_for_status()
    vulns = resp.json().get("vulnerabilities", [])
    return [v for v in vulns if v.get("severity") in min_severity]

digest = "sha256:<digest>"
findings = get_vulnerabilities(digest)
for v in findings:
    print(
        f"{v['vuln']} | {v['severity']} | "
        f"{v['package']} {v['package_version']} | "
        f"fix: {v.get('fix', 'none')}"
    )

Policy Evaluation

Vulnerability data tells you what’s present in an image. Policy evaluation tells you whether that image meets your organization’s standards — three possible verdicts (go, warn, or stop), which in the Queen of Hearts’ more direct vocabulary translate to “carry on,” “be careful,” and “off with its head.” The /images/{imageDigest}/check endpoint returns the current policy evaluation result:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images/sha256:<digest>/check?tag=docker.io/wonderland/whiterabbit-api:latest" \
  | jq .

Note that tag is a required parameter — it determines which tag context to use for the policy evaluation. The response is a PolicyEvaluation object containing an evaluations array, each entry of which includes the final_action (go, warn, or stop), the overall status (pass or fail), and a details object with the full list of individual findings.

In Python, checking evaluation status and extracting stop-level findings looks like this:

import requests<br><br>ANCHORE_URL = "https://wonderland.example.com/v2"
AUTH = ("_api_key", "<your-api-key>")

def get_policy_evaluation(digest, tag):
    resp = requests.get(
       f"{ANCHORE_URL}/images/{digest}/check",
        params={"tag": tag, "detail": True},
        auth=AUTH,
    )
    resp.raise_for_status()
    return resp.json()

def parse_evaluation(result):
    tag = result.get("evaluated_tag")
    evaluations = result.get("evaluations", [])
    if not evaluations:
        return tag, None, []
    evaluation = evaluations[0]
    final_action = evaluation.get("final_action")
   findings = evaluation.get("details", {}).get("findings", [])
    stops = [f for f in findings if f.get("action") == "stop"]
    return tag, final_action, stops

digest = "sha256:<digest>"
tag = "docker.io/wonderland/whiterabbit-api:latest"
result = get_policy_evaluation(digest, tag)
tag, final_action, stops = parse_evaluation(result)

print(f"{tag}: {final_action}")
for f in stops:
    print(
        f"  STOP — gate: {f['gate']}, "
        f"trigger: {f['trigger_id']}, "
        f"message: {f['message']}"
    )

Putting It Together: A Caucus-Race Across the Fleet

Lewis Carroll never explains the rules of the Dodo’s Caucus-Race because there aren’t any — the runners just go in a circle until the Dodo decides they’re done, and at the end everyone gets a prize. The script below works on the same principle: it iterates over every image in your fleet, cross-references the package inventory against a watch list of internal libraries, and summarises the vulnerability posture and policy status for each image. One pass through the API, every image accounted for, no one left out.

import requests
from collections import defaultdict

ANCHORE_URL = "https://wonderland.example.com/v2"
AUTH = ("_api_key", "<your-api-key>")
TRACKED_PACKAGES = {"internal-auth-lib", "legacy-crypto-util"}

ECOSYSTEMS = [
    "os", "files", "java", "python", "go", "npm", "nuget", "gem",
    "rust-crate", "hex", "dart-pub", "php-composer", "php-pear", "php-pecl",
    "swift", "pod", "homebrew", "conan", "conda", "terraform",
    "linux-kernel", "linux-kernel-module", "github-action",
    "github-action-workflow", "wordpress-plugin", "lua-rocks",
    "graalvm-native-image", "erlang-otp", "hackage", "r-package",
    "opam", "swiplpack", "bitnami", "binary", "malware",
]

def get_images():
    resp = requests.get(f"{ANCHORE_URL}/images", auth=AUTH)
    resp.raise_for_status()
    return resp.json()

def get_content(digest, content_type):
    resp = requests.get(
        f"{ANCHORE_URL}/images/{digest}/content/{content_type}",
        auth=AUTH,
    )
    resp.raise_for_status()
    return resp.json().get("content", [])

def get_vuln_summary(digest):
    resp = requests.get(
        f"{ANCHORE_URL}/images/{digest}/vuln/all", auth=AUTH
    )
    resp.raise_for_status()
    vulns = resp.json().get("vulnerabilities", [])
    counts = defaultdict(int)
    for v in vulns:
        counts[v.get("severity", "Unknown")] += 1
    return counts

def get_policy_status(digest, tag):
   resp = requests.get(
        f"{ANCHORE_URL}/images/{digest}/check",
        params={"tag": tag},
        auth=AUTH,
    )
    resp.raise_for_status()
    evaluations = resp.json().get("evaluations", [])
    if evaluations:
        return evaluations[0].get("final_action", "unknown")
    return "unknown"

def analyze_image(image):
    digest = image["imageDigest"]
    tag = image["image_detail"][0].get("fulltag", digest[:20])
    flagged = []
    for content_type in ECOSYSTEMS:
        try:
            for pkg in get_content(digest, content_type):
                if pkg.get("package") in TRACKED_PACKAGES:
                    flagged.append(
                        f"{pkg['package']} ({pkg.get('version')})"
                    )
        except requests.HTTPError:
            pass
    vuln_counts = get_vuln_summary(digest)
    policy_status = get_policy_status(digest, tag)
    return tag, flagged, vuln_counts, policy_status

def main():
    for image in get_images():
        tag, flagged, vulns, policy = analyze_image(image)
        print(f"\n{tag}")
        print(f"  Policy:     {policy}")
        print(
            f"  Critical:   {vulns.get('Critical', 0)}  "
            f"High: {vulns.get('High', 0)}  "
            f"Medium: {vulns.get('Medium', 0)}"
        )
        print(f"  Tracked:    {', '.join(flagged) if flagged else '—'}")

if __name__ == "__main__":
    main()

This is the kind of fleet-wide visibility that benefits teams managing container images at scale — knowing not just what’s in each image, but how it’s affected by current vulnerabilities and whether it meets policy, all from a single pass through the API. No winners, no losers, every image accounted for.

Up Next

The Hatter’s table is already set. Next in the series: A Mad Tea-Party — Event-Driven Workflows with Anchore Notifications. We’ll shift from querying SBOM and vulnerability data to reacting to it — configuring webhooks to fire on security events, building receivers that connect Anchore’s event stream to Slack, Jira, or your own internal tooling, and closing the loop between detection and action.

If you’re an Anchore Enterprise customer looking to build with the API, the Customer Success team is the fastest way to get unblocked — reach out through the Anchore Support Portal. If you’re not a customer yet but want to see what any of this looks like against your own container images, request a demo and we’ll walk you through it.

Through the Looking Glass: Down the Rabbit Hole

The UI in Anchore Enterprise gives you a fast, intuitive way to explore scan results, review vulnerabilities, manage policies, and understand the security posture of your container fleet. Think of it as the polished side of the looking glass. But for teams that want to go further — building custom workflows, feeding scan data into other systems, or reacting to security events automatically — the more interesting world is on the other side. That’s where the Anchore Enterprise API comes in.

The API gives you programmatic access to everything the platform knows about your container images: full software bills of materials, vulnerability findings, policy evaluations, and a real-time event stream. That’s the door to integrations and automations uniquely tailored to how your organization works — blocking a deployment the moment a Critical CVE lands in a base image, opening a Jira ticket against the team that owns each affected service, or pinging Slack the instant a fix becomes available for a vulnerability you’ve been tracking.

This post kicks off a seven-part series on what the Anchore Enterprise API makes possible for container security teams. By the end you should be able to look at almost any container security workflow in your organization and see how the API can help you build it.

The Road Ahead

Here’s where the series goes from here. Each post borrows its subtitle from a chapter of Alice in Wonderland:

• A Caucus-Race and a Long Tale — Working with SBOM Data: Retrieving full package inventories across every ecosystem Anchore understands, and building custom cross-image reports with Python.
• A Mad Tea-Party — Event-Driven Workflows with Anchore Notifications: Configuring webhooks to fire on security events and building receivers that connect Anchore to the rest of your toolchain.
• Humpty Dumpty — Custom Reporting and GraphQL: Going beyond REST with Anchore’s embedded GraphQL subsystem to query exactly the data you need in exactly the shape you want.
• Who Stole the Tarts? — Chasing the Cheshire Cat Through Zero-Day Vulnerabilities: Using the /query/vulnerabilities and /query/images/by-package endpoints to rapidly assess blast radius when a new CVE drops.
• Tweedledee and Tweedledum — Comparing Vulnerabilities Across Image Versions: Diffing vulnerability findings between image versions to understand exactly what was fixed — and what wasn’t.
• Queen Alice — Automating Administrative Tasks: Scripting user creation, account management, and permission grants to bring the same automation mindset to platform operations.

Each post stands on its own, so feel free to jump to whichever topic is most relevant to your work. If you’re new to the Anchore API entirely, reading in order will give you a solid foundation before the later posts get into more advanced territory. With the map in hand, let’s get started.

Finding Your Way Around

Before writing a single line of code, it helps to know what’s available. Wonderland is famously short on signposts; Anchore Enterprise comes with one built in. Every deployment serves its own OpenAPI schema at:

https://wonderland.example.com/v2/openapi.json

https://wonderland.example.com/v2/openapi.json

This machine-readable schema is the authoritative reference for every endpoint, request body, and response shape in your specific deployment. You can import it directly into tools like Postman or Insomnia for interactive exploration, or use it to generate a typed client library in your language of choice. It’s also a useful sanity check — if you’re ever unsure whether a field name or path is correct, the schema is the source of truth.

The official Anchore documentation covers the API in depth alongside the rest of the platform, and is a great companion to the hands-on examples in this series.

Authenticating with the API

Alice’s first obstacle in Wonderland was a locked door without a key. Yours is similar. Anchore Enterprise supports both standard username/password authentication and API key authentication. API keys are the recommended approach for any programmatic or production use — they can be rotated and revoked independently of user credentials, making them safer to embed in scripts and automation.

Generating an API Key

API keys can be generated through the UI or via the API. The Anchore documentation covers the UI workflow. To generate one via the API, POST to the API key management endpoint for your account and username:

curl -s -u alice:password \
  -X POST "https://wonderland.example.com/v2/accounts/mad-hatter-team/users/alice/api-keys" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "cheshire-cat",
    "description": "Pipeline automation key"
  }'

Important: API key credentials cannot be used to generate another API key. You must authenticate with your username and password when creating, listing, or deleting API keys.

Keys can also be revoked without deleting them using the PATCH endpoint, which is useful if you suspect a key has been compromised but want to preserve the audit trail:

curl -s -u alice:password \
  -X PATCH "https://wonderland.example.com/v2/accounts/mad-hatter-team/users/alice/api-keys/cheshire-cat" \
  -H "Content-Type: application/json" \
  -d '{"status": "revoked"}'

API Key Limitations

API keys inherit the permissions and roles of the user they were generated for, but there are two categories of operations that cannot be performed using an API key regardless of which user generated it:

• User and credential management — creating, editing, or removing users and their credentials must use username/password authentication.
• API key management — creating, editing, or revoking API keys (including the call to generate a new key shown above) must also use username/password authentication.

For any script or integration that needs to perform these operations, use a dedicated service account with username/password credentials scoped appropriately, and keep those credentials out of your codebase using environment variables or a secrets manager.

Using an API Key

Once you have a key, pass it using standard HTTP basic authentication with the literal string _api_key as the username and your token as the password:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images"

In Python, the same pattern applies:

import requests

AUTH = ("_api_key", "<your-api-key>")

resp = requests.get("https://wonderland.example.com/v2/images", auth=AUTH)

The API as a Platform

What makes the Anchore Enterprise API genuinely powerful isn’t any single endpoint — it’s the fact that it gives you a coherent, queryable representation of your entire container security posture that you can build against. Once you’ve stepped through, there are more rooms here than this series will cover. Here’s a taste of what’s behind the other doors.

Reason about a release, not a pile of images. If you ship a product made up of multiple containers, this is how you answer “what is the security posture of version 2.4 of our platform?” as a single question. The applications API lets you group images into versioned application definitions and retrieve a combined SBOM and unified vulnerability view across every artifact in a given version.

Tell which vulnerable images are actually running in production. It’s the difference between “is this image vulnerable?” and “is this vulnerable image running in production right now?” Anchore Enterprise ingests runtime inventory from Kubernetes and Amazon ECS, giving you API access to a live picture of which container images are deployed in which namespaces and pods across your entire infrastructure — and a way to correlate that with vulnerability data.

Extend the same security workflows to source code. Use one set of policies, queries, and triage workflows across both images and the repositories they’re built from — no new toolchain, no separate concept model. The sources API brings the same SBOM and vulnerability analysis Anchore applies to container images to your source code repositories, with support for Syft-generated SBOMs as an import path.

Get vulnerability findings without leaving an analysis record behind. Ideal for lightweight integrations, throwaway checks, and pre-merge gates where a persistent analysis would be more noise than signal. The /vulnerability-scan endpoint accepts an SBOM and returns vulnerability findings immediately, with nothing stored in the system.

Deliver compliance artifacts on demand, in the format the asker needs. When a customer, auditor, or downstream system asks for a machine-readable SBOM or VEX document, you can generate and deliver it programmatically. Vulnerability findings, SBOMs, and VEX documents all export in industry-standard formats — CycloneDX JSON and XML, SPDX JSON, and OpenVEX — directly from the API.

Push triage decisions and false-positive fixes back into Anchore automatically. When your team accepts a risk, records a remediation, or determines a finding is a CPE-collision false positive, those decisions belong back in Anchore — not stuck in your ticketing system. The API lets you attach annotations to specific vulnerabilities on an image and submit CPE corrections, so the round trip closes without manual UI work.

Whether you’re a security engineer building executive dashboards, a platform team automating promotion gates, or a developer integrating vulnerability data directly into your ticketing system, the API meets you where you are.

Up Next

Next in the series: A Caucus-Race and a Long Tale — Working with SBOM Data. The cleanest way into the API for most teams is the thing Anchore does best — giving you a complete, queryable view of every package across every image you’ve scanned. We’ll walk through retrieving SBOMs, querying across ecosystems, and stitching the results into custom cross-image reports with a small amount of Python.

If you’re an Anchore Enterprise customer looking to build with the API, the Customer Success team is the fastest way to get unblocked — reach out through the Anchore Support Portal. If you’re not a customer yet but want to see what any of this looks like against your own images, request a demo and we’ll walk you through it.