Sichern Sie Ihre Software-Lieferkette von der Erstellung bis zur Bereitstellung

Verhindern Sie, dass nicht gescannte, nicht signierte oder anfällige Container-Images die Produktion erreichen. Dieser Leitfaden zeigt, wie private Registry-Kontrollen, Schwachstellen-Scans, Artefakt-Signierung und Kubernetes-Zulassungsrichtlinien einen durchsetzbaren Workflow in der gesamten Software-Lieferkette schaffen. 
Jetzt loslegenManaged Private Registry
Domainnamen Illustration

Überprüfen Sie jede Komponente in Ihrer Pipeline

Sicherheit in der Software-Lieferkette bedeutet die kontinuierliche Überprüfung jeder Abhängigkeit, jedes Pakets und jedes Artefakts in einer CI/CD-Pipeline. Das Vertrauen muss sich über den Quellcode, öffentliche Pakete, externe Technologie, Komponenten von Drittanbietern, Build-Elemente, Registries und die endgültige Version erstrecken. Eine Gefährdung kann durch veränderte Abhängigkeiten oder kompromittierte Prozesse eindringen. Beginnen Sie damit, jede kundenorientierte Komponente anhand eines anerkannten Frameworks zu identifizieren, wie etwa der NIST-Anleitung oder den SSCS-Prinzipien. Die Teams können dann erkennen, wo Nachweise fehlen, sichere Codierungspraktiken anwenden und Ausgaben mit Cosign signieren. Dieser Framework-basierte Ansatz ermöglicht es Ihnen, die Sicherheit in der gesamten Kette durchzusetzen, anstatt sich auf einen einzigen Kontrollpunkt zu verlassen. Jede Partei kann nachverfolgen, was in den Build eingeflossen ist, wie es gehandhabt wurde und welche Nachweise die Bereitstellung unterstützen.
[object Object]

Die Release-Sicherheit auf verifizierbare Kontrollen aufbauen

Private Harbor-Projekte, Trivy-Richtlinien, Cosign-Signierung und europäische Gerichtsbarkeit
Community@2x.png
Den Registry-Zugriff einschränken
Cyber Security@2x.png
Bekannte Schwachstellen blockieren
Magnifying Glass Check@2x.png
Herkunft und Resilienz verifizieren

Jede Stufe schützen, die Angreifer ins Visier nehmen können

Was ist Supply-Chain-Sicherheit in einer modernen Container-Umgebung?

Was ist Supply-Chain-Sicherheit in einer modernen Container-Umgebung? Sie schützt den Weg von Quellcode und Drittanbieter-Abhängigkeiten über Build-Systeme und Image-Speicher bis hin zu Bereitstellungs-Endpunkten. Die Sicherheit der Software-Lieferkette behandelt diese Prozesse im Zusammenhang, da ein Angriff an einem Ende jede spätere Kontrolle schwächen kann.

Schutz des Quell-Repositorys

Ein Quell-Repository ist ein klares Angriffsziel. Ein Angreifer könnte Anmeldedaten stehlen, Code verändern, eine Prüfregel deaktivieren oder eine Abhängigkeit einführen, die legitim erscheint. Kontrollierte Download-Quellen, obligatorische Peer-Reviews und geschützte Branches bilden die erste Verteidigungslinie. Die Teams sollten zudem Abhängigkeitsversionen sperren und Prüfsummen, Lizenzen sowie Herkunft verifizieren, anstatt sich ändernde Eingaben für jeden Build zu akzeptieren. Diese Prüfungen verringern das Risiko, bösartige oder unberechtigte Software von einer anderen Partei zu importieren.

Angriffspfade der Build-Infrastruktur

Die Build-Infrastruktur weist verschiedene Angriffspfade auf. Kompromittierte Runner, offengelegte Geheimnisse oder veränderbare Basis-Images können ein Artefakt modifizieren, nachdem die Entwickler dessen Quelle genehmigt haben. Isolieren Sie Build-Prozesse, verwenden kurzlebige Anmeldedaten und zeichnen exakte Eingaben auf. Dieser Ansatz unterstützt die Sicherheit von Container-Images, indem unerwartete Codeänderungen leichter nachverfolgbar gemacht werden.

