📦Container Images

Manage your organization’s container supply chain from end to end: connect registries, automatically tag and label images, inspect image inventories, and map back to source code.

Table of Contents

  1. Adding a Container Registry Integration

  2. Automatic Labeling Policy

  3. Viewing Container Images

  4. 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:

    Integration Options

  3. Add the integration based on the instructions below

Automatic Labeling Policy

Policy definition

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.

The developer facing documentation for this is here: Adding OCI Tags to Docker Images.

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.

    • 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.).

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.

PreviousPrioritization & Product OwnershipNextSecret Detection

Last updated

Was this helpful?