Harbor: Container Registry mit integriertem CVE-Scanning und SBOM

TL;DR

• Harbor ist eine Open-Source-Container-Registry (CNCF Graduated Project), die Registry-Funktion, Security-Scanning, SBOM-Generierung und Signierung in einem System bündelt – ideal für Cloud-native Plattformen in regulierten Umgebungen.
• Für den Cyber Resilience Act sind insbesondere das integrierte CVE-Scanning mit Trivy, die SBOM-Erzeugung und Image-Signierung zentral, um Verwundbarkeiten nachweisbar zu managen und Software-Lieferketten transparent zu machen.
• Im Kontext der GDPR sind Features wie feingranulares RBAC und Audit-Logs entscheidend, um Zugriff auf Container-Images kontrollierbar zu machen und sicherheitsrelevante Aktivitäten nachvollziehen zu können.
• Durch policy-basierte Vulnerability-Prüfungen lässt sich Harbor nahtlos in GitLab-/GitOps-Deployments integrieren, sodass nur gescannte, signierte und policy-konforme Images in Ihre Kubernetes-Cluster gelangen.
• ayedo setzt Harbor als zentrale Komponente der eigenen Software Delivery Plattform ein und unterstützt Sie dabei, Registry, Security-Scanning und Compliance-Anforderungen pragmatisch in Ihre Organisation zu integrieren – vom Konzept bis zum produktiven Betrieb.

---

Harbor im Überblick: Mehr als nur eine Container-Registry

Harbor ist ursprünglich als On-Premise-Alternative zu gehosteten Registries wie Docker Hub oder GitHub Container Registry entstanden. Inzwischen ist es ein CNCF Graduated Project und de facto ein Standardbaustein, wenn Unternehmen ihre Software-Lieferkette selbstbestimmt und auditierbar betreiben wollen.

Technisch gesehen ist Harbor eine Container- und Artefakt-Registry, die:

• containerisierte Anwendungen (Images),
• Helm Charts,
• und weitere OCI-Artefakte

verwalten kann. Entscheidend für Compliance-getriebene Organisationen ist aber nicht nur die reine Registry-Funktion, sondern die Kombination mit:

• integriertem CVE-Scanning (Trivy),
• SBOM-Management,
• Image-Signierung (Notary),
• und rollenbasiertem Zugriff mit Audit-Logs.

Damit wird Harbor von einer „reinen Ablage“ zu einer zentralen Kontrollinstanz für die Integrität und Sicherheit Ihrer Softwarelieferungen – und genau an dieser Stelle wird das Projekt für den Cyber Resilience Act und die GDPR hochrelevant.

Der Cyber Resilience Act tritt am 3. April 2024 in Kraft; die meisten Pflichten gelten ab dem 3. April 2027. Er fordert unter anderem:

• ein strukturiertes Vulnerability Management,
• Nachvollziehbarkeit von Software-Komponenten (Stichwort SBOM),
• und Prozesse für sichere Updates und Patches.

Harbor adressiert diese Punkte direkt im Herzen Ihrer Container-Lieferkette.

---

CRA-relevante Features: Security und Transparenz direkt in der Registry

CVE-Scanning mit Trivy: Sicherheitsstatus als Standardmetadatum

Ein Kernproblem in vielen Organisationen: Vulnerability-Scans laufen irgendwo im CI/CD, Ergebnisse liegen in PDFs oder Einzelsystemen – aber sie sind nicht dort sichtbar, wo die Images tatsächlich liegen.

Harbor löst das, indem es das CVE-Scanning über Trivy direkt in die Registry integriert. Praktisch bedeutet das:

• Jedes gepushte Image für ein Projekt kann automatisiert gescannt werden.
• Die Ergebnisse (CVE-Liste, Schweregrade, betroffene Pakete) sind direkt an das Image gebunden.
• Policies können definieren, welche Schweregrade erlaubt sind, bevor ein Image „freigegeben“ gilt.

Im Kontext des Cyber Resilience Act ist das ein großer Fortschritt:

• Sie können nachweisen, dass Images vor dem Deployment systematisch geprüft werden.
• Sie bauen eine konsistente Datengrundlage für Ihr Vulnerability Management auf.
• Sie haben eine zentrale Sicht auf die Sicherheitslage Ihrer Artefakte, statt verteilte Insellösungen.

