Measuring Anonymous Container Image Registry Access Risk in Harbor Deployments Through Vulnerability Assessment and Remediation Validation

Organizations use Harbor as a container image registry for storing, managing, and distributing container images used by applications and services.

Harbor projects can be configured with different visibility and access-control settings. If a project is configured for public access, container images within that project may be retrievable without authenticated Harbor credentials.

In this use case, a controlled Harbor container registry is deployed on Ubuntu Linux inside an isolated VirtualBox laboratory. Kali Linux is used as the controlled vulnerability-assessment system.

The application used inside the container image is OWASP NodeGoat. NodeGoat is packaged as a container image and stored in the Harbor repository. Harbor is the target registry platform, while NodeGoat provides the controlled application artifact being assessed.

A controlled anonymous container image registry access assessment is performed to determine whether an unauthenticated user can discover and retrieve the NodeGoat container image.

Trivy is used to assess vulnerabilities in the NodeGoat container image. Wazuh monitors relevant Ubuntu and Harbor activity, while OpenSearch supports centralized investigation and correlation.

The identified exposure is risk-prioritized, remediated by restricting project access, and then retested to validate the remediation.

The complete vulnerability-management workflow is: Harbor Deployment → Project/Repository Discovery → Anonymous Access Assessment → Registry Exposure Identification → Container Artifact Enumeration → Vulnerability Scanning → Risk Prioritization → Remediation Planning → Project Access Restriction → Vulnerable Artifact Protection → Post-Remediation Access Testing → Security Monitoring → Evidence Correlation → Remediation Validation.

Harbor is the target container image registry application in this use case. It provides centralized storage, management, and distribution of container images.

Harbor projects can be configured as public or private. A public project may allow users to pull container images without authentication. If a container image containing vulnerable application components is exposed through an anonymously accessible project, an unauthorized user may be able to retrieve the container artifact and identify vulnerable components. In this use case, OWASP NodeGoat is packaged as the container image and stored in the Harbor repository.

The security problem is therefore:

The assessment validates anonymous access, identifies exposed artifacts, scans the exposed NodeGoat image, prioritizes the identified risk, applies access-control remediation, and performs post-remediation validation.

The attack scenario focuses on unauthorized retrieval of a container image from a Harbor project that has been intentionally configured as publicly accessible within the authorized laboratory. The assessment validates whether the Harbor project permits unauthenticated registry access. Kali Linux is used to identify the Harbor registry, discover the publicly accessible project and repository, and attempt to retrieve the NodeGoat container image without authentication.

Anonymous registry exposure assessment determines whether a Harbor project or repository can be accessed without authenticated credentials. Vulnerability-based risk prioritization considers both the accessibility of the container artifact and the vulnerabilities identified within it. Remediation validation confirms that access restrictions are effective after the required changes are applied.

The assessment validates Harbor project visibility, repository discovery, image metadata access, and container image retrieval. Trivy scans the exposed NodeGoat container image to identify known vulnerabilities in the application and its software components. The findings are considered together with the anonymous exposure context to prioritize remediation. The Harbor project is then changed from public to private, and the original anonymous-access assessment is repeated to verify that unauthorized access is rejected while authorized access remains available.

The secure processing flow is: