Supply-Chain-Sicherheit für mittelgroße SaaS: SBOM, Dependency-Scanning und NIS2-Bereitschaft

Ein SaaS-Unternehmen, das europäische Logistiksoftware bedient, stellte Anfang 2026 fest, dass eine beliebte Open-Source-Parsing-Bibliothek elf Tage lang einen schadhaften Release ausgeliefert hatte, bevor der Maintainer es bemerkte. Die Bibliothek war seit drei Jahren im Dependency-Graph und wurde von vier internen Services genutzt. Als das Sicherheitsteam eines Enterprise-Kunden nach einem SBOM und einer schriftlichen Bestätigung fragte, dass die betroffene Version nicht in Produktion lief, hatte der CTO beides nicht. Die Rekonstruktion des Dependency-Graphen aus Package-Lock-Dateien, das Ermitteln, welche Deployments welche Version betrieben, und das Verfassen der Kundenkommunikation benötigen vier Ingenieure zweieinhalb Tage. Der eigentliche Fix dauerte vierzig Minuten.

Supply-Chain-Sicherheit ist für SaaS kein Randthema mehr. Der XZ-Utils-Backdoor 2024, die nachwirkenden Konsequenzen von SolarWinds in Beschaffungsgesprächen und nun die expliziten Supply-Chain-Pflichten von NIS2 unter Artikel 21 haben Dependency-Governance auf dieselbe Prioritätsliste wie Authentifizierung und Secrets-Management gebracht. Dieser Beitrag behandelt, wie ein praktisches Supply-Chain-Sicherheitsprogramm für ein mittelgroßes SaaS-Team aussieht: SBOM-Generierung, die in CI läuft ohne die Pipeline zu verlangsamen, Dependency-Scanning mit einem Triage-Prozess, der tatsächlich umgesetzt wird, Provenance-Attestation für eigene Build-Artefakte und die Incident-Response-Schritte, wenn sich eine Abhängigkeit als kompromittiert herausstellt, und was das alles für die NIS2-Bereitschaft bedeutet.

Was Supply-Chain-Sicherheit für ein SaaS-Team tatsächlich bedeutet

Der Begriff "Software-Supply-Chain" umfasst alles, was in deinen Produktions-Build einfließt, das du nicht selbst geschrieben hast: Open-Source-Bibliotheken, Basis-Container-Images, Build-Tools, interne Pakete anderer Teams, SDKs von Drittanbieter-APIs, die du bündelst, und Infrastructure-as-Code-Module aus öffentlichen Registries. Ein Angriff auf eine dieser Quellen kann schadhaften Code in dein Produkt einbringen, ohne dass einer deiner Ingenieure eine Sicherheitslücke berührt.

Für die meisten mittelgroßen SaaS-Teams ist die realistische Risikooberfläche schmaler als die Konferenz-Vortrag-Version: Es ist primär der Open-Source-Dependency-Graph, die Container-Images, die du zur Build-Zeit pullst, und etwaige interne geteilte Bibliotheken ohne formalen Release-Prozess. Diese engere Perspektive ist nützlich - sie bedeutet, dass du ein verteidigbares Programm aufbauen kannst, ohne ein dediziertes Sicherheitsteam, wenn du die richtigen Tools in den Workflow einbindest, den deine Ingenieure ohnehin nutzen.

Der NIS2-Aspekt erzeugt regulatorischen Druck. Artikel 21 der Richtlinie verpflichtet betroffene Organisationen, Supply-Chain-Sicherheit als verpflichtende Cybersicherheits-Risikomanagementmaßnahme anzugehen, einschließlich der Bewertung von Schwachstellen bei direkten Lieferanten und deren sicheren Entwicklungspraktiken. Wenn dein SaaS europäische Kunden in erfassten Sektoren bedient - Logistik, Fertigung, Gesundheits-IT, Finanzinfrastruktur - enthalten deine Beschaffungsgespräche bereits Supply-Chain-Fragen. Ein SBOM, einen aktuellen Scan-Bericht und einen dokumentierten Response-Prozess zu haben ist zunehmend eine Vertragsanforderung, kein nettes Extra.

SBOMs in CI generieren, ohne es zum Wochenend-Projekt zu machen

Eine Software-Bill-of-Materials ist ein strukturiertes Inventar der Komponenten in einem Software-Build: Bibliotheken, Versionen, Lizenzen und zunehmend Abhängigkeitsbeziehungen und Provenance-Metadaten. Die beiden dominanten Formate sind CycloneDX und SPDX - beide sind maschinenlesbare JSON oder XML, beide werden von den Tools akzeptiert, die Enterprise-Kunden zum Einlesen von Lieferanten-SBOMs verwenden.

