An AI agent can write, test, and ship a production pull request before your compliance team finishes their coffee. It can also pull in a vulnerable dependency, misconfigure a policy, or introduce a supply chain risk nobody catches until an auditor asks for proof six months later.

That’s the collision happening inside most engineering orgs. Agents are active participants in the software supply chain: reading business data, calling APIs, pulling third-party dependencies, and writing code at a volume no human team can manually review. Attackers have noticed too and are using the same tools, with none of the governance constraints slowing them down.

Meanwhile, compliance is still running on last decade’s playbook: screenshots, spreadsheets, and a scramble every Q4 to reconstruct what actually shipped. Josh Bresser, our VP of Security wrote about this shift starting almost a year ago in Navigating the New Compliance Frontier, when we first floated a term for the fix: CompOps.

Our new whitepaper, CompOps: The Modern Blueprint for Continuous Cybersecurity Compliance, lays out what it actually takes to build that fix, and why doing it now, before the next framework lands on your desk, is the difference between compliance as a bottleneck and compliance as leverage.

Who killed the annual audit?

Modern standards don’t wait for year-end anymore. The EU Cyber Resilience Act (CRA), NIST’s Secure Software Development Framework (SSDF), the Product Liability Directive (PLD), and FedRAMP 20x all demand continuous evidence, not a snapshot from last spring. Miss it, and the cost isn’t a slap on the wrist. It’s a blocked market, a stalled deal, or a halted deployment.

Layer GDPR, NIS2, and a half dozen industry-specific frameworks on top, and you get what the whitepaper calls the “spaghetti wiring” problem: every new framework adds another custom script, another spreadsheet column, another siloed GRC tool bolted onto the last one. Eventually engineering teams get scared to ship, because nobody’s sure which overlapping requirement a deployment might quietly violate.

The details compound the pain. The EU CRA requires an SBOM for every release, kept on file for 10 years. FedRAMP 20x expects evidence formatted in OSCAL, a machine-readable standard most GRC spreadsheets have never heard of. None of these requirements were designed to be filled out by hand at scale, and none of them are going away.

The fix: treat compliance like an engineering problem

CompOps applies a DevOps mindset to governance. Instead of wiring a new manual process for every regulation, you plug your security telemetry into one system once, and let Policy-as-Code translate it into whatever format SOC 2, FedRAMP, or the EU CRA demands. The whitepaper calls this the software-defined compliance router, and walks through the five technical pillars that make it real:

• Software Composition Analysis (SCA), which traces every dependency down to the ones developers don’t know they’re shipping
• Vulnerability scanning, correlating that dependency tree against live threat feeds
• The SBOM, standardized in a format like SPDX 3.0, acting as the evidence locker auditors actually trust
• Regulatory Policy-as-Code, which turns legal text into version-controlled, machine-executable rules
• A policy engine, which evaluates it all and returns a deterministic PASS, FAIL, or WARN, no human in the loop required

The whitepaper also walks through where this engine has to plug in: 4 enforcement gates spanning the CI/CD build step, the artifact registry, the deployment admission controller, and continuous runtime monitoring. Catch a violation at any one of them, and the developer gets a deterministic answer in their existing workflow, not a Jira ticket from security three sprints later.

We’ve already shipped pieces of this. Anchore Enterprise 5.26 added HTML compliance reports straight from the CLI, so developers get an audit-ready artifact without ever logging into a GRC tool. And Compliance Operations: Making Kubernetes Audit-Ready by Design shows what continuous evidence looks like when your workloads are as ephemeral as Kubernetes pods.

The business case your board actually wants

This section is for anyone who has to defend a budget line. It reframes compliance from cost center to go-to-market accelerator, with the kind of numbers a VP can repeat in a room: compliance runway for new market entry cut from 12 months to 3, thousands of engineering hours reclaimed from manual review, and compliance coverage scaled 300% without adding headcount.

That last part matters as much as the deadlines. CISOs and platform leads are accountable for proving what shipped, when, and whether an AI agent or a senior engineer wrote the code that got there. CompOps is built to be that backstop either way. And for the security engineers and compliance analysts actually running the pipeline, it means fewer 2am Slack pings asking for a screenshot nobody saved.

What Happens When Your Open Source Maintainer Disappears (EU CRA Edition)

You find a vulnerability in an open source package. You check for a fix. There isn’t one, because the maintainer walked away from the project two years ago. Under the EU Cyber Resilience Act (CRA), what happens next isn’t ambiguous.

That was the question one attendee asked live during our recent webinar with Red Hat and Bitsea, and Roman Zhukov’s answer started with three words: “you own the problem.” What he laid out after that, including the specific options for handling it and where SBOMs fit into catching this before it becomes an incident, is one of the moments worth hearing in his own words in the recording.

It’s also a good preview of the webinar itself. We sat down with Roman Zhukov, Open-Source Security Strategy at Red Hat, and Dr. Andreas Kotulla, Founder & CEO of Bitsea, for “SBOMs or Bust: Automating Compliance for EU CRA and Beyond.” Alex Rybak, our Sr. Director of Product Management, hosted. The conversation covered where the CRA stands today, how a manufacturer the size of Red Hat is operationalizing compliance across eight internal workstreams, and what it actually takes for a mid-sized company to go from zero to CRA-ready.

Where attendees actually stand

Two dates matter more than any others on the CRA calendar: September 11, 2026, when vulnerability reporting obligations kick in, and December 11, 2027, when full compliance is required. We polled the room live, and the results say a lot about how much runway is actually left.

When we asked which regulations were most relevant to their organization, 9 out of 12 respondents named the CRA specifically, alongside NIS2, DORA, PCI DSS, and the EU Product Liability Directive. Nobody in the room is dealing with just one framework.

On compliance progress, 7 of 13 attendees said they’re in the middle of the process, 4 said they’d recently started, and 1 hadn’t started at all. Only one respondent said they’re fully compliant and it’s part of standard operating procedure. That means roughly 92% of the room is still actively working through it.

We also asked which vulnerability data source they trust most. NVD (the U.S. National Vulnerability Database) led with 5 of 12 votes, followed by CISA KEV with 3 and the EU Vulnerability Database (EUVD) with 2. One respondent told us they use a combination of NVD and vendor data because “our customers tend to use NVD most.”

Red Hat’s case for treating this as a program, not a project

Roman walked through how Red Hat structured its CRA response around three roles it plays at once: manufacturer, open source steward for projects like Fedora and Ansible, and upstream contributor. That triple role shaped an 8-workstream program spanning awareness, vulnerability management, conformity assessment, data collection, and legal, built roughly a year and a half ago.

His core point was one worth repeating to your own leadership: CRA compliance can’t sit with a single department, because it touches roadmaps, security, legal, and open source strategy all at once. He also flagged something we don’t hear often enough: early drafts of the CRA risked real harm to the open source ecosystem before industry input helped shape the final requirements.

Bitsea’s five-step path, and the timeline nobody wants to hear

Andreas walked through the five-step framework Bitsea built from the EU-funded OCTET project, starting with a free assessment to determine whether the CRA even applies to your product. From there it moves into gap analysis, SBOM generation, documentation, and ongoing risk monitoring.

The honest answer on timeline: when Alex asked what a mid-sized company should budget to go from step one to full compliance, Andreas didn’t sugarcoat it. We’ll let you hear the exact number he gave in the recording, but the software composition analysis step alone is the long pole.

Unified SBOM management to ease manual vulnerability management

Alex covered how Anchore Enterprise v6, which we announced earlier this month, helps teams generate unified SBOMs and VEX documents across application versions so security teams aren’t chasing every vulnerability manually. He also pointed attendees to Syft and Grype, our open source SBOM generator and vulnerability scanner, which together have over 50 million downloads.

Watch the full session

We covered a lot more than we can fit here: the full CRA timeline and product classification rules, Red Hat’s approach to continuous compliance without adding overhead, and the complete Q&A with both partners. If you’re one of the 92% still working through your CRA journey, this is 45 minutes worth blocking off.

