# Container Images

### Table of Contents

1. [Adding a Container Registry Integration](#adding-a-container-registry-integration)
2. [Automatic Labeling Policy](#automatic-labeling-policy)
3. [Viewing Container Images](#viewing-container-images)
4. [Mapping Images to Source Code](#mapping-images-to-source-code)

***

### Adding a Container Registry Integration

1. **Navigate to Integrations**\
   In the sidebar, go to **Admin → Integrations**. Or click here: <https://app.arnica.io/#/admin/integrations>
2. **Locate your registry type**\
   Under **Containers**, choose your registry, and follow the instructions below to integrate:

   <figure><img src="https://4035514934-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMxc1Ek3qoIZi5t2Sx7do%2Fuploads%2Fgit-blob-2c817d69c72bf3159301cdf4bac2273ab976b539%2Fimage.png?alt=media" alt=""><figcaption><p>Integration Options</p></figcaption></figure>
3. Add the integration based on the instructions below
   * [Amazon Elastic Container Registry (ECR)](https://docs.arnica.io/arnica-documentation/getting-started/container-integrations/ecr)
   * [GitHub Container Registry (GHCR)](https://docs.arnica.io/arnica-documentation/getting-started/container-integrations/ghcr)
   * [JFrog Artifactory](https://docs.arnica.io/arnica-documentation/getting-started/container-integrations/jfrog-artifactory)
   * [Azure Container Registry (ACR)](https://docs.arnica.io/arnica-documentation/getting-started/container-integrations/acr)
   * [Google Artifact Registry (GAR)](https://docs.arnica.io/arnica-documentation/getting-started/container-integrations/gar)

***

### Automatic Labeling Policy

<figure><img src="https://4035514934-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMxc1Ek3qoIZi5t2Sx7do%2Fuploads%2Fgit-blob-b30e19e586e41235910ccaaeabd57c3ba8fb2850%2Fimage%20(1).png?alt=media" alt=""><figcaption><p>Policy definition</p></figcaption></figure>

To ensure every Docker image is traceable back to its Dockerfile and source code repository, configure an **Auto‑Labeling** policy.

1. **Open Policies**\
   In the sidebar, go to **Admin → Policies**, expand **Code Risk**, then select **Rules**.
2. **Create “Tag Dockerfiles” rule**
   * **Trigger**: Pull Request Created
   * **Conditions**:
     * Add conditions to limit which repositories, organizations, or products participate in automatic labeling. Please discuss the implications with the affected developers and their management before proceeding; otherwise, it may generate unnecessary noise.
   * **Action**: **Tag all Dockerfiles**
3. **Configure OCI annotations**\
   Under the **Tag all Dockerfiles** action:

   * Enable `org.opencontainers.image.source`

   * Enable `org.opencontainers.image.path`

   * (Optional) Add a **Custom Message** to display in PR comments

   > **Why?** OCI annotations let you trace each image back to the exact Dockerfile path and Git commit, improving supply‑chain auditability.
4. **Save & enable**
   * Give your rule a descriptive name and save.
   * Toggle it **On** to start tagging on every new PR.

{% hint style="info" %}
The developer facing documentation for this is here: [adding-oci-tags-to-docker-images](https://docs.arnica.io/arnica-documentation/developers/adding-oci-tags-to-docker-images "mention").
{% endhint %}

***

### Viewing Container Images

Once registries are connected and labeling is enabled, you can browse all synced images:

1. **Inventory → Container Images**\
   In the left‑hand nav under **Inventory**, click **Container Images**.
2. Click on a row to see all recent versions. Arnica scans each day the last 20 versions, and marks the most recent one as the latest version (think of it as the HEAD of the default branch if this was a source code repository). The sorting is based on the following sorting logic:

   1. **“latest” Comes First**
      * Any image tagged exactly `latest` always beats all other tags.
      * If there are multiple “latest” images, the one that was most recently pushed (i.e. uploaded) appears first.
   2. **Official Version Numbers (SemVer) Next**
      * After “latest,” images tagged with formal version numbers (for example, `1.2.3` or `2.0.0-beta`) come next.
      * Among these, we compare the version numbers themselves so that `2.0.0` ranks above `1.9.5`, and so on.
      * **We automatically strip a leading `v`**, so tags like `v1.2.3` are treated exactly the same as `1.2.3`.
   3. **Date‑Based Tags After That**
      * If images are tagged with dates (for example, `2025-09-15`), those show up after semantic versions.
      * Newer dates are listed before older ones (e.g. `2025-09-20` will appear above `2025-08-30`).
   4. **Finally, Fallback to Push Time**
      * If an image doesn’t have “latest,” a clear version number, or a date tag, we simply sort by when it was pushed.
      * More recently pushed images will be higher on the list.

   **Why This Order?**

   * **Clarity:** “latest” often represents your intended default build.
   * **Predictability:** Formal version tags follow industry‑standard versioning, so you see the newest major/minor/patch releases first.
   * **Chronology:** Date tags help when you build daily or nightly images.
   * **Recency:** Everything else is organized by when it arrived, so you still see the freshest builds before older ones.

***

### Mapping Images to Source Code

Arnica can automatically or manually map images back to their source Dockerfiles and enrich them with type labels.

#### 1. Automatic Mapping

* **Statistical matching**\
  Compares the image’s config history against your codebase’s Dockerfile lines to infer a match.
  * **Assignment Type**: `Lines`
  * **Confidence**: medium as it is statistical based
* **Labels based mathcing**\
  Uses the `org.opencontainers.image.source` and `org.opencontainers.image.path` labels / annotations to perform the linking. Note that in order for the linking to succeed, these repos must be visible to Arnica after a full inventory scan.\
  More about this method in [adding-oci-tags-to-docker-images](https://docs.arnica.io/arnica-documentation/developers/adding-oci-tags-to-docker-images "mention").
  * **Assignment Type**: `Labels`
  * **Confidence**: high as it's based on deterministic labels

#### 2. Manual Mapping

* **Override any image**
  * In the **Container Images** view, click an image, and enter the repository name under the dropdown labeled: "Link to repository (type to search)".
  * Once you select a repository, another dropdown will show if there are any detected `Dockerfile` files in it during the last inventory scan. Selecting the matching `Dockerfile` can improve correlation in case it is stored in the same folder as an application (e.g. in a monorepo, the `/payment-service` folder contains both the `Dockerfile` as well as the `package-lock.json` or `pom.xml` etc.).

{% hint style="info" %}
If you changed your mind and want to go back to automatic mapping, you can always do that by clicking the ***Auto*** radio button. All changes are automatically saved.
{% endhint %}