Kontrollen von der Registry bis zum Cluster

Die Route von der Registry zum Cluster erfordert unabhängige Kontrollen. Ein Angreifer könnte ein genehmigtes Image ersetzen, einen alten Tag wiederverwenden oder zu großzügige Bereitstellungsberechtigungen ausnutzen. Der Zugriff nach dem Prinzip der geringsten Rechte schränkt ein, was jede Identität veröffentlichen oder abrufen kann. Unveränderliche Referenzen verbinden Manifeste mit präzisen Images, während Kyverno Releases ablehnen kann, denen vertrauenswürdige Nachweise fehlen oder die Sicherheitsanforderungen verletzen.

Ein effektives Management der Software-Lieferkette beginnt mit einer Bestandaufnahme. Erfassen Sie Bibliotheken von Erst- und Drittanbietern, Basis-Images, Lizenzen und Build-Tools, die von jeder Anwendung verwendet werden. Verbinden Sie jede Software-Stückliste (SBOM) mit dem Projekt, dem Commit und dem Pipeline-Lauf, der ihr Artefakt erzeugt hat. Diese Beziehung hilft den Cybersicherheitsteams dabei, betroffene Dienste zu identifizieren, wenn eine empfindliche Komponente kompromittiert wird. Wählen Sie ein Tool, das maschinenlesbare Nachweise exportiert und Versionen mittels Automatisierung vergleicht. Die Bestandaufnahme sollte sich parallel zur Software weiterentwickeln, anstatt von periodischer manueller Arbeit abzuhängen. Legen Sie einen Ansprechpartner für Abhängigkeitsthemen, Ausnahmen und Behebungen fest, damit die Zuständigkeit klar bleibt.
Führen Sie Sicherheitstests früh genug durch, um den Entwicklern umsetzbare Ergebnisse zu liefern. Die Pipeline-Automatisierung kann Quellabhängigkeiten, Container-Layer und Konfigurationen vor der Beförderung untersuchen. Definieren Sie CVE-Scan-Schwellenwerte entsprechend der Workload-Exposition und den geschäftlichen Auswirkungen und leiten Sie fehlgeschlagene Ergebnisse an das verantwortliche Team weiter. Eine fehlgeschlagene Prüfung sollte den Fortschritt stoppen, anstatt einen ungelesenen Alarm zu generieren. Dokumentieren Sie das Problem, das betroffene Paket, den Schweregrad und die genehmigte Reaktion. Dieser Nachweis hilft, die Release-Qualität zu schützen und gleichzeitig die Entscheidungen zur Sicherheit der Software-Lieferkette über Anwendungen hinweg konsistent zu halten.
Die Imagesignierung beweist, welcher kontrollierte Prozess ein Artefakt genehmigt hat. Signieren Sie jedes Image nach Bestehen der erforderlichen Tests mit einem unveränderlichen Digest und speichern Sie dann die Herkunft, die die Quellrevision, den Ersteller und den Workflow identifiziert. Vermeiden Sie, nur veränderbare Tags zu signieren, da ein Tag später auf andere Inhalte verweisen kann. Trennen Sie Signierberechtigungen vom allgemeinen Entwickler- und Pipeline-Zugriff. Die Verifizierung sollte vertrauenswürdige Identitäten oder öffentliche Schlüssel verwenden, die von Ihrer Organisation definiert wurden. Ein kompromittierter Build-Prozess kann dann keine akzeptablen Nachweise erstellen, es sei denn, er erfüllt auch die Signierrichtlinie.
Ein Kubernetes Admission Controller bietet den endgültigen Entscheidungspunkt, bevor Workloads in einen Cluster gelangen. Konfigurieren Sie ihn so, dass er unsignierte Images, nicht genehmigte Registries, fehlgeschlagene Schwachstellenkriterien oder fehlende Herkunftsangaben ablehnt. Kyverno und OPA Gatekeeper können diese Bedingungen als versionskontrollierte Richtlinien ausdrücken. Testen Sie jede Regel anhand repräsentativer Workloads vor der produktiven Durchsetzung. Beginnen Sie im Audit-Modus, um legitime Ausnahmen zu finden, und verschieben Sie ausgereifte Kontrollen dann in den Blockiermodus. Pflegen Sie einen autorisierten Ausnahmepfad mit einem Eigentümer, einem Grund und einem Ablaufdatum. Der Cluster kann dann Release-Nachweise konsistent bewerten, selbst wenn eine frühere Kontrolle umgangen oder falsch konfiguriert wurde.
Ein effektives Management der Software-Lieferkette beginnt mit einer Bestandaufnahme. Erfassen Sie Bibliotheken von Erst- und Drittanbietern, Basis-Images, Lizenzen und Build-Tools, die von jeder Anwendung verwendet werden. Verbinden Sie jede Software-Stückliste (SBOM) mit dem Projekt, dem Commit und dem Pipeline-Lauf, der ihr Artefakt erzeugt hat. Diese Beziehung hilft den Cybersicherheitsteams dabei, betroffene Dienste zu identifizieren, wenn eine empfindliche Komponente kompromittiert wird. Wählen Sie ein Tool, das maschinenlesbare Nachweise exportiert und Versionen mittels Automatisierung vergleicht. Die Bestandaufnahme sollte sich parallel zur Software weiterentwickeln, anstatt von periodischer manueller Arbeit abzuhängen. Legen Sie einen Ansprechpartner für Abhängigkeitsthemen, Ausnahmen und Behebungen fest, damit die Zuständigkeit klar bleibt.