Watch the on-demand webinar

Further resources

The EU CRA demands a shift from static security reports to continuous Live Telemetry. Learn how to operationalize compliance, enforce deterministic policy gates, and automate your path to an audit-ready software supply chain.

Download Now

On September 11, 2026, the EU Cyber Resilience Act’s (CRA) 24-hour vulnerability reporting requirement takes effect. If your software is sold in the European market and you don’t have automated detection and alerting in place before then, you’re already behind.

The penalty for non-compliance isn’t abstract: fines up to €15 million or 2.5% of global annual turnover, and the authority for national regulators to pull your products from the EU market entirely. The December 11, 2027 deadline for full Secure-by-Design and SBOM mandates will follow quickly after.

Most teams aren’t starting from zero; they have scanners, pipelines, and vulnerability management in place. But what most organizations are missing is the architecture to meet a 24-hour reporting window at scale: CISA KEV feed integration, automated alerting hooks, pre-drafted notification templates, and a centralized SBOM inventory that answers “are we affected?” in minutes, not days.

We built two handy resources to get you better prepared: 

The EU CRA Software Supply Chain Compliance Checklist 

This is a phased execution guide for Engineering, SecOps, and GRC teams. 

It breaks CRA requirements into two priority tracks: 

1. the six capabilities you need before September 11, 2026, 
2. and the SBOM, lifecycle monitoring, and Secure-by-Design controls required by December 2027.

Each phase maps directly to the relevant CRA annex and article, so your team knows exactly what they’re building toward and your GRC lead knows what to document. If you are a hands on, this is where you want to start. 

Navigating the EU Cyber Resilience Act: A Blueprint for Secure Software Supply Chains 

This resource goes deeper than the checklist. It explains the three-tier compliance structure (Tier 0 self-assessment through Tier 2 mandatory external audits), why point-in-time compliance doesn’t satisfy CRA’s continuous monitoring requirements, and how CompOps is the only architecture that scales. 

It also covers what happens when you submit a false Declaration of Conformity: maximum fines and immediate product recall across the EU.

Download the White Paper: Navigating the EU CRA →

Learn how to operationalize compliance, enforce deterministic policy gates, and automate your path to an audit-ready software supply chain.

Download Now

By Devashri Datta – Independent Researcher, Software Supply Chain Security

In modern container security, most teams have already solved the visibility problem. SBOMs can be generated automatically during builds, vulnerabilities are mapped to components, and results are fed into CI/CD systems. Yet despite this progress, teams still struggle with a more practical challenge: how to consistently turn that data into clear, defensible decisions.

This issue becomes more pronounced at scale. Containerized environments reuse base images across services, inherit vulnerabilities across layers, and generate large volumes of findings that are difficult to prioritize. As a result, engineering teams are often forced to choose between slowing delivery to address noise or accepting risk without sufficient context. The core problem is no longer about identifying vulnerabilities, but about determining which ones actually matter in a given runtime scenario.

Why Severity Alone Fails in Container Workflows

Most container security pipelines still rely on severity-driven controls. Images are scanned, vulnerabilities are ranked by CVSS scores, and thresholds are used to decide whether builds should pass or fail. While this approach is simple to automate, it does not hold up well in practice.

Severity scores lack awareness of how software is actually used. A critical vulnerability may exist in a component that is never invoked, while a lower-severity issue may sit directly in an exposed execution path. In containerized systems, where deployment context varies widely across environments, this disconnect becomes even more visible. Teams end up reacting to scores instead of risk, leading to unnecessary disruptions on one end and blind spots on the other.

Reframing SBOMs as Operational Data

SBOMs are often treated as static artifacts produced for compliance or inventory purposes. They can serve as a much more powerful operational input when used continuously across the pipeline.

When treated as a living dataset rather than a report, SBOMs help teams understand how components propagate across images, how vulnerabilities are inherited from shared layers, and where dependencies actually influence runtime behavior. This shift allows organizations to move beyond isolated scan results and toward a more connected view of risk across workloads.

However, SBOMs alone still stop short of answering the most important question, whether a vulnerability is actually exploitable in a specific context.

Introducing VEX into the Pipeline

This is where VEX becomes meaningful. Rather than introducing new vulnerability data, VEX adds interpretive context, indicating whether a known issue is exploitable under specific conditions.

In container environments, this context can reflect several realities. A vulnerable function may not be invoked, a component may be present but isolated, or configuration choices may prevent exploitation entirely. Without this layer of understanding, all vulnerabilities appear equally actionable, which leads to inefficient prioritization.

The real value of VEX emerges when it is evaluated alongside SBOM data at the exact points where decisions are made, rather than being stored as separate metadata.

Bridging VEX and Policy: The Role of an Interpretation Layer

VEX provides the exploitability signal, but operationalizing that signal consistently across heterogeneous pipelines requires a structured intermediary. The Safety Relevance Interpretation Layer (SRIL) addresses this gap by defining how VEX assertions, SBOM component data, and deployment context are normalized and translated into policy-actionable outputs.

Rather than leaving each team to define its own logic for consuming VEX statements, SRIL establishes a repeatable preprocessing step: ingesting raw VEX and SBOM inputs, applying domain-weighted safety relevance scoring, and emitting a structured output that downstream policy engines can evaluate uniformly. This is particularly valuable in container environments where the same base image may be deployed across safety-critical and non-safety-critical workloads simultaneously, requiring different policy responses to the same underlying vulnerability.

Without this layer, VEX adoption tends to remain ad hoc, effective in isolated implementations but difficult to standardize at enterprise scale.

Where VEX Improves Real-World Workflows

In practice, VEX integration does not require a complete redesign of existing pipelines. Its impact is most visible when applied incrementally at key stages.

During image analysis, VEX helps reduce noise early by identifying vulnerabilities that are not applicable or not exploitable. This prevents unnecessary findings from reaching developers and improves the overall signal quality of scans.

At the policy stage, VEX enables more nuanced gating decisions. Instead of relying solely on severity thresholds, teams can incorporate exploitability and deployment context into their rules. This leads to fewer false build failures and more targeted enforcement.

Post-deployment, VEX supports continuous re-evaluation. As new vulnerabilities are disclosed or configurations change, previously assessed risks can be revisited without requiring full rebuild cycles. This is particularly valuable for long-lived containers and widely reused base images.

Operational Considerations for Adoption

Making this approach work requires consistency more than complexity. SBOM, vulnerability, and VEX data must align across systems so that decisions remain coherent throughout the pipeline. Without this alignment, teams risk creating fragmented interpretations of the same issue.

Equally important is the use of policy as code. Decisions should be encoded into pipelines and enforcement points rather than left to manual judgment. This ensures that outcomes are repeatable and can scale with the environment.

Finally, decision traceability plays a critical role. Organizations need to retain not just the outcome of a decision, but the reasoning behind it—linking vulnerability data, exploitability context, and policy logic into a clear and auditable record.

Enabling Practical Implementation 

Organizations like Anchore support this model by treating SBOMs as queryable, persistent artifacts that can be evaluated across the software lifecycle. By integrating vulnerability analysis with policy enforcement, they provide natural points where VEX data can influence decisions without disrupting existing workflows.

This approach allows teams to move away from manual exception handling and toward consistent, policy-driven decisioning that reflects actual runtime risk rather than abstract severity scores.

Moving Toward Decision-Centric Security

Container security has matured significantly in its ability to generate and aggregate data. The next step is improving how that data is used. VEX plays a key role in this transition by reducing ambiguity and enabling more precise interpretations of vulnerability impact.

When combined with SBOM-driven workflows and enforced through policy, it helps organizations focus on what truly matters, addressing exploitable risk while maintaining delivery velocity. In high-scale environments, this shift is not just beneficial but necessary to keep security aligned with real-world conditions.

Conclusion

SBOMs have already changed how organizations understand what is inside their container environments. The next step is improving how that information is used to make decisions.