Der praktische Ansatz für einen PHP/Symfony- oder Node/Next.js-Stack ist, das SBOM als Teil der Build-Pipeline zu generieren, nicht als manuellen Schritt. Für PHP-Projekte generiert cyclonedx-php-composer ein CycloneDX-SBOM aus composer.lock in unter zwei Sekunden. Für JavaScript/TypeScript erledigt @cyclonedx/cyclonedx-npm dasselbe aus package-lock.json oder yarn.lock. Die Ausgabe sollte an einem bekannten Ort im Build-Artefakt abgelegt werden - einer Container-Schicht, einem S3-Pfad, der mit dem Image-Tag verschlüsselt ist, oder einem GitHub-Release-Asset - damit du es abrufen kannst, ohne es aus dem aktuellen Code neu zu generieren, wenn ein Kunde nach dem SBOM für eine bestimmte Version fragt.

Der Schritt in einem GitHub-Actions-Workflow sieht ungefähr so aus: Nach dem Bestehen der Testsuite und vor dem Pushen des Images wird der SBOM-Generator ausgeführt, die Ausgabe an den Release angehängt oder in einen bekannten Speicherpfad hochgeladen, und dann geht es mit dem Image-Push weiter. Gesamte Mehrzeit in unseren Symfony-Projekten ist typischerweise unter dreißig Sekunden. Das SBOM für dieselbe Version wie das deployed Image ist dann per Tag abrufbar.

Eine Entscheidung, die du vorab treffen musst: der Scope. Ein vollständiges transitives SBOM für eine Symfony-Anwendung kann mehrere hundert Einträge umfassen, von denen viele DevDependencies sind, die nie Produktion erreichen. Das Filtern auf nur Produktionsabhängigkeiten erzeugt ein kleineres, besser prüfbares Dokument. Die meisten Tools unterstützen das mit einem einzigen Flag. Kunden, die NIS2-getriebene Beschaffung durchführen, wollen generell das Produktionsscope-SBOM; Regulatoren, die Audits durchführen, könnten das vollständige anfragen. Beide zu generieren und beide zu speichern ist der sauberste Ansatz.

Dependency-Scanning, das Maßnahmen erzeugt, kein Backlog-Rauschen

Das Problem mit Dependency-Scanning bei den meisten Teams ist nicht der Scanner - es ist der Triage-Prozess. Dependabot, Snyk oder Trivy ohne eine Handlungsrichtlinie für deren Ausgabe zu betreiben erzeugt eine wachsende Liste von CVEs, die nach und nach nicht mehr gelesen wird. Innerhalb von drei Monaten hat das Team die Alarme abgestellt und der Scanner ist zur Compliance-Theater-Vorstellung geworden.

Ein brauchbares Dependency-Scanning-Programm hat vier Komponenten: einen Scanner, der in CI integriert ist und Builds bei kritischen Schwachstellen in Produktionsabhängigkeiten scheitern lässt; eine Triage-Richtlinie, die definiert, welche Schweregrade bis wann eine Behebung erfordern; einen regelmäßigen Überprüfungs-Rhythmus (keine Warteschlange, die unbegrenzt wächst); und einen dokumentierten und prüfbaren Suppression-Prozess für False-Positives und irrelevante Findings.

Für kritische CVEs in Produktionsabhängigkeiten sollte die Richtlinie unkompliziert sein: Der Build scheitert und der Release wird blockiert, bis die Abhängigkeit aktualisiert oder eine dokumentierte Ausnahme genehmigt wird. Für hohe und mittlere CVEs ist ein SLA-basiertes Triage praktischer - Hohe innerhalb von zwei Wochen, Mittlere innerhalb von dreißig Tagen, Niedrige getrackt aber nicht zeitgebunden. Die genauen Schwellenwerte sind weniger wichtig als die Tatsache, dass sie schriftlich festgehalten, durchgesetzt werden und Nachweise für ein Audit erzeugen.

Der Triage-Schritt ist, wo die meisten Teams zu wenig investieren. Eine CVE in einer Bibliothek ist oft in deiner spezifischen Nutzung nicht ausnutzbar - der verwundbare Code-Pfad könnte nur bei Eingabemustern ausgelöst werden, die deine Anwendung nie erzeugt, oder die Bibliothek könnte nur zur Build-Zeit genutzt werden. Eine CVE als nicht ausnutzbar zu markieren mit einer dokumentierten Begründung ist ein legitimes Ergebnis von Triage und erzeugt eine sauberere Prüf-Spur als sie stillschweigend zu ignorieren. Tools wie VEX-Dokumente (Vulnerability Exploitability eXchange), die Ausnutzbarkeits-Aussagen an CVEs in einem CycloneDX-SBOM anhängen, gewinnen im Enterprise-Beschaffungswesen als bevorzugte Kommunikationsweise an Boden.

