Software Supply Chain Security als Wettbewerbsfaktor: Warum Sicherheit heute Vertrauen schafft

Es gilt heute längst als Binsenweisheit: IT-Sicherheit umfasst mehr als Kennwortregeln, Firewalls und Virenscanner. Das wird vor allem mit Blick auf die wachsende Komplexität moderner Software-Stacks deutlich. Sie bergen ein Netz an Abhängigkeiten, das neue Risiken mit sich bringt. Denn jede zusätzliche Komponente erweitert die Angriffsfläche – oft außerhalb der eigenen direkten Kontrolle. Vertragsstrafen, persönliche Geschäftsführerhaftung oder finanzielle Schäden werden in Warnungen zuerst aufgeführt. Doch Reputationsschäden und Vertrauensverlust wiegen meist schwerer.

Neue Realität. Neue Gefahren.

Das Thema Software Supply Chain Security nimmt an Bedeutung zu – zumindest sollte es das. Teils fehlt in Unternehmen das Bewusstsein, dass hier große Gefahren lauern. Teils sind schlichtweg die Ressourcen nicht vorhanden, um Maßnahmen zu ergreifen. Fehlt Transparenz, was sich in der eigenen Software-Lieferkette verbirgt, wird Schutz zur Glückssache.

Denn die Software-Lieferkette rückt ins Visier von Angreifern. Am häufigsten nutzen sie dafür Schwachstellen in der Lieferkette aus. Doch auch gezielte Angriffe mit Malware und bösartigen Pakten als Vektoren nehmen laut der Umfrage von Ponemon Institute und Black Duck rapide zu (Quelle: „The State of Software Supply Chain Security Risk“).

Risiko „Drittanbieterkomponenten“

Das Hauptproblem: Moderne Software entsteht selten vollständig im eigenen Haus. Sie setzt sich aus Open-Source-Komponenten, Libraries, Frameworks, Build-Artefakten, Containern und Binaries zusammen – Bausteinen, die in unterschiedlichsten Versionen, Abhängigkeiten und Herkunftskontexten zusammenwirken. Der Eigenanteil am Code schrumpft dabei kontinuierlich.

Mit jeder zusätzlichen Komponente wächst jedoch die Zahl der Abhängigkeiten – oft exponentiell und meist unsichtbar. Die Risiken liegen im Detail – ob in transitiven Dependencies, die indirekt eingebunden werden, ob in veralteten oder nicht mehr gepflegten Bibliotheken, bei unbekannten Build-Artefakten oder durch fehlenden Überblick, welche Versionen tatsächlich im Produkt landen.

In der Folge verlieren Unternehmen schleichend die Kontrolle über ihre eigene Softwarebasis. Sicherheit wird zur Annahme statt zur überprüfbaren Eigenschaft.

Vertrauen am seidenen Faden

Die Kundenbeziehung kann dies ebenso nachdrücklich beeinflussen. Wer von Security-Vorfällen und ungeklärten Abhängigkeiten erfährt, stellt nicht nur technische Fragen, sondern äußert zu Recht grundsätzliche Bedenken.

• Wie gut kennt der Anbieter sein eigenes Produkt?
• Wie belastbar sind Aussagen zu Sicherheit, Verfügbarkeit und Compliance?
• Wie verlässlich ist der Umgang mit Risiken, die nicht auf den ersten Blick sichtbar sind?

Gerade im B2B-Umfeld wird Software-Sicherheit zunehmend zum Vertrauensfaktor. Kunden erwarten heute nicht zwingend absolute Fehlerfreiheit, wohl aber Transparenz, Verantwortungsbewusstsein und die Fähigkeit, Risiken nachvollziehbar zu managen. Fehlt diese Grundlage, geraten Geschäftsbeziehungen ins Schwanken – sei es durch Nachfragen in Security-Fragebögen, verschärfte Vertragsklauseln oder verlängerte Entscheidungsprozesse im Einkauf.

Software Supply Chain Security wirkt damit weit über die IT hinaus. Sie beeinflusst, wie glaubwürdig ein Anbieter auftritt, wie schnell neue Kunden gewonnen werden können und wie stabil bestehende Beziehungen bleiben.

Handeln verpflichtend!

Die Dringlichkeit verdeutlicht auch die Gesetzeslage. Immer mehr Regularien fordern von der Geschäftsetage, aktiver zu werden – weg vom reinen Reagieren auf Vorfälle, hin zu präventiver Verantwortung entlang der gesamten Software-Lieferkette.

