How do you tell which repository built a GitHub Container Registry image?

Check whether the image is linked to a repository. GitHub's documentation says pushing from the command line does not link a package to a repository by itself. Publishing from a GitHub Actions workflow links it automatically, and a Dockerfile label named org.opencontainers.image.source can link it too. An unlinked image has no stated source.

How linking works

GitHub documents several ways a container package becomes linked to a repository. Pushing from the command line does not link the image, even if the namespace matches the repository name. The easiest method is publishing from a workflow using the built-in workflow token, which links the workflow's repository automatically. For command-line publishing, you can add the org.opencontainers.image.source label to the Dockerfile, set to the repository URL. A linked package inherits the repository's access permissions, unless the organisation has disabled that inheritance.

New packages default to private visibility, and visibility can be changed in the package's access settings.

Why this helps a consumer

A linked package gives you a repository to read: the Dockerfile, the workflow that built it, the issue tracker and the commit history. That is far better than a name and a tag.

It is still a claim. The label is text set by whoever builds the image, so a repository URL in it is not proof of anything unless the repository itself matches what you expect.

Steps to check an image

1. Open the package page and look for a linked repository. Note the owner and name.
2. Compare the owner with the project or vendor you intend to use. A similar name under a different owner is a red flag.
3. Open the repository and look for the workflow or Dockerfile that builds the image. Is the build visible and recent?
4. Check whether the image has the source label, using an image inspect command, and whether its value matches the linked repository.
5. Look at release notes or tags in the repository against the image tags.
6. Pin the digest, scan it, and record the repository and commit you looked at.

Reading a mismatch

If the package page names one repository and the label names another, ask why before use. There can be innocent reasons, such as a project that moved. There can also be copied labels on a lookalike image. Either way, a mismatch is a reason to stop and confirm.

What your own images should do

If you publish images, link them. Build and push from a workflow so the link is automatic, set the source label for images built elsewhere, and keep package visibility intentional. Your consumers will do the checks above, and a clean link makes them quick.

Quick check

Safeguard dependency scanning and SBOM cover the images you adopt, so a source link is backed by a record of what is inside. Try a free scan at gold.safeguard.sh/scan.

Sources

• GitHub Docs: Working with the Container registry

Last reviewed: 19 October 2026.