Which image labels help route container findings to an owner?

Add a few standard OCI annotations to every image you build: source, revision, authors, version and base digest. A scanner or a person can then read the labels on a flagged image and find the repository and team that own it, without asking around or keeping a separate spreadsheet.

The problem labels solve

A scan flags an image named something like platform-api, tag 4.2. Who fixes it? In many companies the answer takes a day of messages. The image itself can carry the answer if the build writes it in.

The OCI image specification defines a set of pre-defined annotation keys under the org.opencontainers.image prefix. They are optional, but they are standard, so tools can rely on them.

Keys worth setting

From the specification's annotation list:

The spec describes authors as freeform text, so a team mailbox or a team name works better than a single person who may leave.

How to set them

You can pass labels at build time. Docker's build command accepts a label option, and many build tools write annotations from CI variables. In a CI pipeline, fill the values from variables the pipeline already knows: the repository URL, the commit SHA, the release tag. Do this in one shared build template, not by hand in each repository, so no team forgets.

Avoid putting secrets, internal ticket numbers or personal data in labels. Anyone who can pull the image can read them.

How routing then works

1. The scan flags an image digest.
2. A script or your scanner's integration reads the source and authors labels.
3. The finding is assigned to that repository's owners, or a ticket is opened there.

Findings in a base image can be grouped by the base digest label, so a platform team handles one fix instead of fifty tickets. See base image rollup report for the grouping idea.

Where this breaks

• Images built before you adopted labels have none. Backfill from the registry if you can, or assign them to a default owner.
• Labels can be wrong or out of date. Treat them as a hint and verify during triage.
• Third-party images carry the publisher's labels, not yours. Route those findings to whoever approved the image for use.

A worked example: from flagged image to owner in three steps

Suppose a scan flags an image with a digest starting sha256:7f3a. Without labels, someone searches chat for the team. With labels, a script inspects the image configuration and reads the following values.

The finding is assigned to the payments repository, a ticket mentions the commit, and the base digest shows that the vulnerable package came from the shared base image, not from the payments code. The platform team gets one ticket for the base, and the payments team gets none. Triage took minutes.

Step by step: roll out labels

1. Pick the five keys above as your minimum set.
2. Add them in the shared build template or pipeline step, filled from CI variables.
3. Add a check that fails the build if source or authors is empty.
4. After a week, query the registry to see which images still lack labels.
5. Backfill older images by owner lookup, or label them "unowned" and review those monthly.
6. Teach your triage script or ticket integration to read the labels.

Using labels beyond routing

Once the labels exist you can answer other questions quickly.

• Which images were built from a commit that is now known to be vulnerable?
• Which images share a base digest, and how many services need the same base update?
• Which images have no source label, and therefore were not built by the standard pipeline?
• Which images list a person, not a team, as author?

The last two are signals about process health, not just routing.

Keep labels honest

A label is a claim made by the builder. It can be wrong. An image built on a laptop could carry a source label that points to the main repository. Where it matters, combine labels with provenance or signature evidence that you can check, and treat the label as a lookup key rather than proof.

The specification also says the keys are optional and that freeform fields such as authors are strings, so different teams may fill them differently. Write a short style guide: use a team mailbox, use the canonical repository URL, and use the release tag for version.

Common mistakes

• Labeling by hand, which guarantees gaps.
• Putting sensitive data in labels. Anyone who can pull the image can read them.
• Using a personal email, which goes stale when people move.
• Forgetting that third party images carry labels you did not write.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at what information is attached to each item, and imagine the same fields coming from image labels.

Where Safeguard fits

Safeguard's asset discovery and vulnerability management can help you keep track of which assets exist and who looks after them. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• OCI image spec: pre-defined annotation keys

Last reviewed: 19 October 2026.