This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Runtime Inventory

Most of what Anchore Enterprise analyzes arrives from the software delivery pipeline: a CI job submits an image, a registry subscription notices a new tag, or a build publishes an SBOM. Runtime inventory adds the other end of the lifecycle. Agents deployed in Kubernetes clusters and Amazon ECS report which images are actually running, and Anchore Enterprise joins that inventory to the SBOMs, vulnerability matches, and policy evaluations it already holds for those images. The result is a continuously maintained answer to a question build-time scanning cannot ask: of everything that has been analyzed, what is running right now, and where?

Inventory, Contexts, and the Working Set

An inventory record says that a particular image was seen running in a particular context at a particular time. The context is what makes a finding actionable, because it names the place to go and fix it.

  • For Kubernetes, the context is a cluster name and namespace, such as cluster-one/platform-services, with the node and pod recorded underneath it. The cluster name is set in the agent’s configuration, so it is whatever the operator chooses to call that cluster.
  • For Amazon ECS, the context is a cluster ARN, such as arn:aws:ecs:eu-west-2:123456789012:cluster/payments, with the services, tasks, and containers recorded underneath it.

Inventory is deliberately a working set rather than a permanent history. Each report refreshes the last-seen time of the containers and images it names. A deployment-wide time-to-live on the catalog service removes containers, images, and supporting metadata that no agent has reported within the window, and an optional overwrite mode replaces a context’s previous inventory with each new report. Tune these to balance how long a stale record may linger after an agent outage against how quickly retired workloads should disappear. See Runtime Inventory configuration.

The reporting service keeps its own historical record of inventory for report generation, subject to its data retention settings, so a short working-set time-to-live does not erase the trail that reports draw on.

Agents Report, Anchore Enterprise Analyzes

The agents are intentionally thin. Each one runs inside the environment it observes, lists running containers through that platform’s API (the Kubernetes API for anchore-k8s-inventory, the Amazon ECS APIs for anchore-ecs-inventory), and posts the image references and contexts it finds to the Anchore Enterprise API on a fixed interval. Agents make outbound connections only and report references rather than content, so no image data leaves the cluster and nothing in Anchore Enterprise needs to reach into it.

Analysis stays on the Anchore Enterprise side. An image that is already in the catalog is joined to its inventory records as soon as it is reported. An image that Anchore Enterprise has never analyzed appears in the inventory without findings until it is analyzed; watching the context with a runtime_inventory subscription queues each new image it reports for analysis automatically, using the deployment’s own registry credentials to pull it. From then on the image is re-evaluated against new vulnerability data and policy changes like every other stored SBOM. See Watch a Cluster or Namespace and Runtime Inventory Subscriptions.

sequenceDiagram
    participant W as Running workloads
    participant A as Inventory agent
    participant E as Anchore Enterprise
    participant R as Registry
    loop Every reporting interval
        A->>W: List running containers
        A->>E: Report image references and context
    end
    E->>E: Join inventory to stored SBOMs, vulnerabilities, policy results
    opt Context is watched and image is not yet analyzed
        E->>R: Pull image
        E->>E: Analyze, store SBOM, evaluate policy
    end

Agents observe and report; analysis, matching, and evaluation happen centrally.

Because findings arrive through two independently scheduled pipelines, the agent’s reporting interval and the deployment’s analysis queue, the runtime view is near-real-time rather than synchronous with the cluster. See Data Freshness.

Observation Versus Enforcement

Runtime inventory is observational. It tells you what is running and how it stands against policy, and it never prevents a container from starting. Enforcement at the cluster boundary is a separate component: the Kubernetes Admission Controller evaluates an image against Anchore Enterprise policy when Kubernetes asks to admit it, and can reject the deployment, require prior analysis, or simply ensure every admitted image gets analyzed. The two are complementary. Admission control stops known-bad images at the door; inventory catches what was admitted before a vulnerability was disclosed, what arrived outside the admission path, and what has drifted since.

How Runtime Inventory Is Used

  • Blast radius for a new vulnerability — Because inventory is joined to stored SBOMs, a newly published CVE can be traced to the clusters, namespaces, and containers running an affected package without re-scanning anything. The Kubernetes Inventory view in the Anchore Enterprise GUI answers this by vulnerability, and the Vulnerabilities by Kubernetes Namespace, Vulnerabilities by Kubernetes Container, and Vulnerabilities by ECS Container report templates answer it across the fleet. See Kubernetes Inventory and Reporting.
  • Prioritizing by what is running — Reports and views scoped to runtime inventory let a security team work the vulnerabilities in production first rather than everything in the registry.
  • Policy posture of live workloads — Running images are evaluated against their account’s default policy, so the runtime view shows compliant, non-compliant, and not-yet-evaluated workloads side by side. Hosting a watch in a dedicated account with a stricter default policy applies a runtime-specific ruleset. See Policy and Account Scoping.
  • Protecting production data from retention rules — Analysis archive rules and artifact lifecycle policies can treat presence in runtime inventory as a criterion, so images still running stay in the working set while idle ones are archived or deleted. See Data Management.