Legen Sie Verantwortlichkeiten für vier Governance-Prioritäten fest

Vertrauenswürdiger Code und Vendor-Governance

Ein benannter Leiter sollte Kriterien für vertrauenswürdige Quellen und Anbieter definieren, unterstützt durch Beschaffungs-, Entwicklungs- und Sicherheitsressourcen. Nutzen Sie SLSA als Orientierungshilfe für eine stärkere Build-Integrität und Herkunft, ohne eine bestimmte Erreichungsstufe vorauszusetzen. Skalieren Sie Überprüfungen auf die Größe der Organisation und das Risiko der Software-Lieferkette.

Richtliniendurchsetzung und konforme Infrastruktur

Sicherheits- und Plattformverantwortliche sollten Compliance-Verpflichtungen in messbare Richtliniendurchsetzung über Code, Cloud und Infrastruktur hinweg umsetzen. Definieren Sie, wer Ausnahmen genehmigen darf, welche Nachweise er erbringen muss und wie Kontrollen interne Anforderungen erfüllen.

Dokumentation, Audits und Nachweise

Legen Sie einen Ressourcenverantwortlichen fest, um die Dokumentation für Entscheidungen, Abhängigkeiten und Kontrolländerungen zu pflegen. Regelmäßige Audits sollten prüfen, ob Aufzeichnungen mit der betrieblichen Praxis übereinstimmen. Geben Sie den Prüfern ausreichend Unterstützung, um ein Problem bis zu seinem Eigentümer, der betroffenen Version und der Lösung zurückzuverfolgen.

Bereitschaft bei Vorfällen und Verantwortung für die Behebung

Eine Führungskraft im Sicherheitsbereich sollte die Rollen bei der Reaktion koordinieren, bevor ein Angreifer diese testet. Pflegen Sie einen Plan zur Bewältigung potenzieller Probleme, der Triage, Eindämmung, Kommunikation mit Stakeholdern und Wiederherstellung abdeckt. Jede Maßnahme benötigt einen verantwortlichen Eigentümer, unterstützende Ressourcen und Zeitpläne, die dem Risiko des Unternehmens angemessen sind.

Betreiben Sie Harbor anhand von vier Sicherheitssäulen

Kontrollieren Sie den Zugriff genau

Harbor unterstützt RBAC auf Projekt- und Teamebene zur Trennung von Unternehmens-Workloads und Verantwortlichkeiten. Erstellen Sie bereichsbezogene Robot-Accounts für CI/CD-Push- und Pull-Aufgaben, anstatt allgemeine Benutzeranmeldedaten zu teilen. Ordnen Sie jede Identität einem Zweck zu, rotieren Sie deren Geheimnis und ziehen Sie ungenutzten Zugriff zurück. Diese Praxis begrenzt die Auswirkungen einer Offenlegung von Anmeldedaten und sichert gleichzeitig die tägliche Veröffentlichung.