By incorporating VEX into existing SBOM-driven workflows, teams can move beyond generic severity-based prioritization and begin evaluating vulnerabilities in the context that actually matters: how software is built, deployed, and run.

This shift does not require replacing existing tools or pipelines. It requires using the data already available in a more structured and intentional way, where exploitability and context directly influence policy decisions.

For teams operating at scale, the benefit is immediate: fewer unnecessary disruptions, clearer prioritization, and decisions that remain defensible over time.

Author Bio

Devashri Datta is a security researcher and enterprise security architect specializing in AI-driven software supply chain security, DevSecOps automation, and lifecycle-based security governance frameworks. Research spans vulnerability intelligence (VEX), SBOM governance, Third Party Notice (TPN) compliance systems, AI-assisted risk modeling, and shadow risk governance for enterprise security exception management.

Through the Looking Glass: Queen Alice

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

By the final chapter of Through the Looking-Glass, Alice has crossed the entire chessboard, reached the eighth square, and been crowned. She has gone from a bewildered visitor to a Queen — someone who understands the rules of Wonderland well enough to command them. That’s the right frame for where we’ve arrived in this series. We’ve explored SBOM data, built event-driven pipelines, queried across the fleet with GraphQL, investigated zero-day blast radius, and diffed vulnerability profiles between container image versions. What remains is the layer underneath all of that: the platform itself.

Account creation, user provisioning, permission grants, registry configuration — these are the administrative tasks that typically live in a runbook or get performed manually through the UI when onboarding a new team or environment. Every one of them is available through the API, which means they can be scripted, version-controlled, and integrated into whatever infrastructure automation your organization already relies on. The kingdom runs better when the Queen doesn’t have to sign every scroll by hand.

Drawing the Borders: Account Management

In Anchore Enterprise, accounts provide the top-level isolation boundary — separate teams, environments, or tenants each get their own account with their own container images, policies, and users. They’re the territories on the chessboard. Creating one via the API is a single call, available only to admin users:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/accounts" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "mad-hatter-team",
    "email": "[email protected]"
  }'

Accounts can be enabled or disabled independently of deletion — useful for temporarily suspending access without losing configuration:

curl -s -u _api_key:<your-api-key> \
  -X PUT "https://wonderland.example.com/v2/accounts/mad-hatter-team/state" \
  -H "Content-Type: application/json" \
  -d '{"state": "disabled"}'

Deleting an account requires it to be in a disabled state first — a safeguard against accidental removal of active resources:

# Disable first
curl -s -u _api_key:<your-api-key> \
  -X PUT "https://wonderland.example.com/v2/accounts/mad-hatter-team/state" \
  -H "Content-Type: application/json" \
  -d '{"state": "disabled"}'

# Then delete
curl -s -u _api_key:<your-api-key> \
  -X DELETE "https://wonderland.example.com/v2/accounts/mad-hatter-team"

Calling the Court Together: User Management

An account without users is a kingdom without subjects. Users are created within an account context, and because user and credential management cannot be performed with API key authentication, these calls must use username/password credentials:

curl -s -u admin:password \
  -X POST "https://wonderland.example.com/v2/accounts/mad-hatter-team/users" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "alice",
    "password": "changeme123",
    "user_type": "native"
  }'

For production use, users should authenticate with API keys rather than passwords. As covered in the first post in this series, API keys are created per user and use the _api_key username convention — and importantly, must be created using username/password credentials, not an existing API key.

Three Cheers for Queen Alice: Granting Roles with RBAC

At Alice’s coronation feast, the Red Queen and White Queen tested whether she deserved her crown. Anchore RBAC is the reverse — once you have the authority, you decide who gets what title. Creating a user doesn’t grant them any access on its own; permissions in Anchore Enterprise are managed through RBAC roles. To see the full list of available roles in your deployment:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/rbac-manager/roles" \
  | jq '.[].name'

To grant a user a role within a specific account, POST to the role’s members endpoint with the username and the account as the domain_name:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/rbac-manager/roles/full-control/members" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "alice",
    "domain_name": "mad-hatter-team"
  }'

Roles can be revoked just as easily:

curl -s -u _api_key:<your-api-key> \
  -X DELETE "https://wonderland.example.com/v2/rbac-manager/roles/full-control/members?username=alice&domain_name=mad-hatter-team"

Opening the Gates: Registry Configuration

For Anchore to analyze container images from private registries, the gates have to be opened — the registry needs to be configured with the appropriate credentials. This too is fully API-driven:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/registries" \
  -H "Content-Type: application/json" \
  -H "x-anchore-account: mad-hatter-team" \
  -d '{
    "registry": "registry.wonderland.example.com:5000",
    "registry_name": "internal-registry",
    "registry_user": "anchore-svc",
    "registry_pass": "s3cr3t",
    "registry_verify": true
  }'

The x-anchore-account header scopes the registry to the target account — each account manages its own registry credentials independently.

Decreeing the Laws: System Configuration

A queen sets the rules of the kingdom. Anchore Enterprise exposes a set of platform-level configuration settings through the API — things that affect system-wide behavior rather than individual accounts or users. These settings are viewable and updatable without requiring a config file change or service restart in many cases, making them well-suited for automation.

To see everything that’s configurable along with current values, descriptions, and whether a restart is required to apply a change:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/system/configurations" \
  | jq '.items[] | {key: .key, value: .value, requires_restart: .requires_system_restart, description: .description}'

The full schema for all configurable settings — including valid values, types, and constraints — is available at a dedicated endpoint, useful for tooling that needs to validate inputs before applying them:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/system/configurations/schema" \
  | jq .

To read the current value of a specific configuration key:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/system/configurations/<config_key>" \
  | jq .

To update a single setting:

curl -s -u _api_key:<your-api-key> \
  -X PUT "https://wonderland.example.com/v2/system/configurations/<config_key>" \
  -H "Content-Type: application/json" \
  -d '{"key": "<config_key>", "value": "<new_value>"}'

To update multiple settings atomically in a single call — if any key fails validation, none are applied:

curl -s -u _api_key:<your-api-key> \
  -X PATCH "https://wonderland.example.com/v2/system/configurations" \
  -H "Content-Type: application/json" \
  -d '[
    {"key": "<config_key_1>", "value": "<value_1>"},
    {"key": "<config_key_2>", "value": "<value_2>"}
  ]'

To reset a setting back to its system default:

curl -s -u _api_key:<your-api-key> \
  -X DELETE "https://wonderland.example.com/v2/system/configurations/<config_key>"

Each configuration response includes a requires_system_restart field — worth checking before applying changes in a production environment, as some settings only take effect after the relevant service is restarted. The source field on each setting tells you where the current value originated: default, api, or config_file — useful for understanding whether a setting has been previously overridden and by what mechanism.

The Royal Proclamation: Team Provisioning Script

The real value of administrative automation is composing these operations into a repeatable provisioning workflow — one proclamation that calls a whole new team into being. The script below accepts a team name and a list of users, and handles the full onboarding sequence: account creation, user creation, role assignment, and registry configuration:

import requests

ANCHORE_URL = "https://wonderland.example.com/v2"

# admin API key for account, RBAC, and registry operations
AUTH = ("_api_key", "<your-admin-api-key>")

# username/password required for user + credential operations
USER_MGMT_AUTH = ("admin", "<your-admin-password>")

def create_account(name, email=None):
    body = {"name": name}
    if email:
        body["email"] = email
    resp = requests.post(
        f"{ANCHORE_URL}/accounts", json=body, auth=AUTH
    )
    resp.raise_for_status()
    print(f"  Created account: {name}")
    return resp.json()

def create_user(account, username, password, user_type="native"):
    resp = requests.post(
        f"{ANCHORE_URL}/accounts/{account}/users",
        json={
            "username": username,
            "password": password,
            "user_type": user_type,
        },
        auth=USER_MGMT_AUTH,  # API keys cannot manage users or credentials
    )
    resp.raise_for_status()
    print(f"  Created user: {username} in {account}")

def grant_role(username, account, role="full-control"):
    resp = requests.post(
        f"{ANCHORE_URL}/rbac-manager/roles/{role}/members",
        json={"username": username, "domain_name": account},
        auth=AUTH,
    )
    resp.raise_for_status()
    print(f"  Granted role '{role}' to {username} in {account}")

def add_registry(account, registry, user, password, verify_ssl=True):
    resp = requests.post(
        f"{ANCHORE_URL}/registries",
        json={
            "registry": registry,
            "registry_user": user,
            "registry_pass": password,
            "registry_verify": verify_ssl,
        },
        auth=AUTH,
        headers={"x-anchore-account": account},
    )
    resp.raise_for_status()
    print(f"  Configured registry: {registry} for {account}")

def provision_team(account_name, users, registry=None):
    print(f"\nProvisioning account: {account_name}")
    create_account(account_name)
    for user in users:
        create_user(account_name, user["username"], user["password"])
        grant_role(
            user["username"],
            account_name,
            user.get("role", "read-only"),
        )
    if registry:
        add_registry(
            account_name,
            registry["host"],
            registry["user"],
            registry["password"],
        )
    print(f"\nDone. Account '{account_name}' is ready.\n")

if __name__ == "__main__":
    provision_team(
        account_name="mad-hatter-team",
        users=[
            {
                "username": "alice",
                "password": "changeme123",
                "role": "full-control",
            },
            {
                "username": "hatter",
                "password": "changeme456",
                "role": "read-only",
            },
        ],
        registry={
            "host": "registry.wonderland.example.com:5000",
            "user": "anchore-svc",
            "password": "s3cr3t",
        },
    )

This kind of script slots naturally into an infrastructure-as-code workflow — driven by a configuration file, triggered by a CI pipeline, or invoked as part of a larger onboarding automation. The operations are idempotent enough to be re-run safely with appropriate error handling, and the entire provisioning history becomes auditable through your version control system rather than buried in UI click trails.

End of the Looking-Glass Country

Alice begins Through the Looking-Glass as a confused visitor and ends it as a Queen presiding over the chessboard she once didn’t understand. The arc of this series is meant to be similar. We’ve worked through the structure of the API, the data it surfaces, the events it emits, the questions you can ask of it, and now the platform itself. What you do with all of that is finally up to you.

The thread running through all seven posts is the same: Anchore Enterprise exposes a comprehensive, well-structured API, and the container security teams that get the most out of it are the ones who treat it as a platform to build on rather than a UI to click through. The examples in this series are starting points. Your environment, your tooling, and your workflows will take them somewhere specific to you.

Thanks for reading. 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.

As a Solution Architect here at Anchore, I spend a lot of time talking with defense contractors and organizations responsible for managing Controlled Unclassified Information (CUI). Lately, almost every conversation eventually turns to one looming topic: the reality of CMMC (Cybersecurity Maturity Model Certification) audits and compliance requirements..

The DoD’s CMMC 2.0 final rule officially took effect in November 2025, and what we are seeing in the field right now is both curiosity and anxiety for assessment preparedness. Phase 1 self-assessments are already here, but the real wake-up call is Phase 2, which kicks off on November 10, 2026. In just a few months, Level 2 contractors will face mandatory, third-party C3PAO audits to win or renew DoW contracts. 

Many customers assume that simply moving their environments to FedRAMP-authorized cloud services will check the compliance box. It doesn’t, because it is just one part of the story. When it comes to your internal software development lifecycle, specifically securing container images and maintaining a rigorous software inventory, the burden of proof still falls heavily on your engineering and security teams.

For many prospects and customers, maintaining evidence for CMMC audits in regards to their SBOMs and container images is very burdensome. Chasing down vulnerabilities and cross-referencing data doesn’t scale.

We knew our customers needed a better way. They needed to stop treating CMMC compliance as a manual bottleneck and start treating it as an automated, everyday part of their CI/CD pipeline. That’s exactly why we built the Anchore Enterprise CMMC Policy Pack.

Automating the Complexities of CMMC 2.0 and NIST 800-171 

As CMMC 2.0 rolls out, organizations have to understand exactly where they fall. While Level 1 handles basic federal contract information, dealing with CUI puts most of our customers firmly in the crosshairs of Level 2 , which maps directly to the stringent NIST SP 800-171 framework. 

Securing internal network production environments to these standards requires strict adherence. Rather than asking teams to manually audit their Software Bills of Materials (SBOMs) and container images against these sprawling requirements, we designed the CMMC Policy Pack (available via the Enforce module) to automatically map our policy checks directly to those specific CMMC and NIST controls.

Here is how we help customers automate those technical controls directly out of the box:

Fighting Container Drift in Your Base Images

One of the most common pitfalls I see with defense contractors is assuming that if an image passes a scan on Tuesday, it’s compliant on Friday. In the world of containers, container drift is a massive compliance risk. Your base images might be perfectly hardened when you build them, but as new vulnerabilities are discovered or unauthorized changes are made in production, that secure baseline “drifts” out of compliance.

To ensure technical controls don’t just exist on paper but are actively maintained despite container drift, we see our most successful customers implementing an automated workflow:

1. Image & SBOM Analysis: As soon as the build completes, the container image and SBOM are analyzed to generate a definitive list of all the software packages.
2. Vulnerability Scanning: The SBOM is assessed against CVE databases and GitHub Security Advisories for the most accurate and data rich experience. 
3. Policy Evaluation: The CMMC Policy Pack evaluates the image against predefined rules using regulatory guidance and can be modified to add a company’s specific risk posture.
4. Governance Gate: Images that fail the CMMC policy check are automatically blocked from promotion to production registries. No manual intervention required.
5. Continuous Audit: Existing images in the internal network are continuously monitored to ensure they remain compliant the moment new threat intelligence emerges.

Generating Evidence for Your C3PAO Audit

When your November audit requirements roll around, having accessible evidence is critical. Data is stored in perpetuity by default in Anchore Enterprise, where evidence is maintained for both vulnerabilities and policy compliance. Because all images are continuously monitored for vulnerabilities, auditors can clearly see policy analysis in action right within the platform. 

Here is how Anchore Enterprise captures and displays this crucial audit evidence:

1. Vulnerability Analysis 

All images are continuously monitored for vulnerabilities.

2. Policy Analysis in Action
   

The system generates “WARN” actions for discovered vulnerabilities and “STOP” actions for critical violations, such as an effective user running with root permissions or a missing Dockerfile. As indicated in the image below, the image was issued a “STOP” action because the effective user was running with root permissions and a Dockerfile was not provided. The “WARN” actions shown are due to the vulnerabilities that were discovered. 

3. Software Inventory
   A core component of this evidence is the SBOM. An SBOM is a formal, machine-readable inventory of all the components, libraries, and dependencies that make up a software application or container image.

What’s Next

With the Phase 2 deadline right around the corner, organizations leveraging Anchore Enterprise for CMMC compliance are shifting from a reactive panic to a proactive security model. By building compliance natively into your policy-as-code, producing artifacts simply becomes an inherent part of the development lifecycle rather than a reactive roadblock.

This means that by the time an image is promoted to production or delivered to your DoD customer, you already know it complies with CMMC policies, meets your operational risk tolerance, and has a clear, easily exportable paper trail ready for your C3PAO auditor.

If you want to see how this looks in your own environment before the November 2026 deadline hits, or for more information on automating your compliance workflow, check out anchore.com.

A detailed guide mapping automated container inspections directly to DoW RMF and NIST security controls.

Download Now

Through the Looking Glass: Tweedledee and Tweedledum

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

Tweedledee and Tweedledum stood under their tree looking nearly identical — same coat, same posture, same expression — and Alice could only tell them apart by the collars embroidered DUM and DEE. Two consecutive versions of a container image look the same way at first glance. Same name, same base, similar contents — but not quite the same. The difference between whiterabbit-api:1.0 and whiterabbit-api:1.1 might be a handful of updated packages, a changed dependency, or a patched OS layer.