Mit dem Cyber Resilience Act (CRA) rückt erstmals die Sicherheit von Softwareprodukten über ihren gesamten Lebenszyklus in den Fokus. Hersteller und Anbieter müssen künftig nachweisen können,

• welche Komponenten in ihren Produkten stecken,
• wie Risiken identifiziert und bewertet werden und
• wie mit Schwachstellen kontinuierlich umgegangen wird.

Transparenz über die eigene Software Supply Chain wird damit zur Voraussetzung – nicht zur Kür. Auch NIS2, DORA und vergleichbare Regelwerke folgen diesem Prinzip: Sie verlangen kein punktuelles Sicherheitskonzept, sondern nachvollziehbare Prozesse, klare Verantwortlichkeiten und ein waches Auge auf mögliche Risiken. Der Fokus verschiebt sich deutlich vom reinen Incident Response hin zu belastbarer Vorsorge.

Erwartungshaltung entsprechen – aber wie?

Was es also braucht, ist in erster Linie ein Überblick – über Komponenten und Abhängigkeiten in der Software-Lieferkette. Eine Software Bill of Materials, kurz SBOM, ist hier häufig Mittel der Wahl. Sie enthält detaillierte Angaben über die in der Software verwendeten Bibliotheken und deren Versionsstand. Die führenden Formate dafür sind CycloneDX und SPDX, die als JSON, XML oder YAML abgebildet sind.

Aus naheliegenden Gründen sollten SBOMs für Software nicht per Hand erzeugt werden: Schon bei kleineren Softwareprojekten läuft das auf eine ineffiziente Sisyphusarbeit mit hohem Fehlerpotenzial hinaus. Zudem sind manuell erstellte SBOMs kaum konsistent aktuell zu halten, da sich Abhängigkeiten im Rahmen von Builds, Updates oder Patches regelmäßig ändern. Eine belastbare SBOM erfordert daher zwingend den Einsatz geeigneter Werkzeuge, die automatisiert erzeugt werden und bei jeder relevanten Änderung der Software aktualisiert werden können.

Idealerweise ist die SBOM-Erstellung fest in den CI/CD-Prozess integriert, sodass sie automatisch im Zuge jedes Builds generiert und versioniert wird.

Aber auch bei SBOM-Tools gibt es Unterschiede und ein genauerer Blick auf die Funktionsweise und die eigenen Anforderungen ist mehr als sinnvoll:

• Ist Zuriff auf den Quellcode erforderlich?

  Viele Werkzeuge stützen sich auf die Analyse des Quellcodes, um Abhängigkeiten und Fremdpakete in einer Software zu identifizieren. Das funktioniert gut, solange dieser – wie bei Open-Source-Produkten – vorliegt. Spätestens bei proprietärer Closed-Source Software stoßen solche Tools jedoch offensichtlich an eine Grenze, denn wo kein Quellcode, da keine Analyse. Darüber hinaus ist eine auf Basis des Quellcodes erzeugte SBOM lediglich eine Momentaufnahme aus Sicht des Entwicklungsprozesses, die den Stand vor der Erzeugung des eigentlichen Endproduktes widerspiegelt. Vergleichbar mit einer Stückliste, die anhand einer Bauanleitung erstellt wird: „In der Software sollten diese und jene Komponenten enthalten sein“. Über das tatsächliche Endprodukt entscheidet jedoch der Build-Prozess, welcher aus dem Quellcode bzw. der Bauanleitung die konkrete Software erzeugt. Insbesondere bei Containern wird in diesem Prozess noch zusätzliche Software hinzugeladen, die nicht Teil der originären Software ist und bei einer reinen Quellcode-Analyse nicht erfasst wird. Beim Schritt „Bau der Software“ kann also allerhand passieren, was das Endprodukt beeinflusst, aber nicht direkt aus der Betrachtung des Quellcodes ersichtlich ist.

  Geht man also von der Frage aus „Wie belastbar sind Aussagen über die Zusammensetzung einer Software?“, muss die Antwort darauf fast unweigerlich vom fertigen Endprodukt ausgehend gesucht und gefunden werden. Die Wahrheit steckt hier buchstäblich im Binary.

