--- title: "DevSecOps und sichere Software-Lieferketten | SKAFFON" description: "DevSecOps-Beratung: Pipelines mit SBOM, Scanning, Signierung und Deployment-Richtlinien für Container und Software-Lieferketten, mit Referenzarchitektur." url: https://skaffon.de/cybersecurity/devsecops-supply-chain/ --- ![Dunkler Monitor mit farbig hervorgehobenem Quellcode an einem Entwicklerarbeitsplatz mit roter und blauer LED-Beleuchtung](/_astro/dunkler-monitor-quellcode-arbeitsplatz.BkBRz8KX_ABcni.jpg) 1. [Startseite](/) 2. [Cybersecurity](/cybersecurity/) 3. DevSecOps und sichere Software-Lieferketten DevSecOps und Software-Lieferkette # DevSecOps und sichere Software-Lieferketten SKAFFON baut und härtet CI/CD-Pipelines so, dass jedes ausgelieferte Artefakt nachvollziehbar entstanden, geprüft und signiert ist: mit Software-Stückliste (SBOM), Schwachstellenscan, Herkunftsnachweis und Richtlinien, die beim Deployment nur geprüfte Artefakte zulassen. [Projekt anfragen](/projekt-anfragen/) [Referenzpipeline ansehen](/cybersecurity/devsecops-supply-chain/#referenzpipeline-stufe-fuer-stufe) - Für IT-Leitung und CTO mit eigener Softwareentwicklung - Umsetzung in Ihrer CI-Umgebung, Quellcode bleibt bei Ihnen - Keine Konformitätszusage, keine Rechtsberatung Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## Vier Anzeichen, dass Ihre Lieferkette nicht belegbar ist Wenn eines davon auf Sie zutrifft, fehlt der Pipeline nicht ein Werkzeug, sondern die durchgängige Kette von Nachweisen. - ### Der Inhalt laufender Container ist unbekannt Niemand kann sagen, welche Bibliotheken in einem laufenden Container stecken. Wird eine Schwachstelle bekannt, beginnt die Suche von vorn. - ### Images ohne Herkunftsnachweis Images kommen aus verschiedenen Registries, ohne Prüfung und ohne Nachweis, dass sie aus Ihrer Pipeline stammen. - ### Sicherheitsprüfung erst kurz vor dem Release Prüfungen laufen manuell vor dem Release statt automatisch bei jedem Build. - ### Kunden oder Gesetze verlangen Nachweise Der Cyber Resilience Act nennt für Hersteller von Produkten mit digitalen Elementen in Anhang I Teil II die Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen ([Verordnung (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)). Projektablauf ## Vom Ist-Zustand zur Pipeline, die Regeln durchsetzt Sechs Arbeitsschritte, in Ihrer CI-Umgebung, zum Beispiel GitLab CI oder GitHub Actions, und mit Ihren vorhandenen Werkzeugen und Registries. 1. 01 ### Bestandsaufnahme Wir erfassen Pipelines, Repositories, Registries und Deployment-Wege. 2. 02 ### Zielarchitektur Wir entwerfen Build, Prüfung, Signierung, Ablage und Deployment nach dem Muster der Referenzpipeline. 3. 03 ### Umsetzung Wir bauen die Stufen in Ihrer CI-Umgebung auf und passen sie an vorhandene Werkzeuge und Registries an. 4. 04 ### Richtlinien Wir legen für Pipeline und Cluster fest, welche Prüfungen Pflicht sind und was einen Release blockiert. 5. 05 ### Abhängigkeitsmanagement Automatisierte Update-Vorschläge, Bewertung von Schwachstellen und ein Umgang mit nicht behebbaren Fällen. 6. 06 ### Übergabe Dokumentation und Einweisung Ihrer Entwicklerinnen und Entwickler. Referenzpipeline ## Eine Pipeline, in der jede Stufe einen Nachweis erzeugt Unsere Referenzpipeline ist ein winziger Go-Dienst, der durch eine vollständige Lieferketten-Pipeline läuft. Der Dienst ist Nebensache, die Pipeline ist der Inhalt. Der gestrichelte Rückkanal (Schwachstellenmeldung, Abgleich mit gespeicherten SBOMs, betroffene Images) ist nicht Teil der Referenzpipeline, aber in Projekten umsetzbar. Der gestrichelte Rückkanal (Schwachstellenmeldung, Abgleich mit gespeicherten SBOMs, betroffene Images) ist nicht Teil der Referenzpipeline, aber in Projekten umsetzbar. Stufe für Stufe ## Referenzpipeline: von der Zeile Code bis zum Cluster Jede Stufe erzeugt einen Nachweis, der an das Artefakt gebunden wird. Schlägt eine Stufe fehl, endet der Lauf. 1. 01 ### Erst prüfen, dann bauen, nichts in die Registry Lint, Test, Build Formatierung, statische Prüfung, Unit-Tests und das Rendern der Kustomize-Overlays; danach Build des Images in einer sauberen, kurzlebigen Runner-Umgebung. In die Registry wird nichts geschrieben, bevor die Prüfungen bestanden sind. 2. 02 ### Schwachstellen, Konfiguration und Secrets Trivy Prüfung von Manifesten, Dockerfile und Image. Jeder Befund der Schwere HIGH oder CRITICAL bricht den Lauf ab. Ausnahmen gibt es nur über eine versionierte Ausnahmeliste mit exakter ID, schriftlicher Begründung, Ablaufdatum (höchstens 90 Tage) und Freigabe durch eine zweite Person. 3. 03 ### Stückliste für jedes Image Syft Je eine Software-Stückliste in SPDX und CycloneDX, gespeichert als Build-Artefakt. 4. 04 ### Push nur nach bestandener Prüfung, Adressierung per Digest GHCR Nur bei Push auf den Hauptzweig oder ein Versions-Tag, nie bei Pull Requests. Der Digest wird gelesen und gegen die Registry bestätigt; alle folgenden Schritte adressieren das Image über den Digest, nie über ein Tag. 5. 05 ### Signierung ohne langlebigen Schlüssel Cosign Der Job erhält ein kurzlebiges OIDC-Token des CI-Systems, Sigstore stellt daraus ein Zertifikat aus, das Workflow und Git-Ref enthält; die Signatur wird im öffentlichen Transparenzlog eingetragen. Es gibt keinen langlebigen Signaturschlüssel, der gestohlen werden könnte. 6. 06 ### SBOM und Herkunftsnachweis am Image Attestierung Beide Stücklisten werden als signierte Attestierung an das Image gebunden; zusätzlich entsteht mit GitHub Artifact Attestations eine Build-Provenance im SLSA-Format. Ein Selbstprüfungsschritt verifiziert Signatur und Attestierungen am Ende des Laufs, so wie es später auch ein Konsument täte. 7. 07 ### Auslieferung per GitOps, Freigabe per Pull Request Argo CD Ein Skript trägt den geprüften Digest in ein Kustomize-Overlay ein; die Änderung geht als Pull Request durch Review (das ist die Freigabe). Die Staging-Umgebung wird automatisch synchronisiert, die Produktionsumgebung nur durch eine Person. 8. 08 ### Der Cluster lässt nur Geprüftes zu Kyverno Die Cluster-Richtlinie (Kyverno `ImageValidatingPolicy`, fail-closed) lässt nur Images zu, die per Digest adressiert sind, eine gültige Signatur dieser Pipeline tragen und eine SBOM-Attestierung besitzen ([Kyverno: Images prüfen](https://kyverno.io/docs/writing-policies/verify-images/)). Kann nicht geprüft werden, wird abgelehnt. Fail-closed ## Kann die Richtlinie ein Image nicht prüfen, kommt es nicht in den Cluster Die Richtlinie lehnt ab, statt durchzuwinken. Zusätzlich härtet die Referenzpipeline die Beispiel-Workloads: Pod Security `restricted`, Nicht-Root-Nutzer, schreibgeschütztes Root-Dateisystem, entfernte Capabilities und Default-Deny-NetworkPolicy. Werkzeuge ## Womit die Referenzimplementierung arbeitet Build und Registry - GitHub Actions - GitHub Container Registry (GHCR) - Kustomize Prüfen und Stückliste - Trivy - Syft - SPDX - CycloneDX Signieren und belegen - Cosign - Sigstore - GitHub Artifact Attestations - SLSA Ausliefern und durchsetzen - Argo CD - Kyverno Ob diese Auswahl zu Ihrer Umgebung passt, klären wir in der Bestandsaufnahme; in Projekten setzen wir sie mit Ihrer vorhandenen Werkzeugkette um. Ihre Umgebung ## Dasselbe Muster mit Ihren Werkzeugen In Kundenumgebungen setzen wir dasselbe Muster mit der dort vorhandenen Werkzeugkette um, etwa mit GitLab CI und Harbor oder einer anderen Registry. Die Stufenlogik bleibt gleich (Build, Scan, SBOM, Registry, Signierung, Admission); ersetzt werden der OIDC-Aussteller, die in der Richtlinie hinterlegte Zertifikatsidentität und die Registry. Bei hohen Souveränitätsanforderungen kommt schlüsselbasiertes Signieren mit Schlüsseln in einer geschützten Schlüsselverwaltung oder eine private Sigstore-Instanz in Frage, statt der öffentlichen Sigstore-Dienste. Die Referenzpipeline setzt das nicht um. [Projekt anfragen](/projekt-anfragen/) ![Makroaufnahme eines Vorhängeschlosses auf einer blauen Platine mit Bauteilen](/_astro/vorhaengeschloss-auf-platine.CFp6cpdW_1dytl0.jpg) Regulatorischer Hintergrund ## CRA-Fristen und BSIG: was gilt ab wann Geprüft am 13\. November 2026\. Ob Ihr Unternehmen und Ihre Produkte unter den CRA fallen, klären Sie rechtlich; wir setzen die technischen Prozesse um, wir beraten nicht zur Einordnung und garantieren keine Konformität. __Anwendungsfristen der Verordnung (EU) 2024/2847 nach Artikel 71__ | Ab | Was gilt | | ------------------- | ------------------------------------------------------------------------------- | | 11\. Juni 2026 | Kapitel IV (Artikel 35 bis 51): Notifizierung von Konformitätsbewertungsstellen | | 11\. September 2026 | Artikel 14: Meldepflichten der Hersteller | | 11\. Dezember 2027 | Die Verordnung gilt im Übrigen | Quelle: [Verordnung (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Für Einrichtungen unter dem BSI-Gesetz nennt § 30 Abs. 2 Nr. 4 und 5 BSIG die Sicherheit der Lieferkette und die Sicherheit bei Entwicklung und Wartung (siehe [NIS2-Beratung](/cybersecurity/nis2-beratung/)). Belegstand ## Was an der Referenzpipeline belegt ist und was nicht Das Repository ist noch nicht veröffentlicht, und die Workflows sind noch nicht in GitHub Actions gelaufen. Lokal geprüft wurden Test, Image-Build, Trivy- und Syft-Läufe, das Rendern der Overlays und die Ablehnung eines nicht signierten Images durch die Kyverno-Richtlinie in der Kyverno-CLI. Nicht ausgeführt und damit unbelegt sind die Signierung und die Attestierungen im echten Lauf, der positive Pfad der Richtlinie (ein von der Pipeline signiertes Image wird zugelassen) und die Argo-CD-Synchronisation in einem Cluster. SLSA-Einordnung Als Orientierung für Herkunftsnachweise nutzen wir den Build-Track von [SLSA](https://slsa.dev/spec/v1.0/levels). Die Provenance der Referenzpipeline entspricht nach unserer Lesart der GitHub-Dokumentation dem Build-Level 2, nicht Level 3, und ist nicht von dritter Seite bestätigt. Welche Stufe Ihr Vorhaben braucht, legen wir gemeinsam fest, und jede zugesagte Stufe belegen wir mit der erzeugten Provenance. Voraussetzungen und Grenzen ## Was Sie mitbringen und was eine Pipeline nicht leistet ### Das bringen Sie mit - Zugriff auf Repositories, CI-Konfiguration und Registry. - Klarheit, welche Systeme zu schützen sind und welche Meldewege bei Schwachstellen gelten. - Entwicklungsteams, die die Pipeline-Regeln mittragen. - Eine CI/CD-Basis. Fehlt sie, bauen wir sie zuerst über [DevOps-Automatisierung](/leistungen/devops-automatisierung/) oder [Platform Engineering](/leistungen/platform-engineering/). ### Das leistet die Pipeline nicht - Scanner finden bekannte Schwachstellen in bekannten Komponenten, aber keine Logikfehler im eigenen Code; sie ersetzen weder Code-Review noch Penetrationstest. - Eine Signatur belegt Herkunft und Unverändertheit, nicht die Sicherheit des Inhalts. - Wir greifen nur auf die für die Pipeline nötigen Systeme zu, Quellcode bleibt in Ihrer Umgebung. - Ein fertiges Produkt zum Abonnieren statt einer Integration in Ihre Pipelines ist es nicht. - Eine rechtliche Einordnung nach CRA oder eine Konformitätserklärung gehört nicht zum Umfang. Angrenzende Themen ## Was an die Lieferkette anschließt - ### [Cybersecurity im Überblick](/cybersecurity/) Alle Sicherheitsleistungen von SKAFFON auf einer Seite. Weiter - ### [NIS2-Beratung](/cybersecurity/nis2-beratung/) Lieferkettensicherheit aus Sicht des BSI-Gesetzes. Weiter - ### [Managed Kubernetes](/managed-services/managed-kubernetes/) Cluster-Betrieb, in dem die Admission-Richtlinien durchgesetzt werden. Weiter - ### [DevOps-Automatisierung](/leistungen/devops-automatisierung/) Die CI/CD-Basis, auf der die Lieferketten-Stufen aufsetzen. Weiter Lieferkette absichern ## Wie weit ist Ihre Pipeline von dieser Kette entfernt? Beschreiben Sie Ihre CI-Umgebung und Ihre Registry in wenigen Sätzen. [Projekt anfragen](/projekt-anfragen/) [Cybersecurity im Überblick](/cybersecurity/)