Ein Code-Qualitäts-Audit zeigt oft, dass Teams Dependency-Scanning konfiguriert haben, aber keine Triage-Richtlinie daran geknüpft ist - die Scanner-Ausgabe geht in ein Dashboard, aber das Dashboard ist nicht mit einem Remediation-Workflow verbunden. Diese Verbindung wiederherzustellen ist eine Tagesaufgabe, sobald die Richtlinie vereinbart ist.

Provenance-Attestation und das SLSA-Framework

Ein SBOM sagt dir, was in einem Build ist. Provenance-Attestation sagt dir, wie dieser Build produziert wurde - welcher Source-Commit, welches Build-System, welche Pipeline, mit welchen Inputs. Das SLSA-Framework (Supply-chain Levels for Software Artefacts) definiert vier zunehmend strenge Provenance-Levels, von grundlegender Dokumentation des Build-Prozesses (SLSA 1) bis zu hermetischen, reproduzierbaren Builds auf einem gehärteten Build-Service (SLSA 4).

Für ein mittelgroßes SaaS-Team ist SLSA 2 das praktische Ziel: ein Build, der aus Version-Control ausgelöst wird, einen gehosteten Build-Service (GitHub Actions, GitLab CI) nutzt und ein generiertes und signiertes Provenance-Dokument produziert. Das schließt die häufigsten Supply-Chain-Angriffsvektoren aus - ein kompromittierter Entwickler-Laptop, der schadhaften Code in einen Build einschleust, oder ein inoffizieller Build-Prozess, der Security-Checks umgeht - ohne Build-Infrastruktur zu erfordern, die nur bei Hyperscaler-Scale Sinn ergibt.

Die Tooling-Landschaft ist zugänglicher als die SLSA-Spezifikation es klingen lässt. GitHub Actions unterstützt SLSA-Provenance-Generierung nativ über die slsa-github-generator-Action, die ein Provenance-Attestierungsdokument erzeugt, das mit dem Sigstore-Rekor-Transparenzprotokoll signiert ist. Für Container-Images signiert cosign vom Sigstore-Projekt das Image und hängt Attestierungen an, die Konsumenten verifizieren können, bevor sie pullen. Beide Tools sind kostenlos, Open-Source und fügen einem typischen CI-Lauf nur wenige Sekunden hinzu.

Das Provenance-Dokument reist dann mit dem Artefakt: Ein Container-Image in deiner Registry hat eine zugehörige cosign-Signatur und Attestierung. Ein Enterprise-Kunde, der verifizieren möchte, dass dein veröffentlichtes Image tatsächlich aus deiner deklarierten Build-Pipeline und deinem Source-Commit stammt, kann das tun, ohne dir zu vertrauen. Das ist zunehmend, was "Supply-Chain-Assurance" in NIS2-getriebenen Lieferanten-Fragebögen bedeutet.

Wenn eine Abhängigkeit kompromittiert ist: Die ersten neunzig Minuten

Supply-Chain-Incidents haben eine andere Form als Infrastruktur-Incidents. Das typische Szenario: Eine CVE wird veröffentlicht oder ein schadhafter Release für eine Bibliothek in deinem Dependency-Graph wird bestätigt, du weißt nicht sofort, welche Services betroffen sind oder welche Versionen deployed sind, und deine Enterprise-Kunden stellen Fragen, bevor du die Antworten hast.

Die erste Aufgabe ist Scope-Ermittlung. Wenn du SBOMs für jede deployed Version gespeichert hast (wie oben beschrieben), ist das eine Datenbankabfrage: Welche Services enthalten diese Bibliothek, und welche Version läuft in welcher Umgebung? Wenn du keine SBOMs hast, rekonstruierst du das manuell aus Deployment-Logs, Package-Dateien in laufenden Containern oder rollenden Produktions-Builds - ein Prozess, der Stunden dauern kann. Das ist das operative Argument für SBOM-Generierung, die nicht davon abhängt, dass die Bibliothek als Sicherheitslücke bekannt ist: Du möchtest das Inventar existieren lassen, bevor du es brauchst.

