Harbor Deep Dive: Vulnerability-Scanning, SBOM, Image-Signing

TL;DR

• Eine moderne Container Registry ist heute ein zentrales Compliance-Werkzeug – insbesondere im Kontext von Cyber Resilience Act, NIS-2 und DORA.
• Harbor kombiniert Vulnerability-Scanning (Trivy), SBOM-Verwaltung (SPDX, CycloneDX) und Image-Signing (Notary, Cosign) mit Enterprise-Features wie Replication, Quotas, RBAC und Audit Logs – ideal, um Supply-Chain-Risiken strukturiert zu steuern.
• Für den Cyber Resilience Act (in Kraft seit 20. Mai 2024, Anwendung der meisten Pflichten ab 2027) sind insbesondere SBOMs, koordinierte Vulnerability-Disclosure-Prozesse und signierte Artefakte relevant – alles Bereiche, in denen Harbor sehr konkret unterstützen kann.
• NIS-2 (seit 16. Januar 2023 in Kraft, Umsetzung in nationales Recht bis 17. Oktober 2024) und DORA (anwendbar ab 17. Januar 2025) verlangen mehr Transparenz und Steuerung in der IKT-Lieferkette – Harbor liefert hier nachvollziehbare Artefakt-Historien, Richtlinien und Prüfbarkeit.
• ayedo plant, baut und betreibt Harbor-Instanzen als Bestandteil einer integrierten Compliance-fähigen Plattform – inklusive Policy-Design, Vulnerability-Management-Workflows und sicherer Harbor Configuration.

---

Warum die Container Registry zur Compliance-Schlüsselkomponente wird

Container-Images sind heute das primäre Auslieferungsformat für Software. Damit wandert ein großer Teil der sicherheits- und compliance-relevanten Informationen in die Registry: Vulnerabilities, Abhängigkeiten, Lizenzen, Provenance.

Regulatorisch verdichtet sich das:

• Der Cyber Resilience Act (CRA) verlangt u. a. dokumentierte Sicherheitsprozesse, SBOMs und signierte Updates.
• NIS-2 fordert von vielen kritischen und wichtigen Einrichtungen eine stärkere Kontrolle über IKT-Lieferketten und eingesetzte Komponenten.
• DORA adressiert speziell Finanzinstitute und deren IKT-Drittparteirisiken, inklusive Nachvollziehbarkeit und Steuerung externer Softwarelieferungen.

Wer diese Anforderungen ernst nimmt, braucht eine Registry, die mehr ist als ein „Docker Hub on-prem“. Genau hier setzt Harbor an: eine Cloud-native Registry mit tief integrierten Security- und Compliance-Funktionen.

---

Harbor im Überblick: Rolle in der Supply Chain

Harbor ist eine erweiterte Container Registry für Images, Charts und weitere OCI-Artefakte. Typischerweise sitzt Harbor im Zentrum Ihrer Softwarelieferkette, eingebettet in CI/CD (z. B. GitLab CI) und Deployment-Werkzeuge wie Argo CD oder andere GitOps-Lösungen.

Wesentliche Eigenschaften:

• Verwaltung von Projekten, Repositories und Artefakten (Images, SBOMs, Signaturen, Attestations)
• Integration von Security-Funktionen: Vulnerability-Scanning, Policy-Enforcement, Image-Signing
• Enterprise-Fähigkeiten: Multi-Tenancy, RBAC, Quota Management, Replication, Audit Logs

Für eine regulierungsfeste Plattform ist die Kombination entscheidend: nicht nur scannen, sondern auch dokumentieren, einschränken, protokollieren – und das über alle Teams hinweg konsistent.

---

Vulnerability-Scanning mit Harbor und Trivy

Wie Harbor und Trivy zusammenspielen

Harbor integriert den Scanner Trivy als Standard. Trivy analysiert Container-Images auf bekannte Schwachstellen (CVEs) in:

• Betriebssystempaketen
• Programmiersprachen-Ökosystemen (z. B. npm, pip, Maven)
• Konfigurationsartefakten (je nach Setup)

Zentrale Merkmale:

• Automatisches Scannen beim Push: Jedes neue oder aktualisierte Image wird direkt beim Eintreffen gescannt.
• Periodische Rescans: Da neue CVEs laufend gemeldet werden, können regelmäßige Rescans konfiguriert werden, um bestehende Images gegen aktuelle Datenbanken zu prüfen.
• Feingranulare Ergebnisse: CVE-IDs, Pakete, Versionen, Schweregrad (z. B. Critical, High, Medium).

Policy-basiertes Vulnerability-Management

Der eigentliche Mehrwert entsteht durch Policies, die auf den Scan-Ergebnissen aufbauen. Praxisnahe Muster:

• Pull-Restriktion nach Schweregrad:
  Nur Images ohne „Critical“ oder „High“ Vulnerabilities dürfen in produktionsnahe Projekte gezogen oder promotet werden.
• Promotion-Gates:
  Ein Image darf nur von „Dev“ nach „Staging“ oder „Production“ verschoben werden, wenn definierte Schwellenwerte eingehalten werden.
• Projekt-spezifische Policies:
  Besonders regulierte Anwendungen (z. B. Finanzprodukte unter DORA) können strengere Regeln erhalten als interne Tools.

Im CRA-Kontext spielt das direkt in die geforderte koordinierte Vulnerability-Disclosure (CVD) hinein: Sie können nachweisen, dass:

• Schwachstellen systematisch detektiert werden,
• Risiko-basiert behandelt werden (z. B. blockierende Policies für kritische CVEs),
• historische Entscheidungen nachvollziehbar bleiben (über Audit Logs, siehe unten).

Für NIS-2 und DORA unterstützt ein solches Setup nachweislich das Management von Supply-Chain-Risiken: nicht nur im Cluster, sondern vorne in der Lieferkette an der Registry-Grenze.

---

SBOM in Harbor: SPDX und CycloneDX als Transparenzgrundlage

Der CRA legt explizit Wert auf Transparenz über Softwarekomponenten. Eine SBOM (Software Bill of Materials) in Formaten wie SPDX oder CycloneDX ist hier das zentrale Werkzeug.

Wie SBOMs in Harbor abgebildet werden

Harbor selbst generiert nicht zwingend alle SBOMs; vielmehr orchestriert es deren Speicherung und Zuordnung:

• SBOMs werden typischerweise bereits in der CI-Pipeline erzeugt (z. B. per Trivy, Syft oder anderen Tools).
• Diese SBOMs werden als zusätzliche OCI-Artefakte zusammen mit dem Image nach Harbor gepusht.
• Harbor verknüpft die SBOM-Artefakte mit dem referenzierten Image (Digest-basiert) und macht sie über die Benutzeroberfläche und APIs abrufbar.

Wesentliche Vorteile:

• Konsolidierte Sicht: Für jedes Image ist zentral ersichtlich, welche Komponenten und Lizenzen enthalten sind.
• Maschinenlesbare Formate: SPDX und CycloneDX erlauben automatisierte Auswertung, z. B. für Lizenz-Compliance oder schnelle Impact-Analysen bei neuen CVEs.
• Auditierbarkeit: Sie können gegenüber Auditoren belegen, dass für produktiv eingesetzte Images SBOMs existieren und aktuell gehalten werden.

Regulatorischer Bezug

• Der Cyber Resilience Act verlangt von Herstellern u. a. eine Dokumentation der Komponenten und deren Sicherheitsstatus über den gesamten Lebenszyklus. SBOMs in Harbor sind ein sehr direktes Mittel, diese Pflicht umzusetzen.
• Unter NIS-2 werden insbesondere Betreiber kritischer Dienste angehalten, Abhängigkeiten in der Lieferkette zu kennen und zu steuern. SBOMs, die mit Images in Harbor verknüpft sind, liefern genau diese Transparenz.
• Für DORA liefern sie eine harte Datengrundlage, um das IKT-Drittparteirisiko zu bewerten, insbesondere wenn externe Provider ihre Images in Ihre Registry einstellen.