Wichtig ist hier die Prozessperspektive: Trivy in Harbor ist kein Zusatztool, das „auch noch irgendwo laufen muss“, sondern Teil des Standard-Lebenszyklus jedes Images. Damit passt es gut zu einer idealistischen Vorstellung von Compliance: Sicherheit als integraler Qualitätsaspekt, nicht als nachträgliche Kontrolle.

SBOM-Generierung: Komponenten-Transparenz als Compliance-Baustein

Der Cyber Resilience Act macht deutlich, dass Hersteller von Software künftig eine bessere Transparenz über ihre Komponenten bieten müssen. Eine Software Bill of Materials (SBOM) ist genau dafür gedacht:

• Sie listet Bibliotheken, Pakete und Abhängigkeiten,
• ermöglicht das schnelle Auffinden betroffener Produkte bei neuen CVEs,
• und ist eine Basis für strukturierte Risikoanalysen.

Harbor kann für Images SBOMs erzeugen oder verwalten und diese eng mit den Image-Metadaten verknüpfen. Das bietet mehrere Vorteile:

• Ein zentrales Repository für SBOMs parallel zu den Images.
• Direkte Korrelation: „Welche SBOM gehört zu welchem Image-Tag?“ ist eindeutig beantwortet.
• Grundlage für automatisierte Auswertungen (z. B. „Welche Images enthalten Log4j-Version X?“).

Für die Praxis im CRA-Kontext heißt das:

• Sie können SBOMs als Teil Ihrer technischen Produktdokumentation pflegen.
• Im Incident-Fall sind betroffene Artefakte schnell identifiziert.
• Sie reduzieren manuellen Aufwand, weil SBOMs automatisiert und wiederholbar erzeugt werden.

Image-Signing mit Notary: Integrität und Herkunft nachvollziehbar machen

Die Signierung von Container-Images mit Notary schafft eine kryptografische Bindung zwischen:

• Produzent (z. B. Ihrer CI/CD-Pipeline),
• konkretem Image (Digest),
• und einer Vertrauenskette („Trust Policy“) auf Ihrer Plattform.

In Harbor sind Notary-Integration und Signaturverwaltung fest verankert. Für den Betrieb bedeutet das:

• Ihre Build-Pipeline signiert Images beim Push in Harbor.
• Harbor speichert und verwaltet diese Signaturen.
• Downstream-Prozesse (z. B. Admission Controller im Kubernetes-Cluster) können prüfen, ob Images korrekt signiert sind.

Im Sinne des Cyber Resilience Act ist das ein wichtiger Baustein, um:

• Manipulationen entlang der Lieferkette zu verhindern oder schnell zu erkennen,
• eindeutig nachvollziehen zu können, welche Pipeline oder welches Team ein bestimmtes Image gebaut hat,
• nur vertrauenswürdige Images in produktive Umgebungen zuzulassen.

In Kombination mit SBOM und CVE-Scanning entsteht damit eine geschlossene Kette von „gebaut → signiert → gescannt → freigegeben“.

Vulnerability-Management: Von Einzelbefunden zu steuerbaren Policies

Harbor stellt die Ergebnisse des Trivy-Scans nicht nur als Rohdaten bereit, sondern ermöglicht:

• Projektweite Policies („Images mit kritischen Vulnerabilities werden blockiert“),
• eine Übersicht über den Vulnerability-Status pro Projekt und Repository,
• sowie eine konsequente Durchsetzung dieser Policies in Pull- und Replizierungsprozessen.

In regulatorischen Umfeldern ist besonders wertvoll:

• Sie müssen nicht mehr auf manuelle Checklisten vertrauen, sondern können maschinenlesbare Policies definieren.
• Ausnahmen (z. B. akzeptierte Vulnerabilities mit dokumentierten Mitigations) lassen sich strukturiert handhaben und dokumentieren.
• Sie legen fest, welche Kriterien ein Image erfüllen muss, bevor es in sicherheitskritische Umgebungen gelangt.

So wird Harbor zur zentralen Instanz, an der Ihre CRA-Compliance für Container-Artefakte technisch durchgesetzt wird.

---

GDPR-relevante Features: Zugriffskontrolle und Nachvollziehbarkeit

Die GDPR gilt seit dem 25. Mai 2018 und fordert unter anderem:

• angemessene technische und organisatorische Maßnahmen (Art. 32),
• Nachvollziehbarkeit und Rechenschaftspflicht,
• sowie eine strikte Zugriffsbeschränkung auf personenbezogene Daten.