Die zweite Aufgabe ist die Ausnutzbarkeitsbeurteilung. Nicht jede Schwachstelle in einer Abhängigkeit übersetzt sich in Ausnutzbarkeit in deinem Produkt. Prüfe, ob der betroffene Code-Pfad in deiner Nutzung tatsächlich aufgerufen wird, ob die Bibliothek eine Produktionsabhängigkeit oder eine Build-/Dev-Abhängigkeit ist, und ob mindernde Kontrollen (Input-Validierung, eingeschränkter Netzwerkzugriff, WAF-Regeln) die effektive Exposition reduzieren. Dokumentiere diese Beurteilung, auch wenn die Schlussfolgerung "in unserer Konfiguration nicht ausnutzbar" lautet - die Dokumentation ist das, was du an Kunden sendest, nicht nur die Schlussfolgerung.

Die dritte Aufgabe ist Kommunikation. Enterprise-Kunden unter NIS2 könnten eigene Meldepflichten haben, wenn ein Lieferantenvorfall ihre Betriebe betrifft. Proaktive Kommunikation - bestätigen, dass du dir der CVE bewusst bist, deine beurteilte Exposition angeben und einen Zeitplan für Remediation oder eine abschließende Bestimmung zusagen - ist erheblich besser für die Beziehung als darauf zu warten, gefragt zu werden. Ein im Voraus vorbereitetes Kommunikationstemplate für "CVE in einer Abhängigkeit" ist wert, vorhanden zu sein. Die Anwendungsentwicklungs-Teams, mit denen wir arbeiten und die einen Supply-Chain-Incident durchgemacht haben, produzieren invariant danach ein Runbook; es ist nützlicher, eines vorher zu erstellen.

Die vierte Aufgabe, sobald Scope und Ausnutzbarkeit festgestellt sind, ist Remediation: die Abhängigkeit aktualisieren, den Fix verifizieren und erneut deployen. Wenn die Bibliothek noch keine behobene Version hat, beurteile, ob sie vorübergehend entfernt, durch eine Alternative ersetzt oder auf Anwendungsebene gemindert werden kann, während ein Fix abgewartet wird. Dokumentiere die Entscheidung und den Zeitplan.

Unter NIS2 gilt: Wenn der Incident den Schwellenwert eines "erheblichen" Incidents erreicht - eines, der schwere betriebliche Störungen verursacht oder verursachen könnte oder andere Entitäten betrifft - gilt die 24-Stunden-Frühwarnung an das nationale CSIRT. Den Supply-Chain-Incident in dein breiteres Incident-Response-Runbook integriert zu haben, mit einem klaren Auslöser für die NIS2-Meldebewertung, verhindert, dass der regulatorische Schritt unter Druck übersehen wird.

Das Evidenz-Paket zusammenstellen

Enterprise-Kunden, die NIS2-getriebene Lieferanten-Due-Diligence durchführen, fragen zunehmend nach einem Standardsatz von Artefakten. Diese griffbereit zu haben - statt sie für jeden Fragebogen neu zu generieren - spart erhebliche Ingenieurzeit und verkürzt Verkaufszyklen. Das Kernpaket für ein mittelgroßes SaaS im Jahr 2026 ist: ein aktuelles Produktionsscope-SBOM (CycloneDX JSON bevorzugt), ein VEX-Dokument oder äquivalentes Suppression-Register für CVEs, die als nicht ausnutzbar markiert sind, ein Scan-Bericht deines Dependency-Scanners mit dem aktuellen Status und Triage-Entscheidungen, eine kurze Beschreibung deines SBOM-Generierungsprozesses und wo Provenance-Attestierungen veröffentlicht sind, sowie eine Zusammenfassung deines Response-Prozesses für Supply-Chain-Incidents.

Dieses Paket, regelmäßig aktualisiert und auf Anfrage bereit zu teilen, verwandelt einen Beschaffungs-Sicherheitsfragebogen von einem drei-Wochen-Prozess in eine Zwei-Tage-Antwort. Es bildet auch den Kern der Supply-Chain-Sicherheitsdokumentation, die ein NIS2-Audit erwarten würde.

Wolf-Tech arbeitet mit in Berlin ansässigen und EU-SaaS-Teams zusammen, um Supply-Chain-Sicherheitsprogramme zu entwickeln und umzusetzen - SBOM-Pipelines, Triage-Richtlinien, Provenance-Attestation und Incident-Runbooks -, die proportional zur Teamgröße und verteidigbar gegenüber NIS2-Prüfung sind. Wenn deine Beschaffungsgespräche bereits Supply-Chain-Fragen aufwerfen oder du dem Audit voraus sein möchtest statt darauf zu reagieren, melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io, um ein Gespräch zu vereinbaren.