• Wie geht das SBOM-Tool mit Binärdaten um?

  Binärdaten spielen in zweierlei Hinsicht eine Rolle im Bauprozess und damit der Zusammensetzung von Software: Einerseits als Endprodukt des Compiler-Prozesses, welcher aus dem Quellcode die ausführbaren Binärdaten (Kompilat) für die jeweilige Ziel-CPU erzeugt, beziehungsweise das fertig ausführbare Container-Image.

  Für SBOM- und CRA-Zwecke sind andererseits neben Quellcode auch ausgelieferte binäre Artefakte zu erfassen, die als Assets bereitgestellt und zur Laufzeit in Hardware-Komponenten geladen werden. Als typische Beispiele wären hier Firmware für Netzwerkelemente, binäre KI-Modelle und Accelerator-Blobs bzw. Microcode zu nennen.

• Kann das Werkzeug einfach in bestehende Build- und Deployment-Prozesse eingebaut werden?

  Eine SBOM stellt eine vergängliche Momentaufnahme des Softwarezustands zum Zeitpunkt der Analyse dar. Ihre Aussagekraft verliert an Gültigkeit, sobald sich die Softwaredefinition oder indirekte Abhängigkeiten, etwa zu verwendeten Bibliotheken, ändern. Das erfolgt beispielsweise bei jeder erneuten Kompilierung.

  Da Container-Images darüber hinaus ein vollständiges Software-Ökosystem einschließlich Laufzeit, Bibliotheken und Systemkomponenten enthalten, kann sich ihre Zusammensetzung mit jedem Build-Prozess sogar erheblich verändern. Daraus ergibt sich die Notwendigkeit, SBOMs automatisiert und wiederholbar in den Build- und Deployment-Prozess zu integrieren, um ihre Aktualität und regulatorische Aussagekraft sicherzustellen.

• Welche weiteren Informationen werden abseits der SBOM in die Analyse aufgenommen? Eine SBOM stellt lediglich eine Stückliste der Softwarekomponenten dar. Sie trifft aber keine Aussagen darüber, welche konkreten Risiken damit verbunden sein können: „Meine Software besteht aus Framework X Version 1, sowie Library Y und Z Version 2.“ Aber was bedeutet das? Gibt es bekannte Sicherheitslücken für diese Komponenten in dieser Version und, falls ja, welcher Art entsprechen sie und wie schwerwiegend sind sie?

  SBOM ist also nicht gleichzusetzen mit einer Risikobewertung. Das bedeutet: Sie gibt tiefe Einblicke über die Software-Komponenten und ermöglicht es, nachzuweisen, dass diese bekannt und überwacht werden (regulatorische Anforderung). Welche Maßnahmen für mehr Sicherheit nötig sind, stellt sie meist aber nicht umfassend und vor allem nutzerfreundlich dar. Daher bieten sich Lösungen an, die zudem einen Security-Report erstellen.

In jedem Fall sollten Verantwortliche also bei der Auswahl darauf achten, dass

• Ergebnisse für die SBOM nicht ausschließlich während des Software-Entwicklungsprozesses generiert werden – das greift zu kurz.
• die fertig kompillierte und gebaute Software und deren Abhängigkeiten und Komponenten analysiert werden.
• über die SBOM-Generierung hinaus auch ein automatischer Abgleich gegen aktuelle CVE-Datenbanken erfolgt – nur so lassen sich alle bekannten Schwachstellen einbeziehen.

Zielsetzung: sicher und vertrauenswürdig

Die Relevanz einer sicheren Software Supply Chain steht angesichts der zunehmenden Attacken längst nicht mehr zur Debatte. Doch Unternehmen müssen auch davon wegkommen, Software Supply Chain Security als reines Compliance-Thema zu betrachten, dass es möglichst schnell abzuhaken gilt. Denn damit greifen sie zu kurz und echte Sicherheitsrisiken bleiben unbeachtet. Um Kunden also jederzeit eine vertrauensvolle Partnerschaft – beziehungsweise ein integres Produkt – bieten zu können, erfordert es Transparenz, Kontext und eine kontinuierliche Bewertung – in Form von SBOM und Security-Report.

Sie möchten Ihre Kundenbeziehungen nicht aufs Spiel setzen? Dann sollten Sie dringend Software Supply Chain Security umsetzen – eine Tool-Empfehlung: der Application Supply Guard!

Jetzt Termin vereinbaren