---

Image-Signing: Notary, Cosign und Vertrauenskette

Signierte Artefakte sind ein zentrales Element im CRA: Updates und ausgelieferte Software müssen eindeutig auf einen verantwortlichen Hersteller zurückgeführt werden können, und ihre Integrität muss überprüfbar sein.

Funktionsprinzip in Harbor

Harbor unterstützt mehrere Mechanismen für Image-Signing:

• Notary / Notation (v2): Die „klassische“ Signaturinfrastruktur, tief mit der Registry-Welt verzahnt.
• Cosign: Ein moderner Ansatz, der Signaturen und weitere Attestations als OCI-Artefakte neben dem Image speichert.

In beiden Fällen kann Harbor:

• Signaturen an Images binden und deren Gültigkeit anzeigen.
• Policies definieren, die unsignierte oder ungültig signierte Images in bestimmten Projekten blockieren.
• Attestations (z. B. „Dieses Image wurde durch diese CI-Pipeline mit diesen Sicherheitsprüfungen gebaut“) verwalten.

Policies für Signaturen

Typische Policy-Muster:

• Signaturpflicht für produktive Projekte: Nur signierte Images dürfen in „Prod“-Projekten existieren oder von dort gezogen werden.
• Vertrauensanker je Team/Hersteller: Pro Projekt definieren Sie, welche Signierschlüssel oder Identitäten als Vertrauensanker gelten.
• Kombination mit Vulnerability-Policies:
  „Nur signierte Images ohne kritische Vulnerabilities dürfen nach Produktion promotet werden.“

Das schließt direkt an den CRA an (signierte Updates, Herkunftsnachweis) und unterstützt DORA-Anforderungen: Sie können in einer Finanzorganisation z. B. Richtlinien etablieren, dass nur Images signierter, zugelassener Drittparteien aus der Registry in produktive Kubernetes-Cluster gezogen werden dürfen.

---

Enterprise-Features mit Compliance-Mehrwert: Replication, Quotas, RBAC, Audit Logs

Neben den Security-Kernfunktionen bietet Harbor eine Reihe von Enterprise-Features, die für Compliance-Themen entscheidend sind.

Replication: Souveränität und Resilienz

Harbor kann Artefakte zwischen verschiedenen Instanzen replizieren:

• Geografische Verteilung: z. B. EU-only-Replikation für Daten- und Rechtssouveränität.
• Air-gapped-Umgebungen: kontrollierte Synchronisation von Images von einer „Internet-nahen“ Registry in eine isolierte Produktionsdomäne.
• Lieferantenanbindung: Hersteller-Registries können bestimmte Projekte in die Kundendomäne replizieren.

Das unterstützt sowohl CRA-Anforderungen an Update- und Patch-Management als auch NIS-2- und DORA-Vorgaben zu Resilienz und Betriebsfortführung.

Quota Management: Ressourcenkontrolle und Bereinigung

Quota Management ist nicht nur Kostenkontrolle:

• Begrenzung pro Projekt verhindert „Image-Müllhalden“ ohne Wartung.
• Gekoppelt mit Retention Policies können Sie erzwingen, dass nur noch aktuell geprüfte Images vorgehalten werden.
• Das erleichtert im CRA-Kontext die Pflicht, auch alte Versionen und deren Risiko im Blick zu behalten – oder bewusst aus dem aktiven Bestand zu entfernen.

RBAC: Kontrollierte Verantwortlichkeiten

Harbor bietet feingranulares Role Based Access Control:

• Rollen auf Projektebene (Viewer, Developer, Maintainer, Project Admin etc.)
• Integration mit Unternehmens-Identitätsquellen (LDAP, OIDC, SSO)

Damit können Sie Verantwortlichkeiten sauber trennen:

• Entwicklungsteams dürfen Images pushen, aber nicht Security-Policies ändern.
• Security-/Compliance-Teams verwalten Globale Policies und Scanning-Konfiguration.
• Betriebs-Teams kontrollieren Replikation und Schnittstellen zu Produktionsumgebungen.

Diese klare Zuordnung von Zuständigkeiten ist für Compliance-Nachweise unter NIS-2 und DORA sehr hilfreich.

Audit Logs: Nachvollziehbarkeit statt Bauchgefühl

Harbor protokolliert alle relevanten Aktionen:

• Logins und Authentifizierungsereignisse
• Pushes, Pulls, Deletionen, Tag-Änderungen
• Policy-Änderungen, Replikationsoperationen, Projektverwaltung

Diese Audit Logs sind:

• Eine direkte Grundlage für forensische Analysen bei Sicherheitsvorfällen.
• Ein wichtiges Artefakt für Compliance-Audits („Wer hat wann welche Policy geändert?“, „Wann wurde dieses Image in Produktion übernommen?“).
• Ein Baustein für die CRA-Anforderung, den Lebenszyklus von Sicherheitsmaßnahmen zu dokumentieren.

---

Praktisches Beispiel: Eine Harbor-Policy für Vulnerability-Management

Wie könnte ein einstiegsfreundliches, aber regulatorisch tragfähiges Vulnerability-Management mit Harbor aussehen? Ein mögliches, praxistaugliches Setup:

1. Risikokategorien und SLAs definieren

Organisationsebene:

• Festlegen, welche CVSS-Schweregrade akzeptabel sind (z. B. „Critical: nie erlaubt“, „High: nur mit dokumentierter Ausnahme und kurzfristiger Behebung“).
• Ergänzen um Business-Kontext (z. B. strengere Vorgaben für produktrelevante Microservices im Vergleich zu internen Tools).
• SLAs für Behebung definieren (z. B. Critical ≤ 7 Tage, High ≤ 30 Tage, Medium ≤ 90 Tage).

2. Harbor-Policies je Projekt ableiten

In Harbor:

• Automatisches Scannen beim Push für alle Projekte aktivieren.
• Für produktionsnahe Projekte festlegen:
  • Pulls oder Promotions sind blockiert, wenn „Critical“ Vulnerabilities vorhanden sind.
  • „High“ Vulnerabilities lösen einen „Warn“-Status aus, der einen manuellen Freigabeprozess erfordert.
• Für Entwicklungsprojekte können anfangs weichere Regeln gelten, um Teams nicht zu blockieren, aber frühzeitig Transparenz zu liefern.

3. CI/CD in die Verantwortung nehmen

Im CI/CD-System:

• Images werden nur dann mit einem „prod“-Tag versehen, wenn der letzte Harbor-Scan die definierten Schwellen einhält.
• SBOM-Erzeugung und Image-Signing sind Pflichtschritte vor dem Push nach Harbor.
• Ausnahmen (z. B. unvermeidbare „High“-Vulnerabilities in Third-Party-Software) werden nachvollziehbar dokumentiert und im Ticket-System verlinkt.

4. Operatives Vulnerability-Management etablieren

Security- und Plattform-Teams:

• Nutzen die Harbor-Oberfläche und APIs, um regelmäßig Berichte über kritische und hohe Vulnerabilities je Projekt zu ziehen.
• Etablieren ein regelmäßiges „Security-Review“ mit den verantwortlichen Produktteams.
• Mappen Harbor-Daten auf regulatorische Berichte, etwa im Kontext NIS-2 oder DORA.

Diese Kombination aus Tooling (Harbor, Trivy, Policies) und Prozess (SLAs, Reviews, Ausnahmemanagement) schafft eine belastbare Grundlage, um CRA- und NIS-2-Anforderungen nicht nur formal, sondern substanziell zu erfüllen.

---

Häufige Fragen