From a security standpoint, what matters is what changed in the vulnerability profile: what got fixed, what got introduced, and what persisted unchanged. Anchore Enterprise has a built-in image-comparison capability for separating vulnerabilities inherited from a parent image, and supports versioning applications for future comparison — but for a single image, version-to-version isn’t something the UI is designed to surface directly. The API makes it straightforward: with two vulnerability queries and some set operations in Python, you can answer “what did this release actually fix?” with precision.

Reading the Collars: Looking Up Image Digests by Tag

Alice had to look at the embroidered collars to keep DUM and DEE straight. Container images are identified the same way: the tag is the collar; the digest is the actual identity underneath. Before comparing vulnerability data, you need the digest for each image version. The /v2/images endpoint accepts a full_tag query parameter for exactly this:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images?full_tag=docker.io/wonderland/whiterabbit-api:1.0" \
  | jq '.[0].imageDigest'

Repeat for the second version:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/images?full_tag=docker.io/wonderland/whiterabbit-api:1.1" \
  | jq '.[0].imageDigest'

With both digests in hand, you can query the vulnerability data for each.

Asking Each Twin What They Know: Fetching Vulnerability Data

The vulnerability endpoint is the same one we’ve used throughout this series. Ask each twin in turn:

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

Run this for both digests and you have everything you need to diff.

Contrariwise: The Version Diff Script

“Contrariwise,” Tweedledee insisted whenever something needed to be looked at from the other side. A version diff is the same exercise: from one side, what got fixed; from the other, what got introduced; and from the middle, what stuck around in both. The script below takes two image tags, resolves their digests, fetches their vulnerability data, and produces a structured diff — vulnerabilities that were fixed between versions, vulnerabilities that were newly introduced, and those that persist in both:

import sys
import requests

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

def get_digest_for_tag(full_tag):
    resp = requests.get(
        f"{ANCHORE_URL}/images",
        params={"full_tag": full_tag},
        auth=AUTH,
    )
    resp.raise_for_status()
    images = resp.json()
    if not images:
        raise ValueError(f"No image found for tag: {full_tag}")
    return images[0]["imageDigest"]

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

def diff_vulnerabilities(tag_a, tag_b):
    print("Resolving digests...")
    digest_a = get_digest_for_tag(tag_a)
    digest_b = get_digest_for_tag(tag_b)
    print(f"  {tag_a}: {digest_a[:20]}...")
    print(f"  {tag_b}: {digest_b[:20]}...")

    print("\nFetching vulnerability data...")
    vulns_a = get_vulnerabilities(digest_a)
    vulns_b = get_vulnerabilities(digest_b)

    ids_a = set(vulns_a.keys())
    ids_b = set(vulns_b.keys())

    fixed = ids_a - ids_b
    introduced = ids_b - ids_a
    persisting = ids_a & ids_b

    print(f"\nVulnerability diff: {tag_a} → {tag_b}")
    print(f"  Fixed:      {len(fixed)}")
    print(f"  Introduced: {len(introduced)}")
    print(f"  Persisting: {len(persisting)}")

    if fixed:
        print(f"\nFixed in {tag_b}:")
        for vuln_id in sorted(fixed):
            v = vulns_a[vuln_id]
            print(
                f"  {vuln_id} [{v.get('severity')}] "
                f"— {v.get('package')} {v.get('package_version')}"
            )

    if introduced:
        print(f"\nIntroduced in {tag_b}:")
        for vuln_id in sorted(introduced):
            v = vulns_b[vuln_id]
            print(
                f"  {vuln_id} [{v.get('severity')}] "
                f"— {v.get('package')} {v.get('package_version')}"
            )

    if persisting:
        print("\nPersisting in both:")
        for vuln_id in sorted(persisting):
            v = vulns_b[vuln_id]
            fix = v.get("fix")
            fix_str = (
                f" (fix available: {fix})"
                if fix and fix != "None"
                else ""
            )
            print(
                f"  {vuln_id} [{v.get('severity')}] "
                f"— {v.get('package')} {v.get('package_version')}"
                f"{fix_str}"
            )

if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("Usage: python3 diff.py <tag_a> <tag_b>")
        print(
            "  e.g: python3 diff.py "
            "docker.io/wonderland/whiterabbit-api:1.0 "
            "docker.io/wonderland/whiterabbit-api:1.1"
        )
        sys.exit(1)
    diff_vulnerabilities(sys.argv[1], sys.argv[2])

Running it produces output like:

Resolving digests...
  docker.io/wonderland/whiterabbit-api:1.0: sha256:3a1f2e8dc4...
  docker.io/wonderland/whiterabbit-api:1.1: sha256:9b7c4f1ae2...

Fetching vulnerability data...

Vulnerability diff: docker.io/wonderland/whiterabbit-api:1.0 → docker.io/wonderland/whiterabbit-api:1.1
  Fixed:      12
  Introduced:  2
  Persisting: 34

Fixed in docker.io/wonderland/whiterabbit-api:1.1:
  CVE-2023-1234 [High] — libssl 1.1.1n-0+deb11u4
  CVE-2023-5678 [Critical] — zlib1g 1:1.2.11.dfsg-2
  ...

Introduced in docker.io/wonderland/whiterabbit-api:1.1:
  CVE-2024-0001 [Medium] — curl 7.88.1-10+deb12u4
  ...

Persisting in both:
  CVE-2022-9876 [High] — openssl 3.0.2-0ubuntu1 (fix available: 3.0.2-0ubuntu1.10)
  ...

The persisting section is particularly actionable — vulnerabilities that survived the update and have a fix available are exactly what should feed back into the next release cycle. The broken rattle from Carroll’s chapter is the right reference: every quarrel needs to end with somebody picking up the pieces.

What’s Worth a Battle: Filtering by Severity

Tweedledee and Tweedledum agreed to fight over a rattle and then immediately called it off when a monstrous crow appeared overhead — proportion matters. For release validation or compliance documentation, you may only care about the diff at specific severity levels. The script can be extended with a severity filter before the diff output:

SEVERITY_FILTER = {"Critical", "High"}

fixed_filtered = {
    k for k in fixed
    if vulns_a[k].get("severity") in SEVERITY_FILTER
}
introduced_filtered = {
    k for k in introduced
    if vulns_b[k].get("severity") in SEVERITY_FILTER
}

This keeps the full diff logic intact while surfacing only the findings that matter for your use case.

Up Next

A version diff turns a vulnerability scan from a point-in-time snapshot into a meaningful measure of progress. “We fixed 12 vulnerabilities in this release, introduced 2, and still have 34 to address — 8 of which now have fixes available” is a far more useful statement than a raw count. It also gives development teams a clear, honest picture of where things stand without requiring anyone to manually compare two scan results.

Final post in the series: Queen Alice — Automating Administrative Tasks via the API. Alice ends Through the Looking-Glass by being crowned and presiding over a chessboard’s worth of new responsibilities. We’ll turn from analysis to operations and use the API to handle the queenly tasks of running an Anchore deployment — creating users, managing accounts, granting permissions, and keeping the whole thing tidy.

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: Who Stole the Tarts? — Chasing the Cheshire Cat

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

“Well! I’ve often seen a cat without a grin,” thought Alice, “but a grin without a cat! It’s the most curious thing I ever saw in all my life!” A zero-day vulnerability has the same trick. It appears everywhere at once, sometimes leaving nothing behind but a CVE ID — a grin — long after the package itself has been patched, repackaged, or nested two JARs deep inside another dependency. Take Log4Shell: log4j-core turned up in container images nobody knew were running Java at all, and kept turning up for months.

When a new CVE drops, the first question is always the same: are we affected, and if so, where? Answering that manually — clicking through images one at a time, running ad hoc scans, waiting for analysts to compile results — is exactly the wrong approach when the clock is running. The query endpoints in Anchore Enterprise are designed for this moment. With two API calls and a small amount of Python, you can go from a CVE ID to a complete picture of your container fleet’s exposure.

