Harbor Deep Dive: Vulnerability Scanning, SBOM, Image Signing

TL;DR

• A modern container registry is now a central compliance tool, especially in the context of the Cyber Resilience Act, NIS-2, and DORA.
• Harbor combines vulnerability scanning (Trivy), SBOM management (SPDX, CycloneDX), and image signing (Notary, Cosign) with enterprise features like replication, quotas, RBAC, and audit logs—ideal for structured management of supply chain risks.
• For the Cyber Resilience Act (effective since May 20, 2024, with most obligations applicable from 2027), SBOMs, coordinated vulnerability disclosure processes, and signed artifacts are particularly relevant—areas where Harbor can provide substantial support.
• NIS-2 (effective since January 16, 2023, to be implemented into national law by October 17, 2024) and DORA (applicable from January 17, 2025) demand more transparency and control in the ICT supply chain—Harbor provides traceable artifact histories, policies, and auditability.
• ayedo plans, builds, and operates Harbor instances as part of an integrated compliance-capable platform—including policy design, vulnerability management workflows, and secure Harbor configuration.

Why the Container Registry Becomes a Key Compliance Component

Container images are now the primary delivery format for software. This means a large portion of security and compliance-relevant information moves into the registry: vulnerabilities, dependencies, licenses, provenance.

Regulatory pressure is increasing:

• The Cyber Resilience Act (CRA) requires documented security processes, SBOMs, and signed updates.
• NIS-2 demands stronger control over ICT supply chains and components from many critical and important entities.
• DORA specifically addresses financial institutions and their ICT third-party risks, including traceability and control of external software deliveries.

Those who take these requirements seriously need a registry that is more than just a “Docker Hub on-prem.” This is where Harbor comes in: a cloud-native registry with deeply integrated security and compliance functions.

Harbor Overview: Role in the Supply Chain

Harbor is an advanced container registry for images, charts, and other OCI artifacts. Typically, Harbor sits at the center of your software delivery chain, embedded in CI/CD (e.g., GitLab CI) and deployment tools like Argo CD or other GitOps solutions.

Key features:

• Management of projects, repositories, and artifacts (images, SBOMs, signatures, attestations)
• Integration of security functions: vulnerability scanning, policy enforcement, image signing
• Enterprise capabilities: multi-tenancy, RBAC, quota management, replication, audit logs

For a regulation-compliant platform, the combination is crucial: not only scanning but also documenting, restricting, logging—and doing so consistently across all teams.

Vulnerability Scanning with Harbor and Trivy

How Harbor and Trivy Work Together

Harbor integrates the Trivy scanner as standard. Trivy analyzes container images for known vulnerabilities (CVEs) in:

• Operating system packages
• Programming language ecosystems (e.g., npm, pip, Maven)
• Configuration artifacts (depending on setup)

Key features:

• Automatic scanning on push: Every new or updated image is scanned immediately upon arrival.
• Periodic rescans: As new CVEs are continuously reported, regular rescans can be configured to check existing images against current databases.
• Granular results: CVE IDs, packages, versions, severity (e.g., Critical, High, Medium).

Policy-Based Vulnerability Management

The real value comes from policies based on scan results. Practical patterns:

• Pull restriction by severity:
  Only images without “Critical” or “High” vulnerabilities may be pulled or promoted to production-like projects.
• Promotion gates:
  An image may only be moved from “Dev” to “Staging” or “Production” if defined thresholds are met.
• Project-specific policies:
  Particularly regulated applications (e.g., financial products under DORA) can have stricter rules than internal tools.

In the CRA context, this directly ties into the required coordinated vulnerability disclosure (CVD): You can demonstrate that:

• Vulnerabilities are systematically detected,
• Managed based on risk (e.g., blocking policies for critical CVEs),
• Historical decisions remain traceable (via audit logs, see below).

For NIS-2 and DORA, such a setup demonstrably supports the management of supply chain risks: not just in the cluster, but upfront in the supply chain at the registry boundary.

SBOM in Harbor: SPDX and CycloneDX as Transparency Foundation

The CRA places explicit emphasis on transparency over software components. An SBOM (Software Bill of Materials) in formats like SPDX or CycloneDX is the central tool here.

How SBOMs Are Represented in Harbor

Harbor itself does not necessarily generate all SBOMs; rather, it orchestrates their storage and association:

• SBOMs are typically generated in the CI pipeline (e.g., via Trivy, Syft, or other tools).
• These SBOMs are pushed to Harbor as additional OCI artifacts along with the image.
• Harbor links the SBOM artifacts with the referenced image (digest-based) and makes them accessible via the user interface and APIs.