Brauche ich Registry-Scanning in Harbor, wenn ich bereits Cluster-Scanning einsetze?

Ja, Registry-Scanning ergänzt Cluster-Scanning, ersetzt es aber nicht.
Cluster-Scanning zeigt Ihnen, welche Schwachstellen tatsächlich in laufenden Pods vorhanden sind. Registry-Scanning in Harbor:

• greift früher ein (beim Push und vor Deployment),
• ermöglicht Policy-gesteuerte Promotion-Gates,
• ist besser geeignet für Compliance-Dokumentation, weil es eine vollständige Historie der Images und ihrer Sicherheitszustände erhält.

Für CRA-, NIS-2- und DORA-konforme Setups ist die Kombination aus Registry- und Laufzeit-Scanning der robusteste Ansatz.

Wie gehe ich mit bestehenden „Legacy“-Images um, die neue Policies verletzen?

Ein pragmatischer Weg:

1. Bestehende Images einmalig scannen und ein initiales Risikoprofil erstellen.
2. Kritische und High-Risiken priorisieren und eine Migrations-Roadmap definieren.
3. Harbor-Policies so konfigurieren, dass neue Images sofort den strengeren Regeln folgen, während für Bestandsartefakte temporäre Ausnahmen gelten.
4. Mit jeder neuen Version wird konsequent auf die neuen Policies migriert, bis Legacy-Bestände auslaufen.

Wichtig ist Transparenz: Harbor liefert mit Scan-Historie und Audit Logs die Daten, um gegenüber Auditoren den Migrationspfad zu belegen.

Wie unterstützt ayedo beim Aufbau einer Harbor-basierten Compliance-Architektur?

ayedo begleitet Organisationen entlang der gesamten Kette:

• Architektur-Design: Einbettung von Harbor in Ihre Plattform, inklusive Integration mit CI/CD, Identity, Secrets und Kubernetes.
• Umsetzung: Installation, Härtung und Policy-Definition für Harbor inklusive Vulnerability-Management, SBOM-Handling und Image-Signing.
• Betrieb & Weiterentwicklung: Monitoring, Upgrades, Anpassung an neue regulatorische Anforderungen (z. B. detailliertere CRA-Leitlinien) und laufende Optimierung der Prozesse.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Harbor zeigt, wie sich technische Exzellenz und regulatorische Anforderungen produktiv verbinden lassen: Eine zentrale Stelle für Images, SBOMs, Signaturen, Scans und Protokolle – und damit ein belastbares Fundament für Ihre Compliance-Strategie unter Cyber Resilience Act, NIS-2 und DORA.

Die eigentliche Herausforderung liegt selten in der Technologie allein, sondern in der sauberen Verzahnung:

• Wie sehen sinnvolle, risikobasierte Policies für unterschiedliche Anwendungsdomänen aus?
• Wie greifen Harbor-Policies, CI/CD-Pipelines und organisatorische Prozesse ineinander?
• Wie dokumentieren Sie das Ergebnis so, dass Ihre Compliance- und Revisionsteams damit arbeiten können?

Genau hier setzt ayedo an. Wir entwickeln gemeinsam mit Ihren Technik- und Compliance-Verantwortlichen eine Architektur, in der Harbor als integraler Teil Ihrer Plattform funktioniert – inklusive:

• Sicherer Basiskonfiguration und Härtung der Registry
• Design und Implementierung belastbarer Vulnerability- und Signing-Policies
• Integration mit bestehenden Security- und Monitoring-Werkzeugen
• Aufbau von Dashboards und Reports, die technische Daten für Audits und Management-Berichte nutzbar machen

Wenn Sie Ihre Registry von einem reinen „Image-Speicher“ zu einem tragenden Pfeiler Ihrer Sicherheits- und Compliance-Architektur weiterentwickeln möchten, unterstützen wir Sie von der Konzeption bis zum laufenden Betrieb – inklusive einer auf Ihre Umgebung abgestimmten Harbor Configuration.
Harbor Configuration