Two Trails to the Cat: The Endpoints

Two endpoints do the heavy lifting for zero-day investigation. The first tells you what the Cat looks like; the second tells you where it’s been spotted.

/v2/query/vulnerabilities — Given one or more CVE IDs, this returns everything Anchore knows about the vulnerability: severity, affected packages and versions, fix availability, NVD and vendor data, and references. This is where you start — understand what the vulnerability actually affects before you go looking for it.

/v2/query/images/by-package — Given a package name (and optionally a type and version), this returns every container image in your fleet that contains that package. Cross-reference this with the affected packages from the first query and you have your blast radius.

Spotting the Cat: Query the CVE

Before you can chase something, you have to know what you’re chasing. The /query/vulnerabilities endpoint accepts one or more CVE IDs and returns the full vulnerability record for each:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/query/vulnerabilities?id=CVE-2021-44228" \
  | jq .

You can query multiple CVEs in a single call — useful when a vulnerability has related follow-on IDs (Log4Shell’s grin reappeared as CVE-2021-45046 a few days after the original disclosure):

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/query/vulnerabilities?id=CVE-2021-44228&id=CVE-2021-45046" \
  | jq .

The response includes the severity rating, a list of affected packages with the vulnerable version ranges, fix availability, NVD and vendor CVSS scores, and external references. The affected_packages array is what you’ll use to drive the next step — each entry gives you a package name, type, and version to search for.

Where Has It Been Seen? Find Affected Images

With the affected package details in hand, ask Anchore where the package has shown up across your fleet:

curl -s -u _api_key:<your-api-key> \
  "https://wonderland.example.com/v2/query/images/by-package?name=log4j-core&package_type=java" \
  | jq .

The name parameter is required. package_type and version are optional but useful for narrowing results when a package name is common across multiple ecosystems. The response returns a paginated list of images, each with the matching package details and the image’s tag history — every place the Cat has been seen, and under what name.

The Knave’s Defence: Understanding will_not_fix

At the trial of the Knave of Hearts, the Knave’s defence was simple: he hadn’t written the letter, his name wasn’t on it, and the whole thing was somebody else’s mess. Distro vendors sometimes file the same kind of plea, and the API reports it back to you as will_not_fix.

When will_not_fix is true on an affected package, the vendor of the image’s OS distribution has assessed the vulnerability and either disagrees with the upstream severity rating or has explicitly indicated they do not intend to ship a fix. This is common with distro-specific package assessments — a vulnerability that NVD rates Critical may be rated differently by, say, the Debian or Red Hat security teams based on how the package is actually used in their distribution.

Whether to include or exclude will_not_fix packages in your investigation depends on your organization’s policy. For a broad initial sweep during a zero-day event, you may want to include everything and triage later (the Queen’s “sentence first, verdict afterwards” approach, applied a little more responsibly). For a more targeted assessment focused on actionable findings, filtering them out reduces noise. The script below supports both via a flag.

Calling the Witnesses: Blast Radius in One Script

The trial wasn’t decided by speeches; it was decided by the witnesses called to the stand. The script below calls the witnesses: it takes one or more CVE IDs, extracts every affected package from the vulnerability record, queries for container images containing each package, and produces a complete blast radius summary.

import sys
import requests
from collections import defaultdict

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

def get_vulnerability(cve_ids):
    params = [("id", cve_id) for cve_id in cve_ids]
    resp = requests.get(
        f"{ANCHORE_URL}/query/vulnerabilities",
        params=params,
        auth=AUTH,
    )
    resp.raise_for_status()
    return resp.json().get("vulnerabilities", [])

def get_images_by_package(name, package_type=None, version=None):
    params = {"name": name}
    if package_type:
        params["package_type"] = package_type
    if version:
        params["version"] = version

    images = []
    page = 1
    while True:
        params["page"] = page
        resp = requests.get(
            f"{ANCHORE_URL}/query/images/by-package",
            params=params,
            auth=AUTH,
        )
        resp.raise_for_status()
        data = resp.json()
        images.extend(data.get("images", []))
        if not data.get("next_page"):
            break
        page += 1
    return images

def investigate(cve_ids, skip_will_not_fix=False):
    print(f"Querying: {', '.join(cve_ids)}")
    if skip_will_not_fix:
        print("  (excluding packages marked will_not_fix by vendor)\n")
    else:
        print("  (including packages marked will_not_fix by vendor)\n")

    vulns = get_vulnerability(cve_ids)
    if not vulns:
        print("No vulnerability records found.")
        return

    affected_images = defaultdict(set)  # image_digest -> set of CVEs

    for vuln in vulns:
        cve_id = vuln.get("id")
        severity = vuln.get("severity", "Unknown")
        affected_packages = vuln.get("affected_packages", [])
        print(f"{cve_id} [{severity}]")
        print(f"  Affected packages: {len(affected_packages)}")

        for pkg in affected_packages:
            name = pkg.get("name")
            pkg_type = pkg.get("type")
            will_not_fix = pkg.get("will_not_fix", False)
            if skip_will_not_fix and will_not_fix:
                continue
            images = get_images_by_package(name, package_type=pkg_type)
            for img in images:
                digest = img["image"].get("image_digest")
                affected_images[digest].add(cve_id)
        print()

    if not affected_images:
        print("No affected images found in fleet.")
        return

    print(
        f"Blast radius: {len(affected_images)} image(s) affected\n"
    )
    for digest, cves in affected_images.items():
        print(
            f"  {digest[:20]}...  "
            f"CVEs: {', '.join(sorted(cves))}"
        )

if __name__ == "__main__":
    args = sys.argv[1:]
    skip = "--skip-will-not-fix" in args
    cve_ids = (
        [a for a in args if not a.startswith("--")]
        or ["CVE-2021-44228"]
    )
    investigate(cve_ids, skip_will_not_fix=skip)

Running it is as simple as passing one or more CVE IDs on the command line:

# Include all affected packages
python3 investigate.py CVE-2021-44228 CVE-2021-45046

# Exclude packages where the vendor won't provide a fix
python3 investigate.py CVE-2021-44228 CVE-2021-45046 --skip-will-not-fix

The script handles pagination automatically, so it works regardless of fleet size. It also deduplicates images across multiple CVEs — if an image is affected by both CVEs in a query, it appears once with both IDs listed.

Following the Trail: Narrowing by Tag History

The Cheshire Cat’s vanishings were never quite total — Alice could usually retrace its path by what it had said last and where. The images response includes a tag_history array for each image, giving you the full list of tags ever associated with that digest. This is useful for identifying which specific deployments are affected — not just that a digest is vulnerable, but which named services or versions carry it. You can extend the script to surface this:

for img in images:
    image_data = img.get("image", {})
    digest = image_data.get("image_digest")
    tags = [
        t.get("full_tag")
        for t in image_data.get("tag_history", [])
    ]
    print(
        f"  {digest[:20]}...  "
        f"tags: {', '.join(tags) if tags else 'none'}"
    )

Up Next

When a zero-day drops, the gap between “we’ve heard about this CVE” and “we know exactly which of our container images are affected” should be measured in seconds, not hours. The /query/vulnerabilities and /query/images/by-package endpoints make that possible — from a CVE ID to a complete blast radius in a single script execution.

Next in the series: Tweedledee and Tweedledum — Comparing Vulnerabilities Across Image Versions. Tweedledee and Tweedledum spent their time arguing about who looked the same and who looked different. Container image versions raise the same question every release — what actually changed between v1.2 and v1.3, which vulnerabilities got fixed, and which ones quietly came along for the ride? We’ll diff vulnerability findings between image versions and get a clear answer.

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: Humpty Dumpty

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

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.” Anchore Enterprise’s GraphQL subsystem takes the same approach to data: you define exactly what you want back, in exactly the shape you want it, without over-fetching or stringing together multiple REST calls to assemble the picture yourself.

