Harbor: Container Registry with Integrated CVE Scanning and SBOM

TL;DR

• Harbor is an open-source container registry (CNCF Graduated Project) that combines registry functionality, security scanning, SBOM generation, and signing into one system—ideal for cloud-native platforms in regulated environments.
• For the Cyber Resilience Act, the integrated CVE scanning with Trivy, SBOM generation, and image signing are crucial to demonstrably manage vulnerabilities and make software supply chains transparent.
• In the context of the GDPR, features like fine-grained RBAC and audit logs are essential to control access to container images and trace security-relevant activities.
• Through policy-based vulnerability checks, Harbor can be seamlessly integrated into GitLab/GitOps deployments, ensuring that only scanned, signed, and policy-compliant images reach your Kubernetes clusters.
• ayedo uses Harbor as a central component of its own software delivery platform and supports you in pragmatically integrating registry, security scanning, and compliance requirements into your organization—from concept to production operation.

Harbor Overview: More Than Just a Container Registry

Harbor was originally developed as an on-premise alternative to hosted registries like Docker Hub or GitHub Container Registry. It has since become a CNCF Graduated Project and a de facto standard component for companies wanting to operate their software supply chain autonomously and auditable.

Technically, Harbor is a container and artifact registry that can manage:

• containerized applications (images),
• Helm charts,
• and other OCI artifacts.

However, for compliance-driven organizations, it’s not just the pure registry function that matters but the combination with:

• integrated CVE scanning (Trivy),
• SBOM management,
• image signing (Notary),
• and role-based access with audit logs.

This transforms Harbor from a “mere storage” to a central control instance for the integrity and security of your software deliveries—and this is precisely where the project becomes highly relevant for the Cyber Resilience Act and the GDPR.

The Cyber Resilience Act comes into effect on April 3, 2024; most obligations apply from April 3, 2027. It requires, among other things:

• a structured vulnerability management,
• traceability of software components (keyword SBOM),
• and processes for secure updates and patches.

Harbor addresses these points directly at the heart of your container supply chain.

CRA-Relevant Features: Security and Transparency Directly in the Registry

CVE Scanning with Trivy: Security Status as Standard Metadata

A core problem in many organizations: vulnerability scans run somewhere in the CI/CD, results are in PDFs or individual systems—but they are not visible where the images actually reside.

Harbor solves this by integrating CVE scanning via Trivy directly into the registry. Practically, this means:

• Every pushed image for a project can be automatically scanned.
• The results (CVE list, severity levels, affected packages) are directly linked to the image.
• Policies can define which severity levels are allowed before an image is considered “approved.”

In the context of the Cyber Resilience Act, this is a significant advancement:

• You can prove that images are systematically checked before deployment.
• You build a consistent data foundation for your vulnerability management.
• You have a central view of the security status of your artifacts, instead of distributed isolated solutions.

The process perspective is crucial here: Trivy in Harbor is not an additional tool that “also has to run somewhere,” but part of the standard lifecycle of every image. This fits well with an idealistic view of compliance: security as an integral quality aspect, not as a retrospective control.

SBOM Generation: Component Transparency as a Compliance Building Block

The Cyber Resilience Act makes it clear that software manufacturers must provide better transparency about their components in the future. A Software Bill of Materials (SBOM) is intended precisely for this:

• It lists libraries, packages, and dependencies,
• enables quick identification of affected products with new CVEs,
• and serves as a basis for structured risk analyses.

Harbor can generate or manage SBOMs for images and closely link them with the image metadata. This offers several advantages:

• A central repository for SBOMs parallel to the images.
• Direct correlation: “Which SBOM belongs to which image tag?” is clearly answered.
• Basis for automated evaluations (e.g., “Which images contain Log4j version X?”).

In practice, in the CRA context, this means:

• You can maintain SBOMs as part of your technical product documentation.
• In the event of an incident, affected artifacts are quickly identified.
• You reduce manual effort because SBOMs are generated automatically and repeatably.

Image Signing with Notary: Making Integrity and Origin Traceable

Signing container images with Notary creates a cryptographic link between:

• Producer (e.g., your CI/CD pipeline),
• specific image (digest),
• and a trust chain (“Trust Policy”) on your platform.

In Harbor, Notary integration and signature management are firmly anchored. For operations, this means:

• Your build pipeline signs images when pushing to Harbor.
• Harbor stores and manages these signatures.
• Downstream processes (e.g., admission controllers in the Kubernetes cluster) can check whether images are correctly signed.

