> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/findings/containers.md).

# Containers

Vulnerability, secret and support-lifecycle results for the container images your cloud accounts push and run.

**Security → Containers** is your inventory of scanned container images. Each row is one image digest, with the packages inside it, the vulnerabilities in those packages, any secrets in its layers, the support state of its operating system and runtimes, and the workloads running it.

{% hint style="info" %}
**Who this is for:** platform and security engineers who own what ships in your images.
{% endhint %}

## What a scan records

Every layer of the image is read, and the scan records:

| Item                 | What you get                                                                                                                                        |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Packages**         | Operating-system packages and application dependencies, with version, package type, licenses and package URL.                                       |
| **Vulnerabilities**  | One row per package and advisory, with severity, CVSS, EPSS, KEV membership, the fixed version where one exists, and the distribution's fix status. |
| **Secrets**          | Credentials in the files the image's layers wrote, with the rule that matched, the file path and the layer.                                         |
| **Operating system** | The distribution and release, and the date its security support ends.                                                                               |
| **Runtimes**         | The language runtimes installed in the image, each with its version and support state.                                                              |
| **Layers**           | The filesystem layers, the build instruction behind each, and which came from the base image.                                                       |
| **Base image**       | The base the image declares, how it was declared, and its digest.                                                                                   |

Runtimes cover .NET, Go, Java, Node.js, PHP, Python and Ruby.

When the same digest sits in more than one repository, each copy is its own row and links to the others.

## What container scanning needs

Heeler scans an image after your cloud account reports that it was pushed. Push events reach Heeler through cloud event collection.

| Registry                             | What you connect                                                                                                                                                       |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Amazon ECR**, private repositories | An AWS connection with [event collection](/mrecEO40m5D6bt7Pq5pE/get-started/cloud-and-runtime/amazon-web-services/aws-event-collection.md). Tagged pushes are scanned. |
| **Google Artifact Registry**         | A Google Cloud connection with [event collection](/mrecEO40m5D6bt7Pq5pE/get-started/cloud-and-runtime/google-cloud-platform/gcp-event-collection.md).                  |

### Images found running

Heeler also reads the image digests declared by your running workloads — ECS tasks and services, Kubernetes pods, Cloud Run revisions, and Lambda functions packaged as images.

When a running workload references a digest that is not yet in the inventory, Heeler scans that image directly. This is the path to results for an account without event collection, and it covers images whose push predates the connection.

## The two views

The **Browse by** tabs give two views of the same data.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Images</strong></td><td>One row per image digest, with its vulnerability, secret and support rollups.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/images.md">Container Images</a></td></tr><tr><td><strong>Vulnerabilities</strong></td><td>One row per image, package and advisory.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/vulnerabilities.md">Container Vulnerabilities</a></td></tr></tbody></table>

Both views share one set of filters. On the Images tab, a filter that describes a finding — severity, package, vulnerability, fix availability — selects images that have at least one finding matching it.

{% hint style="info" %}
Containers has its own listings, filters and exports.
{% endhint %}

## In this section

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Container Images</strong></td><td>The Images listing — its columns and every filter.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/images.md">Container Images</a></td></tr><tr><td><strong>Container Image Detail</strong></td><td>One image: contents, build, timeline and its five tabs.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/image-detail.md">Container Image Detail</a></td></tr><tr><td><strong>Container Vulnerabilities</strong></td><td>Browse by vulnerability across every scanned image.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/vulnerabilities.md">Container Vulnerabilities</a></td></tr><tr><td><strong>Base Image Upgrades</strong></td><td>Newer base tags, and what each removes.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/base-image-upgrades.md">Base Image Upgrades</a></td></tr><tr><td><strong>Scanning and Retention</strong></td><td>When an image is scanned, rescanned and removed.</td><td><a href="/mrecEO40m5D6bt7Pq5pE/findings/containers/scanning-and-retention.md">Scanning and Retention</a></td></tr></tbody></table>

## Related

* [Supported Technologies](/mrecEO40m5D6bt7Pq5pE/supported-technologies.md) — the registries and operating systems container scanning covers.
* [Connect Your Cloud and Runtime](/mrecEO40m5D6bt7Pq5pE/get-started/cloud-and-runtime.md) — the connections that supply push events and the running-workload inventory.
* [Catalog → Deployments](/mrecEO40m5D6bt7Pq5pE/catalog/deployments.md) — the deployments those workloads belong to.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/findings/containers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.