Erkennen Sie unsichere Komponenten kontinuierlich

Kombinieren Sie kontinuierliche Trivy-Prüfungen mit Software Composition Analysis (SCA) und Abhängigkeitsmanagement. Diese Tools erkennen bekannte Schwachstellen, veraltete Pakete und Indikatoren für bösartigen Code bei jeder Komponente. Erstellen Sie für jede Version einen klaren Bericht, einschließlich Schweregrad, Ort und Behebungsstatus. Die Teams können dann blockierende Ergebnisse von akzeptierten Ausnahmen unterscheiden und erkennen, wenn neue Informationen gespeicherte Artefakte betreffen.

Entwicklungs-Workflows verbinden

Integrieren Sie die Plattform mit GitLab CI, Tekton und anderen genehmigten Entwicklungs-Workflows. Halten Sie Richtlinienentscheidungen nah an der Pipeline, damit eine fehlgeschlagene Prüfung nützliches Feedback vor der Beförderung liefert. Referenzen zur Quellcodeverwaltung (SCM) sollten jedes Artefakt mit seinem Commit, Build-Lauf und Eigentümer verknüpfen. Die DevSecOps-Teams verfügen dann über einen konsistenten Datensatz anstelle von separaten Nachweisen, die über verschiedene Systeme verstreut sind.

Die operative Reaktion vorbereiten

Pflegen Sie einen Plan zur Reaktion auf Vorfälle für kompromittierte Anmeldeinformationen, unsichere Images und fehlgeschlagene Kontrollen. Definieren Sie, wer die Verteilung stoppt, eine betroffene Version entfernt, den Zugriff untersucht und die Wiederherstellung genehmigt. Warnmeldungen brauchen einen Verantwortlichen und einen erwarteten Reaktionsweg; sie nur zu generieren, verringert das Risiko nicht. Führen Sie Übungen durch, um sicherzustellen, dass die Sicherheits- und Plattformteams den relevanten Bericht finden, Inhalte isolieren und Entscheidungen kommunizieren können. Diese operative Säule verwandelt Erkennung in zeitnahes Handeln auf der gesamten Bereitstellungsplattform.

Bewahren Sie vertrauenswürdige Nachweise für jede Version auf

Die Versionen-Sichtbarkeit hängt von Nachweisen ab, die zeigen, wer ein Artefakt erstellt hat, woher es stammt und wie es getestet wurde. Generieren und speichern Sie Trivy-Ergebnisse, Daten zur Softwarestückliste und Signaturen für jedes Image und jeden Satz von Helm-Charts. Dies ermöglicht es dem Unternehmen, jeden Inhaltstyp zu identifizieren und ein potenzielles Sicherheitsproblem zu untersuchen. Integrieren Sie Prüfungen in GitLab CI, um Entwickler-Feedback zu automatisieren, bevor die Software in die kontrollierte Umgebung gelangt. Konsistente Tests unterstützen auch das Sicherheitsbewusstsein, indem sie zeigen, warum eine Veröffentlichung fehlgeschlagen ist. Schützen Sie Cosign-Signaturschlüssel durch den OVHcloud Key Management Service unter Verwendung von FIPS 140-2 HSM-gestütztem Speicher. Eine zentralisierte Schlüsselverwaltung trägt dazu bei, sicherzustellen, dass jede erzeugte Signatur an kontrolliertes Schlüsselmaterial gebunden ist und nicht an ein exponiertes Pipeline-Geheimnis.
[object Object]
Setzen Sie Ihre Container-Versionen-Richtlinie mit OVHcloud durch
Bauen Sie einen kontrollierten Weg von der CI/CD-Ausgabe zur Kubernetes-Bereitstellung mit Managed Private Registry und Managed Kubernetes Service auf. Bewerten Sie, wie Registry-Validierung, Versions-Nachweise und Cluster-Durchsetzung nicht gescannte, nicht signierte oder anfällige Images vor der Produktion stoppen können. Entdecken Sie Managed Private Registry und bewerten Sie dann die Kubernetes-Integration für Ihre Workloads, Ihr Richtlinienmodell und Ihre operativen Verantwortlichkeiten.
Den Registry-Pfad erkunden