In terms of the Cyber Resilience Act, this is an important building block to:

• Prevent or quickly detect manipulations along the supply chain,
• clearly trace which pipeline or team built a specific image,
• allow only trusted images in production environments.

Combined with SBOM and CVE scanning, this creates a closed chain from “built → signed → scanned → approved.”

Vulnerability Management: From Individual Findings to Controllable Policies

Harbor not only provides Trivy scan results as raw data but also enables:

• Project-wide policies (“Images with critical vulnerabilities are blocked”),
• an overview of the vulnerability status per project and repository,
• and consistent enforcement of these policies in pull and replication processes.

In regulatory environments, this is particularly valuable:

• You no longer have to rely on manual checklists but can define machine-readable policies.
• Exceptions (e.g., accepted vulnerabilities with documented mitigations) can be handled and documented in a structured manner.
• You define the criteria an image must meet before it enters security-critical environments.

Thus, Harbor becomes the central instance where your CRA compliance for container artifacts is technically enforced.

GDPR-Relevant Features: Access Control and Traceability

The GDPR has been in effect since May 25, 2018, and requires, among other things:

• appropriate technical and organizational measures (Art. 32),
• traceability and accountability,
• and strict access restriction to personal data.

Even though a container registry primarily stores technical artifacts, the applications processed within are often directly or indirectly connected to personal data. Accordingly, protecting these supply chain components is part of a holistic GDPR strategy.

RBAC: Least Privilege in the Registry

Harbor offers fine-grained Role-Based Access Control (RBAC) at the project and artifact level. Typically, roles can be defined such as:

• System-wide administrators,
• Project owners (e.g., for a specialist team),
• Maintainers, developers, guests.

In enterprise scenarios, this adds:

• Integration into central identity providers (LDAP, OIDC),
• Single sign-on and central lifecycle of user accounts,
• Clear separation of responsibilities (e.g., platform team vs. application teams).

From a GDPR perspective, this enables:

• Principle of “least privilege”: Only those who really need images get access.
• Clean separation of development, test, and production areas.
• A clear assignment of responsibilities for repositories and projects.

This strengthens the organizational side of your GDPR compliance: roles, permissions, and responsibilities are mapped within the system itself.

Audit Logs: Who Did What and When?

Harbor logs central actions such as:

• Logins and authentication attempts,
• Push and pull operations,
• Configuration changes (e.g., to projects, replication rules, policies),
• Triggering scans.

These audit logs can be:

• Viewed directly in Harbor,
• or forwarded to central logging systems—such as to Loki on your platform.

In the context of the GDPR, audit logs are relevant in several ways:

• They support accountability: You can prove who accessed security-relevant resources and when.
• In the event of an incident, they assist in forensic analysis and assessing the severity.
• They are a component of technical measures under Art. 32, allowing attacks and misuse to be detected and traced.

Integration into your overall architecture is also important here: Harbor provides the audit data, central logging like with Loki makes it searchable and analyzable—ideally with clear retention periods and access rules that are GDPR-compliant.

Practical Example: Policy-Based Vulnerability Check in the Deployment Process

What does a realistic end-to-end process look like where Harbor plays to its strengths for CRA compliance? Let’s orient ourselves on a setup we often see with customers—and which is also laid out in our own Application Deployment Guide:

• GitLab as source code management and CI/CD,
• a container build engine (e.g., Kaniko or Buildah),
• Harbor as the central registry for images and Helm charts,
• Argo CD for GitOps-based deployment on Kubernetes clusters.

1. Build and Push: The Starting Point of Every Supply Chain

A development team works in feature branches and merges via merge requests into the main branch. After each merge:

• a CI pipeline starts,
• builds a container image of the application,
• and pushes the image into a project in Harbor.

At the same time, a Helm chart is built and also stored in Harbor as an OCI artifact. This bundles images and deployment artifacts in one place.

2. Automatic CVE Scanning and SBOM in Harbor

As soon as the image arrives in Harbor, the registry-side security automation kicks in:

• Harbor automatically triggers a Trivy scan for the new image.
• The scan result status (e.g., “No critical vulnerabilities”) is stored as metadata on the image.
• Optionally, an SBOM is generated and also associated with the image.

This creates a clear truth: the security status of the image is contained in the registry entry itself—not in a separate tool.

3. Policy Check in the CI/CD Pipeline

In the next step, policy-based control comes into play:

• The CI pipeline queries the scan status in Harbor before marking an image as “release-ready”.