The REST endpoints we’ve explored in earlier posts are ideal for targeted, per-image operations. GraphQL is the right tool when you need to ask broader questions across your container fleet — things like “which images have Critical vulnerabilities and which runtime containers are they running in?” or “what is the policy compliance posture across all of my registered tags?” These are questions that would require multiple REST calls, response aggregation, and client-side filtering. With GraphQL, they become a single query.

Pick Your Wall: The Reporting Endpoints

Humpty Dumpty had one wall; you get two. Anchore Enterprise exposes two GraphQL endpoints depending on the scope you need.

https://<anchore-host>/v2/reports/graphql

This endpoint is scoped to the authenticated user’s account. The x-anchore-account header is required:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/reports/graphql" \
  -H "Content-Type: application/json" \
  -H "x-anchore-account: mad-hatter-team" \
  -d '{"query": "{ __typename }"}'
https://<anchore-host>/v2/reports/global/graphql

This endpoint requires administrator access and returns data across all accounts. No account header required:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/reports/global/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __typename }"}'

Glory For You: Exploring the Schema

“There’s glory for you!” Humpty Dumpty told Alice. “I don’t know what you mean by ‘glory,’” Alice replied. “Of course you don’t — till I tell you.” Before writing queries, let GraphQL tell you. Introspection returns the full list of available query types, filter inputs, and response fields directly from your deployment:

curl -s -u _api_key:<your-api-key> \
  -X POST "https://wonderland.example.com/v2/reports/graphql" \
  -H "Content-Type: application/json" \
  -H "x-anchore-account: mad-hatter-team" \
  -d '{
    "query": "{ __schema { queryType { fields { name description args { name type { name kind ofType { name kind } } } } } } }"
  }' | jq .

You can also import the endpoint into a tool like Insomnia or GraphQL Playground — both support introspection natively and give you an interactive schema explorer and query builder. The full list of available query types is summarised below. All queries accept limit, nextToken, and a typed filter object.

Putting Humpty Back Together: Cross-Image Vulnerability Summaries

All the King’s horses and all the King’s men couldn’t put Humpty together again. A single GraphQL query can. Where REST would need a series of round trips — list images, fetch vulnerabilities per image, fetch tags per image, join client-side — imagesByVulnerability returns a list of unique vulnerabilities alongside every container image affected by each one, in one response.

Filtering is done via nested filter objects — severity filtering lives under vulnerability, with separate filter objects available for artifact, registry, repository, tag, and image. Note that severity values are GraphQL enum literals and are written without quotes.

{
  imagesByVulnerability(
    limit: 500
    filter: { vulnerability: { severity: Critical } }
  ) {
    pageInfo { nextToken count }
    results {
      vulnerabilityId
      cve
      imagesCount
      images {
        digest
        distro
        tags {
          registryName
          repositoryName
          tagName
          current
        }
        artifacts {
          artifactName
          artifactVersion
          artifactType
          severity
          fixedIn
          isKev
          epssScore
        }
      }
    }
  }
}

To filter on multiple severities, use severities instead of severity:

filter: { vulnerability: { severities: [Critical, High] } }

In Python, with pagination handled via pageInfo.nextToken:

import requests

ANCHORE_URL = "https://wonderland.example.com/v2/reports/graphql"
AUTH = ("_api_key", "<your-api-key>")
HEADERS = {"x-anchore-account": "mad-hatter-team"}

VULN_QUERY = """
query($nextToken: String) {
  imagesByVulnerability(
    limit: 500
    nextToken: $nextToken
    filter: { vulnerability: { severity: Critical } }
  ) {
    pageInfo { nextToken count }
    results {
      vulnerabilityId
      cve
      imagesCount
      images {
        digest
        distro
        tags {
          registryName
          repositoryName
          tagName
          current
        }
        artifacts {
          artifactName
          artifactVersion
          artifactType
          severity
          fixedIn
          isKev
          epssScore
        }
      }
    }
  }
}
"""

def get_images_by_vulnerability():
    results = []
    next_token = None
    while True:
        resp = requests.post(
            ANCHORE_URL,
            json={
                "query": VULN_QUERY,
                "variables": {"nextToken": next_token},
            },
            auth=AUTH,
            headers=HEADERS,
        )
        resp.raise_for_status()
        data = resp.json()["data"]["imagesByVulnerability"]
        results.extend(data.get("results", []))
        next_token = data.get("pageInfo", {}).get("nextToken")
        if not next_token:
            break
    return results

def main():
    findings = get_images_by_vulnerability()
    print(
        f"Critical vulnerabilities affecting images: "
        f"{len(findings)}\n"
    )
    for f in findings:
        cve = f.get("cve") or f.get("vulnerabilityId")
        print(f"{cve} — {f.get('imagesCount')} image(s)")
        for img in f.get("images", []):
            for tag in img.get("tags", []):
                if tag.get("current"):
                    print(
                        f"  {tag['registryName']}/"
                        f"{tag['repositoryName']}:{tag['tagName']}"
                    )
            for artifact in img.get("artifacts", []):
                fix = artifact.get("fixedIn")
                fix_str = f"fix: {fix}" if fix else "no fix"
                kev_str = " [KEV]" if artifact.get("isKev") else ""
                print(
                    f"    {artifact['artifactName']} "
                    f"{artifact['artifactVersion']} "
                    f"— {fix_str}{kev_str}"
                )

if __name__ == "__main__":
    main()

From the Wall: Policy Compliance Across the Fleet

What the cross-image vulnerability query did for CVE exposure, policyEvaluationsByTag does for compliance — give you the whole fleet’s view from one vantage point. It returns policy evaluations in a hierarchical view: registry → repository → tag → evaluations. Each tag may have multiple evaluation records; use the latest field to identify the most current result.

{
  policyEvaluationsByTag(limit: 1000) {
    pageInfo { nextToken count }
    results {
      registryName
      repositoriesCount
      tagsCount
      account
      repositories {
        repositoryName
        tagsCount
        tags {
          tagName
          imageDigest
          current
          evaluations {
            result
            reason
            lastEvaluatedAt
            latest
          }
        }
      }
    }
  }
}

In Python, flattening the hierarchy to produce a compliance summary:

import requests
from collections import Counter

ANCHORE_URL = "https://wonderland.example.com/v2/reports/graphql"
AUTH = ("_api_key", "<your-api-key>")
HEADERS = {"x-anchore-account": "mad-hatter-team"}

POLICY_QUERY = """
query($nextToken: String) {
  policyEvaluationsByTag(limit: 1000, nextToken: $nextToken) {
    pageInfo { nextToken count }
    results {
      registryName
      account
      repositories {
        repositoryName
        tags {
          tagName
          imageDigest
          current
          evaluations {
            result
            reason
            lastEvaluatedAt
            latest
          }
        }
      }
    }
  }
}
"""

def get_policy_evaluations():
    all_registries = []
    next_token = None
    while True:
        resp = requests.post(
            ANCHORE_URL,
            json={
                "query": POLICY_QUERY,
                "variables": {"nextToken": next_token},
            },            auth=AUTH,
            headers=HEADERS,
        )
        resp.raise_for_status()
        data = resp.json()["data"]["policyEvaluationsByTag"]
        all_registries.extend(data.get("results", []))
        next_token = data.get("pageInfo", {}).get("nextToken")
        if not next_token:
            break
    return all_registries
<br>def flatten_latest_evaluations(registries):
    flat = []
    for registry in registries:
        for repo in registry.get("repositories", []):
            for tag in repo.get("tags", []):
                for evaluation in tag.get("evaluations", []):
                    if evaluation.get("latest"):
                        flat.append({<br>                            "full_tag": (
                                f"{registry['registryName']}/"
                                f"{repo['repositoryName']}:"
                                f"{tag['tagName']}"                            ),
                            "image_digest": tag.get("imageDigest"),
                            "result": evaluation.get("result"),
                            "reason": evaluation.get("reason"),
                            "last_evaluated_at": evaluation.get(
                                "lastEvaluatedAt"
                            ),
                        })
    return flat

