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.
- Für IT-Leitung und CTO mit eigener Softwareentwicklung
- Umsetzung in Ihrer CI-Umgebung, Quellcode bleibt bei Ihnen
- Keine Konformitätszusage, keine Rechtsberatung
01Ausgangslage
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).
02Projektablauf
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.
- 01
Bestandsaufnahme
Wir erfassen Pipelines, Repositories, Registries und Deployment-Wege.
- 02
Zielarchitektur
Wir entwerfen Build, Prüfung, Signierung, Ablage und Deployment nach dem Muster der Referenzpipeline.
- 03
Umsetzung
Wir bauen die Stufen in Ihrer CI-Umgebung auf und passen sie an vorhandene Werkzeuge und Registries an.
- 04
Richtlinien
Wir legen für Pipeline und Cluster fest, welche Prüfungen Pflicht sind und was einen Release blockiert.
- 05
Abhängigkeitsmanagement
Automatisierte Update-Vorschläge, Bewertung von Schwachstellen und ein Umgang mit nicht behebbaren Fällen.
- 06
Übergabe
Dokumentation und Einweisung Ihrer Entwicklerinnen und Entwickler.
03Referenzpipeline
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.
04Stufe 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.
- 01
Erst prüfen, dann bauen, nichts in die Registry
Lint, Test, BuildFormatierung, 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.
- 02
Schwachstellen, Konfiguration und Secrets
TrivyPrü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.
- 03
Stückliste für jedes Image
SyftJe eine Software-Stückliste in SPDX und CycloneDX, gespeichert als Build-Artefakt.
- 04
Push nur nach bestandener Prüfung, Adressierung per Digest
GHCRNur 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.
- 05
Signierung ohne langlebigen Schlüssel
CosignDer 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.
- 06
SBOM und Herkunftsnachweis am Image
AttestierungBeide 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.
- 07
Auslieferung per GitOps, Freigabe per Pull Request
Argo CDEin 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.
- 08
Der Cluster lässt nur Geprüftes zu
KyvernoDie 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). 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.
05Werkzeuge
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.
06Ihre 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.
07Regulatorischer 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.
| 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. 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).
08Belegstand
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.
09Voraussetzungen 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 oder 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.
10Angrenzende Themen
Was an die Lieferkette anschließt
-
Cybersecurity im Überblick
Alle Sicherheitsleistungen von SKAFFON auf einer Seite.
-
NIS2-Beratung
Lieferkettensicherheit aus Sicht des BSI-Gesetzes.
-
Managed Kubernetes
Cluster-Betrieb, in dem die Admission-Richtlinien durchgesetzt werden.
-
DevOps-Automatisierung
Die CI/CD-Basis, auf der die Lieferketten-Stufen aufsetzen.
Lieferkette absichern
Wie weit ist Ihre Pipeline von dieser Kette entfernt?
Beschreiben Sie Ihre CI-Umgebung und Ihre Registry in wenigen Sätzen.