Auch wenn eine Container-Registry in erster Linie technische Artefakte speichert, sind die darin verarbeiteten Anwendungen oft direkt oder indirekt mit personenbezogenen Daten verbunden. Entsprechend ist der Schutz dieser Supply-Chain-Komponenten Teil einer ganzheitlichen GDPR-Strategie.

RBAC: Least Privilege in der Registry

Harbor bietet ein feingranulares Role-Based Access Control (RBAC) auf Projekt- und Artefaktebene. Typischerweise lassen sich Rollen definieren wie:

• Systemweite Administratoren,
• Projekt-Owner (z. B. für ein Fachteam),
• Maintainer, Developer, Guest.

In Enterprise-Szenarien kommt hinzu:

• Integration in zentrale Identity-Provider (LDAP, OIDC),
• Single Sign-On und zentraler Lifecycle von Benutzerkonten,
• klare Trennung von Zuständigkeiten (z. B. Plattform-Team vs. Applikationsteams).

Aus GDPR-Perspektive ermöglicht das:

• Prinzip „Least Privilege“: Nur wer Images wirklich benötigt, bekommt Zugriff.
• Saubere Trennung von Entwicklungs-, Test- und Produktionsbereichen.
• Eine klare Zuordnung von Verantwortlichkeiten für Repositories und Projekte.

Damit stärkt Harbor die organisatorische Seite Ihrer GDPR-Compliance: Rollen, Berechtigungen und Verantwortlichkeiten werden im System selbst abgebildet.

Audit Logs: Wer hat was wann getan?

Harbor protokolliert zentrale Aktionen wie:

• Logins und Authentifizierungsversuche,
• Push- und Pull-Operationen,
• Konfigurationsänderungen (z. B. an Projekten, Replikationsregeln, Policies),
• das Auslösen von Scans.

Diese Audit-Informationen können Sie:

• direkt in Harbor einsehen,
• oder in zentrale Logging-Systeme weiterleiten – etwa nach Loki auf Ihrer Plattform.

Im Kontext der GDPR sind Audit-Logs in mehrfacher Hinsicht relevant:

• Sie unterstützen die Rechenschaftspflicht: Sie können belegen, wer wann auf sicherheitsrelevante Ressourcen zugegriffen hat.
• Im Incident-Fall helfen sie bei der forensischen Analyse und bei der Beurteilung des Schweregrads.
• Sie sind ein Baustein technischer Maßnahmen nach Art. 32, die Angriffe und Missbrauch erkennen und nachvollziehen lassen.

Wichtig ist auch hier die Integration in Ihre Gesamtarchitektur: Harbor liefert die Audit-Daten, ein zentrales Logging wie mit Loki macht sie durchsuchbar und auswertbar – idealerweise mit klaren Aufbewahrungsfristen und Zugriffsregeln, die wiederum GDPR-konform gestaltet sind.

---

Praktisches Beispiel: Policy-basierte Vulnerability-Prüfung im Deployment-Prozess

Wie sieht ein realistischer End-to-End-Prozess aus, in dem Harbor seine Stärken für CRA-Compliance ausspielt? Orientieren wir uns an einem Setup, wie wir es häufig bei Kunden sehen – und das auch in unserem eigenen Application Deployment Guide angelegt ist:

• GitLab als Source Code Management und CI/CD,
• eine Container-Build-Engine (z. B. Kaniko oder Buildah),
• Harbor als zentrale Registry für Images und Helm Charts,
• Argo CD für GitOps-basiertes Deployment auf Kubernetes-Cluster.

1. Build und Push: Der Startpunkt jeder Lieferkette

Ein Entwicklungsteam arbeitet in Feature-Branches und merged über Merge Requests in den Main-Branch. Nach jedem Merge:

• startet eine CI-Pipeline,
• baut ein Container-Image der Anwendung,
• und pusht das Image in ein Projekt in Harbor.

Gleichzeitig wird ein Helm Chart gebaut und ebenfalls in Harbor als OCI-Artefakt abgelegt. Damit sind Images und Deployment-Artefakte an einem Ort gebündelt.

2. Automatisches CVE-Scanning und SBOM in Harbor

Sobald das Image in Harbor ankommt, greift die Registry-seitige Security-Automatisierung:

• Harbor triggert automatisch einen Trivy-Scan für das neue Image.
• Der Scan-Ergebnisstatus (z. B. „Keine kritischen Vulnerabilities“) wird als Metadatum am Image gespeichert.
• Optional wird eine SBOM generiert und ebenfalls dem Image zugeordnet.