def main():
    registries = get_policy_evaluations()
    evaluations = flatten_latest_evaluations(registries)
    counts = Counter(e["result"] for e in evaluations)

    print("Fleet Policy Compliance Summary")
    print(f"  Total tags evaluated: {len(evaluations)}")
    print(f"  Pass: {counts.get('Pass', 0)}")
    print(f"  Fail: {counts.get('Fail', 0)}")
    print()

    failing = [e for e in evaluations if e["result"] == "Fail"]
    if failing:
        print("Failing tags:")
        for e in failing:
            print(
                f"  {e['full_tag']}  "
                f"(evaluated: {e['last_evaluated_at']})"
            )

if __name__ == "__main__":
    main()

For administrator access across all accounts, swap the endpoint and remove the account header:

ANCHORE_URL = "https://wonderland.example.com/v2/reports/global/graphql"
HEADERS = {}

Beyond the Wall: Runtime Inventory Queries

Sitting on the wall, Humpty Dumpty had a view of the static landscape. Runtime inventory queries let you see what’s actually moving on the other side. One of the more distinctive aspects of this GraphQL schema is its deep integration with runtime inventory. runtimeInventoryImagesByVulnerability combines vulnerability data with live Kubernetes and ECS inventory, answering not just “which container images are vulnerable?” but “which vulnerable images are currently running in my clusters?”

{
  runtimeInventoryImagesByVulnerability(
    limit: 500
    filter: { vulnerability: { severity: Critical } }
  ) {
    pageInfo { nextToken count }
    results {
      vulnerabilityId
      cve
      imagesCount
      images {
        digest
        tags {
          registryName
          repositoryName
          tagName
          current
        }
        artifacts {
          artifactName
          artifactVersion
          severity
          fixedIn
          isKev
        }
      }
    }
  }
}

Use introspection to explore kubernetesRuntimeVulnerabilitiesByNamespace and vulnerabilitiesByKubernetesContainer for even more granular Kubernetes-scoped views.

Up Next

The GraphQL reporting interface gives you a query language designed around the questions container security and platform teams actually ask — not individual image lookups, but fleet-wide views of vulnerability exposure, policy compliance, and runtime context. The typed filter inputs and paginated responses are consistent across all query types, so once you’re comfortable with the pattern, exploring the rest of the schema is straightforward.

Next in the series: Who Stole the Tarts? — Chasing the Cheshire Cat Through Zero-Day Vulnerabilities. When a new CVE drops, the question changes from “what does our fleet look like?” to “are we on fire?” — and you need an answer in minutes, not hours. We’ll use the /query/vulnerabilities and /query/images/by-package endpoints to rapidly assess blast radius the moment a vulnerability is disclosed.

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.

For security and platform engineers, the term “End-of-Life” (EOL) often seems like background noise — a compliance checkbox or a distant roadmap item. However, as supply chain attacks become more sophisticated, it’s becoming clear that the greatest risk isn’t always a malicious zero day; often, it’s the forgotten, unpatched library sitting deep in your dependency tree.

In our recent webinar, “The EOL Trap: Why Supply Chain Risk is Often Born of Neglect, Not Malice,” Josh Bressers (VP of Security, Anchore) and Mike Morgan (Senior Solutions Engineer, HeroDevs) break down the technical reality of managing aging software stacks.

Why “Done” Software is a Myth

One of the most persistent misconceptions in engineering is that a piece of software can be “complete.” The reality is that the ecosystem around your code is constantly shifting. A library that was secure four years ago may now be incompatible with modern compilers (like GCC updates) or vulnerable to exploits that didn’t exist when it was written. If a package hasn’t seen a commit in years, it isn’t “stable”— it’s a liability.

The Complexity of Transitive Dependencies

The webinar dives into the data behind the 12.1 million open-source packages currently tracked. A significant portion of these have not seen an update in over four years, yet they continue to garner millions of downloads. As engineers, we often lack visibility into these transitive dependencies. You might be running the latest version of your primary framework, but six layers deep, you’re still tethered to an EOL library that no one is maintaining.

Moving Beyond CVSS

While vulnerability scanners are essential, they often fail to flag EOL status unless a specific CVE is assigned. Josh and Mike discuss how to use heuristics—such as repository archiving, README deprecation notices, and stale release lines—to identify risk before it becomes a critical incident.

Watch the full recording

If you’re tasked with maintaining legacy systems or securing complex CI/CD pipelines, this discussion provides a pragmatic framework for identifying and remediating EOL risks.

If you’ve been in the security universe for the last few decades, you know we love a good vulnerability scanner. We’re great at finding known bads. We have very mature practices to hunt for CVEs, malware, and leaked secrets. But here’s the thing about modern software development: the trend continues, where deployed applications are composed mostly of open-source software. 

We treat our own proprietary code like a prized possession. We run QA, we enforce secure development practices, we fuzz it, we review it before it ever hits production. But what about the rest of the application? We just sort of trust it. Sure, we check the specific version of an open source dependency to see if it has a CVE, but we rarely look deeply at the qualities of the open-source project itself through the lens of security. 

Relying purely on vulnerability databases to measure risk is a systemic problem. A lack of CVEs doesn’t mean a piece of software is safe to use; it just means it doesn’t have a known CVE registered against it. 

The Threat Intelligence Gap

Let’s step back and see what the state of threat intelligence actually is. A solid threat hunting practice relies on high-quality data. But if you’re only looking at whether FUBAR version 1.0 has a known CVE or leaked credentials, you’re missing the bigger picture.

What if the project itself has been abandoned by its maintainers for three years? What if it’s End of Life? What if the project does have vulnerabilities, but the maintainers take an average of six months to actually ship a fix?

Or worse, what if the project doesn’t even exist? We’re seeing a fascinating and terrifying new threat vector right now: AI code generators hallucinating dependencies. An AI might write a script and confidently suggest import YAML instead of the actual, real-world project, PyYAML. A malicious actor sees that hallucination, creates a fake project named YAML loaded with malicious code, and waits for a developer to blindly copy-paste the AI’s output.

These aren’t theoretical problems. This is the new reality of the software supply chain. But traditional scanners won’t catch these issues because there’s no CVE for “project was created yesterday by a name-squatter.”

What is Anchore doing?

Our Chief Research Officer, Daniel Nurmi, recently gave a fantastic presentation with the goal to figure out how to evaluate open-source projects using the same rigorous criteria we apply to our own applications.

At Anchore, we’ve been building a data-gathering pipeline to solve this. It starts with a Software Bill of Materials (SBOM). We take that list of ingredients, go out into the messy reality of the internet, and find the canonical source of truth for those projects (like their GitHub repository).

From there, we can normalize the data and extract some really useful insights:

• Boolean metrics: Does the project actually exist (DNE)? Is it End of Life (EOL)?
• Time-based metrics: How old is the project? When was the last release? What’s the cadence for fixing security issues?
• Qualitative metrics: Are there active maintainers, or is it a ghost town?

But throwing more data at developers doesn’t fix systemic problems, it’s just an increasing amount of noise. Therefore we here at Anchore gather the metrics and apply a flexible scoring technique. A project that “Does Not Exist” or is EOL bubbles right to the top of the risk list, because those are massive red flags that need immediate attention.

Watch Dan’s talk to see how this actually works and how we catch AI-hallucinated packages before they introduce risk into an environment.

Ready to stop guessing what’s in your code?

It’s easy to be a cynic about supply chain security, but the truth is you can’t secure what you don’t understand. If you’re ready to stop wondering what’s lurking in your dependencies, we are here to help. Anchore’s SBOM-powered platform gives you the comprehensive visibility you need to actually manage your software supply chain risk.

From automatically generating accurate SBOMs to continuous vulnerability scanning and advanced policy enforcement, we give you the actionable data to find hidden threats and achieve compliance by default. Whether you need to rapidly detect zero-days, manage imported third-party SBOMs, or automate policy checks for frameworks like NIST and FedRAMP, we have you covered.

Reach out to our team and request a demo to get started.