Key advantages:

• Consolidated view: It is centrally visible for each image which components and licenses are included.
• Machine-readable formats: SPDX and CycloneDX allow automated evaluation, e.g., for license compliance or quick impact analyses for new CVEs.
• Auditability: You can demonstrate to auditors that SBOMs exist and are kept up-to-date for images in production.

Regulatory Reference

• The Cyber Resilience Act requires manufacturers to document components and their security status throughout the lifecycle. SBOMs in Harbor are a very direct means of fulfilling this obligation.
• Under NIS-2, operators of critical services are particularly encouraged to know and control dependencies in the supply chain. SBOMs linked with images in Harbor provide exactly this transparency.
• For DORA, they provide a solid data foundation to assess ICT third-party risk, especially when external providers upload their images to your registry.

Image Signing: Notary, Cosign, and Chain of Trust

Signed artifacts are a central element in the CRA: Updates and delivered software must be traceable to a responsible manufacturer, and their integrity must be verifiable.

Functionality in Harbor

Harbor supports multiple mechanisms for image signing:

• Notary / Notation (v2): The “classic” signature infrastructure, deeply integrated with the registry world.
• Cosign: A modern approach that stores signatures and other attestations as OCI artifacts alongside the image.

In both cases, Harbor can:

• Bind signatures to images and display their validity.
• Define policies that block unsigned or invalidly signed images in certain projects.
• Manage attestations (e.g., “This image was built by this CI pipeline with these security checks”).

Signature Policies

Typical policy patterns:

• Signature requirement for production projects: Only signed images may exist in “Prod” projects or be pulled from there.
• Trust anchors per team/manufacturer: Define per project which signing keys or identities are considered trust anchors.
• Combination with vulnerability policies:
  “Only signed images without critical vulnerabilities may be promoted to production.”

This directly connects to the CRA (signed updates, provenance) and supports DORA requirements: In a financial organization, for example, you can establish policies that only images from signed, approved third parties may be pulled from the registry into production Kubernetes clusters.

Enterprise Features with Compliance Added Value: Replication, Quotas, RBAC, Audit Logs

In addition to core security functions, Harbor offers a range of enterprise features that are crucial for compliance topics.

Replication: Sovereignty and Resilience

Harbor can replicate artifacts between different instances:

• Geographical distribution: e.g., EU-only replication for data and legal sovereignty.
• Air-gapped environments: controlled synchronization of images from an “internet-near” registry to an isolated production domain.
• Supplier connection: Manufacturer registries can replicate certain projects into the customer domain.

This supports both CRA requirements for update and patch management and NIS-2 and DORA guidelines on resilience and business continuity.

Quota Management: Resource Control and Cleanup

Quota management is not just cost control:

• Limiting per project prevents “image dumps” without maintenance.
• Coupled with retention policies, you can enforce that only currently reviewed images are retained.
• This facilitates the CRA requirement to keep track of old versions and their risks—or consciously remove them from active inventory.

RBAC: Controlled Responsibilities

Harbor offers granular Role Based Access Control:

• Roles at the project level (Viewer, Developer, Maintainer, Project Admin, etc.)
• Integration with corporate identity sources (LDAP, OIDC, SSO)

This allows you to clearly separate responsibilities:

• Development teams may push images but not change security policies.
• Security/compliance teams manage global policies and scanning configuration.
• Operations teams control replication and interfaces to production environments.

This clear assignment of responsibilities is very helpful for compliance evidence under NIS-2 and DORA.

Audit Logs: Traceability Instead of Gut Feeling

Harbor logs all relevant actions:

• Logins and authentication events
• Pushes, pulls, deletions, tag changes
• Policy changes, replication operations, project management

These audit logs are:

• A direct basis for forensic analysis in security incidents.
• An important artifact for compliance audits (“Who changed which policy when?”, “When was this image adopted into production?”).
• A component for the CRA requirement to document the lifecycle of security measures.

Practical Example: A Harbor Policy for Vulnerability Management

How could an entry-level but regulatory-compliant vulnerability management setup with Harbor look? A possible, practical setup:

1. Define Risk Categories and SLAs

At the organizational level:

• Determine which CVSS severity levels are acceptable (e.g., “Critical: never allowed”, “High: only with documented exception and short-term remediation”).
• Add business context (e.g., stricter requirements for product-relevant microservices compared to internal tools).
• Define SLAs for remediation (e.g., Critical ≤ 7 days, High ≤ 30 days, Medium ≤ 90 days).

2. Derive Harbor Policies per Project

In Harbor:

• Automa