Registry Sources and Artifact Metadata

Overview

Container scanning in Fencer works with two types of sources: cloud provider accounts accessed via the cloud integration credentials, and standalone OCI-compatible registries connected through the Container Registry integration. This page covers what each source discovers, what permissions are required, and the artifact metadata that Fencer records for each discovered image.

Sources and what they discover

AWS

Fencer discovers images with the scanner role configured on the AWS integration. No separate registry credential is needed. Discovery covers, in every active region the connection scans:

Images running in ECS tasks, EKS clusters, and Lambda functions packaged as container images.
The newest image in each Amazon Elastic Container Registry (ECR) repository, when that image isn’t already found running elsewhere.

The Fencer scanner role from the AWS integration setup includes the ECR read permissions it needs (ecr:BatchGetImage, ecr:Describe*, ecr:Get*, and ecr:List*). Discovering images in EKS also needs the role to have view access to each cluster.

GCP

For GCP integrations, Fencer finds the images running in GKE workloads through Cloud Asset Inventory, using the configured service account. The Cloud Asset and Cloud Resource Manager APIs must be enabled. To pull private images for scanning, the service account needs the Artifact Registry Reader role (roles/artifactregistry.reader) on the relevant projects.

When Artifact Registry discovery is enabled for your organization, discovery also includes the newest tagged image of each image in each Artifact Registry Docker repository in the regions the connection scans, unless an image with the same name is already running in a GKE workload. That lookup needs the Artifact Registry API (artifactregistry.googleapis.com) enabled.

Azure

Azure integrations discover images in Azure Container Registry (ACR), Azure Container Instances, Container Apps, and AKS clusters. Assign the AcrPull built-in role to the Fencer Scanner app on each registry you want scanned. This role grants read-only image pull access without write or delete permissions. To scan images running in AKS, the app also needs the Azure Kubernetes Service Cluster Admin Role on each cluster (or on the subscription), and the cluster must allow local accounts.

DigitalOcean

DigitalOcean integrations use the API token configured on the connection to discover images in DigitalOcean Container Registry and in DigitalOcean Kubernetes clusters. No separate registry credential is needed.

Container Registry (Docker Hub, GitHub Container Registry, Harbor, self-hosted)

The Container Registry integration connects Fencer to any registry that implements the OCI Distribution Specification, such as Docker Hub, GitHub Container Registry, Quay.io, Harbor, and self-hosted registry deployments.

Configuration:

Name — An optional name for the connection. Defaults to the URL.
URL — The registry URL, optionally with a namespace or organization path (for example ghcr.io/myorg or https://registry.example.com). https:// is assumed when you leave out the scheme.
Username and Password — A registry username and a password or access token with pull permissions. Leave both blank for public registries that allow anonymous access.
Images — Specific images to scan, one per line, up to 20 (for example nginx:1.27, or ghcr.io/org/image:tag for other registries). Required for public registries.
Scan registry images — Scan the listed images, or the registry catalog when you provide credentials. On by default.

With credentials and no Images list, Fencer scans every repository and tag in the catalog. A URL that returns more than 100 repositories is rejected: add a namespace or organization to the URL to narrow it.

For Docker Hub, use a personal access token rather than your account password. For Harbor and other self-hosted registries, create a service account or robot account with pull permissions.

Enabling container scanning

Container scanning is on by default for every source, and you can turn it off per integration:

Cloud accounts (AWS, GCP, Azure, DigitalOcean) — Scan container images on the connection, under Admin > Integrations.
Container Registry integrations — Scan registry images when creating or editing the connection.

Sources with scanning on are included in the daily discovery and in every Scan All.

Artifact metadata fields

Each image discovered during the discovery phase creates or updates an Artifact record. The following fields are recorded:

Field	Description
Name	The registry and repository path of the image (for example `ghcr.io/my-org/my-app`)
Tag	The image tag most recently discovered (for example `latest`, `v1.2.3`, or `main-abc1234`)
Digest	The SHA256 content-addressable digest (for example `sha256:abc123...`), when the source has it
Platform	The operating system and architecture (for example `linux/amd64` or `linux/arm64`)
Visibility	Whether the image is in a public or a private registry
Source	The cloud account or registry integration that discovered the image
Type	Docker / OCI Container Image, or Amazon Machine Image (AMI)

An artifact is one image name per source. When discovery finds a newer tag or digest for the same image, Fencer updates the existing artifact instead of adding another one. The artifact’s detail page shows the full image reference (name, tag, and digest) along with its source, platform, and type.

Discovery phase mechanics

The discovery phase runs a container scan against each connected source. During discovery:

Fencer authenticates to the source using the configured credentials.
Fencer enumerates the source’s images (see Sources and what they discover). Build cache tags and image signature tags are skipped.
For each image not seen before, Fencer creates an Artifact record with the metadata fields above.
For images already in the system, Fencer updates the tag, digest, and platform if they have changed.

Discovery itself does not produce vulnerability findings — it builds the artifact inventory and then starts a vulnerability scan for each discovered artifact that isn’t suspended.

Scan phase mechanics

The scan phase processes each discovered artifact:

Fencer pulls the image using the source’s credentials.
The scanner analyzes the image filesystem layer by layer, extracting:
- OS package inventory (e.g., apt, rpm, apk package lists)
- Language dependency manifests (e.g., package-lock.json, requirements.txt, go.sum, Gemfile.lock)
Each package and dependency is cross-referenced against known CVEs.
Findings are normalized into vulnerability records with severity ratings and linked to the originating Artifact. Each vulnerability also records whether an upstream fix is available.

Scan All status

While a Scan All discovery is in progress, the Scan All button on the Artifacts page shows Scanning… and can’t be clicked. Individual artifacts show their own scan status in the list.

Platform and architecture considerations

Fencer scans each image using the platform recorded for it, or linux/amd64 when none is known. Most production images target linux/amd64 or linux/arm64.

If the image doesn’t include that platform, Fencer tries linux/amd64, linux/arm64, windows/amd64, and windows/arm64 in turn, and updates the artifact’s platform to the first one that works.
Multi-arch images (using manifest lists) are scanned for one platform: the recorded one, or the first fallback the image contains.

Examples

Viewing artifact metadata

Go to Posture > Artifacts. Each row shows the image name, tag, source, and platform. Click an artifact to see its full image reference, including the digest, along with its source, platform, and type.

Understanding discovery results

After clicking Scan All, the button shows Scanning… until discovery finishes. Discovery may add new Artifact records to your list if new images were deployed or pushed since the last scan. Existing artifacts show their previous vulnerability counts until their new scan completes.

Troubleshooting

AWS ECR authentication failures — Verify that the scanner role can pull the image (ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, and ecr:BatchCheckLayerAvailability).
Azure ACR access denied — Ensure the Fencer Scanner app (or, for a Container Registry connection, the service principal) has the AcrPull role assigned on the registry.
GCP images not discovered — Images running in GKE workloads need the Cloud Asset and Cloud Resource Manager APIs enabled, and a service account that can read the projects that host the clusters. When Artifact Registry discovery is enabled for your organization, Artifact Registry Docker repositories in the scanned regions are included too: the newest tagged image of each image, unless an image with the same name is already running in GKE. Enable the Artifact Registry API (artifactregistry.googleapis.com) and confirm the service account can list those repositories. To pull private images, the service account needs roles/artifactregistry.reader.
Container Registry connection fails — Check the URL and credentials, and that the access token has not expired. If the error says the URL returns too many repositories, add a namespace or organization to the URL (for example ghcr.io/myorg).
“Image is not available for any supported platform.” — Check the image manifest to confirm the target platform, and rebuild the image for linux/amd64 or linux/arm64.