So entsteht eine klare Wahrheit: Der Sicherheitsstatus des Images ist im Registry-Eintrag selbst enthalten – und nicht in einem separaten Tool.

3. Policy-Prüfung in der CI/CD-Pipeline

Im nächsten Schritt kommt die Policy-basierte Steuerung ins Spiel:

• Die CI-Pipeline fragt vor der Markierung eines Images als „release-ready“ den Scan-Status in Harbor ab.
• Eine organisatorisch definierte Policy (z. B. „Keine kritischen oder hohen Vulnerabilities in produktionsrelevanten Images“) wird angewendet.
• Erfüllt das Image die Policy nicht, schlägt die Pipeline fehl und es wird kein Tag vergeben, der für produktive Deployments verwendet wird.

Wichtig: Die Policy ist nicht „nur“ Dokument, sondern maschinenlesbar im Build-Prozess verankert. Das reduziert den Interpretationsspielraum und schafft klare, überprüfbare Regeln – exakt das, was Regulierer im Rahmen des Cyber Resilience Act erwarten.

4. Signierung und Vertrauensketten

Parallel zur Policy-Prüfung signiert die CI-Pipeline das Image:

• Die Signatur wird in Harbor gespeichert.
• Argo CD oder ein Admission Controller im Kubernetes-Cluster prüfen bei Deployments, ob Images aus Harbor korrekt signiert sind und von vertrauenswürdigen Schlüsseln stammen.

Nur Images, die sowohl signiert als auch als policy-konform markiert sind, passieren den Admission-Check. Dadurch wird Ihre Kubernetes-Landschaft zu einer „Zero-Trust“-Umgebung für Container-Images: Ohne Signatur und bestandene Security-Policy kein Deployment.

5. GitOps-Deployment mit Argo CD

Auf GitOps-Ebene liegt die gewünschte Systemkonfiguration (z. B. Helm Values, Zielversionen) in einem Git-Repository. Argo CD:

• liest regelmäßig den Stand aus Git,
• synchronisiert diesen mit dem Ziel-Cluster,
• zieht dabei die Images aus Harbor.

Da die Images im Git-Repo nur über freigegebene Tags referenziert werden, ist sichergestellt:

• dass nur zuvor geprüfte und signierte Images in den Clustern ankommen,
• und dass jedes Deployment auf eine nachvollziehbare CI/CD-Pipeline zurückzuführen ist.

Im Ergebnis:

• Sie haben eine lückenlose Kette von Source Code über Build, Scan, Signierung bis zum Deployment.
• Sie können für jedes produktive Image nachweisen, dass es durch einen definierten, policy-basierten Prozess gegangen ist.
• Vulnerabilities, SBOMs und Audit-Informationen sind an einem zentralen Punkt – Harbor – verfügbar.

So wird Harbor faktisch zur operativen Drehscheibe Ihrer CRA- und Security-Compliance im Container-Umfeld.

---

Häufige Fragen

Brauchen wir Harbor, wenn wir bereits eine gehostete Registry (z. B. ECR, GCR) nutzen?

Gehostete Registries der großen Hyperscaler sind technisch solide und bequem. Die Frage ist weniger „Entweder-oder“, sondern:

• Wie viel Kontrolle und Transparenz benötigen Sie entlang der gesamten Lieferkette?
• Welche Funktionen wollen Sie zentral bündeln, statt sie auf mehrere Services zu verteilen?

Harbor bietet Ihnen:

• integriertes CVE-Scanning (Trivy) direkt an der Registry,
• SBOM-Verwaltung und Image-Signierung,
• einheitliche Policies projektübergreifend,
• und die Option, die Registry vollständig in Ihrer eigenen Infrastruktur zu betreiben.

Für viele Organisationen in Europa ist gerade die Kombination aus technischer Tiefe und Souveränität – unabhängig vom Hyperscaler – ein entscheidender Faktor, insbesondere mit Blick auf den Cyber Resilience Act und die GDPR.

Wie integrieren wir Harbor-Scans sinnvoll in unsere bestehenden CI/CD-Pipelines?

Die Erfahrung zeigt: Der sinnvollste Ansatz ist, den Security-Status als integrales Metadatum im Lifecycle zu betrachten, nicht als separaten Schritt „am Rand“.

Typischer Ablauf:

1. CI/CD-Pipeline baut das Image und pusht es nach Harbor.
2. Harbor scannt das Image automatisch per Trivy.
3. Die Pipeline fragt, bevor ein „release“-Tag vergeben oder ein GitOps-Repo aktualisiert wird, den Scan-Status über Harbor-APIs ab.
4. Auf Basis einer gemeinsamen Policy (z. B. nach CVSS-Scores, Paketen, Compliance-Anforderungen) entscheidet die Pipeline objektiv: freigeben oder blockieren.

Damit vermeiden Sie doppelte Scans und verteilen keine Sicherheitslogik auf mehrere Tools. Alles, was für die Sicherheitsfreigabe zählt, ist direkt an das Image in Harbor gebunden.

Wie unterstützt ayedo konkret bei Harbor-Betrieb und CRA-Compliance?

ayedo setzt Harbor als zentrale Registry-Komponente in der eigenen Software Delivery Plattform ein und kennt die operativen Herausforderungen aus erster Hand:

• Wir designen Registry-Architekturen, die zu Ihren Sicherheits- und Compliance-Zielen passen – inklusive High Availability, Netzwerk-Segmentierung und Integration in Ihre Identitätsinfrastruktur.
• Wir integrieren Harbor eng mit CI/CD (z. B. GitLab), GitOps (Argo CD) und zentralem Logging (z. B. Loki), sodass CVE-Scanning, SBOMs und Signaturen im Alltag tatsächlich genutzt werden, statt nur „auf dem Papier“ zu existieren.
• Wir unterstützen Sie bei der Ableitung von Policies aus regulatorischen Anforderungen (CRA, GDPR) und übersetzen diese in konkrete technische Kontrollen in Harbor und Ihrer Plattform.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Harbor zeigt exemplarisch, wie sich regulatorische Anforderungen und moderne Cloud-native Architektur nicht widersprechen, sondern gegenseitig verstärken können. Eine Registry, die nicht nur speichert, sondern:

• CVEs sichtbar macht und per Policy adressiert,
• SBOMs verwaltet und damit Transparenz schafft,
• Signaturen durchsetzt und die Herkunft von Software absichert,
• sowie Rollen, Rechte und Audit-Logs sauber abbildet,

ist ein idealer Ankerpunkt, um den Cyber Resilience Act und die GDPR in Ihrer technischen Realität zu verankern.

In der Praxis ist der Weg dorthin selten eine Big-Bang-Migration. Erfolgreiche Organisationen gehen schrittweise vor:

1. Harbor als zentrale Registry etablieren
   Zunächst wird Harbor als verlässliche Registry eingeführt – mit klarer Projektstruktur, integriert in Ihr Identity-Management und Ihre Netzwerktopologie.

2. Scans und SBOMs in den Standard-Lifecycle aufnehmen
   Danach werden Trivy-Scans und SBOM-Generierung zum Standardbestandteil jedes Builds. Anstatt zusätzliche Tools einzuführen, wird die vorhandene Harbor-Funktionalität systematisch genutzt.

3. Policy-basierte Freigabeprozesse aufbauen
   Im nächsten Schritt werden Sicherheitsanforderungen (etwa aus dem Cyber Resilience Act) in konkrete, maschinenlesbare Policies übersetzt, die Ihre CI/CD-Pipelines durchsetzen.

4. Signaturen und Admission-Kontrollen etablieren
   Schließlich werden Signaturen verbindlich gemacht und Admission-Kontrollen auf Ihren Kubernetes-Clustern aktiv, sodass nur noch geprüfte, signierte Images deployt werden.

ayedo begleitet diesen Weg ganz bewusst aus einer europäischen Perspektive: mit dem Anspruch, technische Exzellenz, wirtschaftliche Wettbewerbsfähigkeit und regulatorische Anforderungen zu verbinden. In unserer Software Delivery Plattform ist Harbor daher fest eingebettet – inklusive:

• Integration mit GitLab, Argo CD, Loki und weiteren Bausteinen,
• automatisierten Guardrails für CVE-Scanning und SBOM-Handling,
• sowie Betriebs- und Supportmodellen, die den Dauerbetrieb in kritischen Umgebungen absichern.

Wenn Sie Harbor als zentrales Element Ihrer CRA-konformen Lieferkette etablieren möchten, stehen wir Ihnen gerne mit Architekturberatung, Implementierung und Betrieb zur Seite – von der ersten Proof-of-Concept-Umgebung bis zur produktiven, hochverfügbaren Registry-Landschaft.

Den Einstieg erleichtert unser kompakter Leitfaden zur Inbetriebnahme und Integration von Harbor in Ihre bestehende Plattform: Harbor Setup Guide