Software Supply Chain Security: Warum 70–90 % Ihres Codes ein unterschätztes Risiko sind
70–90 % moderner Software bestehen aus fremdem Code. Ohne Transparenz, zentrale Kontrolle und sichere Prozesse werden Dependencies, Build-Pipelines und Artefakte zum Einfallstor für Angriffe, regulatorische Risiken und schwer kontrollierbare Sicherheitsvorfälle weltweit.
Inhaltsverzeichnis
Moderne Software entsteht nicht mehr im Alleingang. Der Großteil jeder Applikation – Schätzungen sprechen von 70 bis 90 Prozent – besteht aus fremdem Code: Open-Source-Libraries, Third-Party-Dependencies, automatisierte Build-Pipelines, externe Services. Das macht Entwicklungsteams schneller, flexibler und wettbewerbsfähiger. Aber es macht sie auch angreifbar – auf eine Art, die viele noch immer unterschätzen.
Log4Shell hat es 2021 gezeigt. Die NPM-Hacks rund um s1ngularity und shai hulud haben es bestätigt. SolarWinds hat es auf staatlicher Ebene demonstriert. Das Muster ist immer dasselbe: Angreifer suchen sich nicht das härteste Ziel. Sie suchen das verbreitetste. Und genau das sind oft die Libraries und Tools, denen Engineering-Teams täglich blind vertrauen.
Dieser Artikel erklärt, was Software Supply Chain Security wirklich bedeutet, welche Fehler in der Praxis immer wieder auftreten und wie ihr – Schritt für Schritt – Kontrolle über eure Lieferkette zurückgewinnt. Mit Praxisbeispielen aus echten Projekten, ohne Tool-Pitch.
Was ist Software Supply Chain Security?
Software Supply Chain Security beschäftigt sich mit der Absicherung aller Prozesse, Tools, Artefakte und Komponenten, die aus Source-Code eine lauffähige Applikation machen – von der ersten Zeile Code bis zum Betrieb in der Produktion.
Das klingt abstrakt. Konkret bedeutet es: Alles, was zwischen dem Moment, in dem ein Entwickler Code schreibt, und dem Moment, in dem dieser Code beim Nutzer läuft, eine Rolle spielt, gehört zur Software-Lieferkette – und ist damit ein potenzieller Angriffsvektor.
Was gehört zur Software-Lieferkette?
Die Software-Lieferkette umfasst deutlich mehr, als die meisten Teams auf Anhieb benennen würden:
Jeder dieser Punkte ist eine mögliche Einfallstür. Nicht, weil die Technologie grundsätzlich unsicher ist – sondern weil jedes externe Element ein Risiko mitbringt, das nicht im eigenen Code liegt und damit oft auch nicht im eigenen Blickfeld ist.
Der Unterschied zwischen Supply Chain Security und Application Security
Ein häufiges Missverständnis in Kundengesprächen: Supply Chain Security und Application Security werden gleichgesetzt oder verwechselt.
Application Security befasst sich mit dem Code selbst – Architektur, Logik, Schwachstellen in der eigenen Implementierung. Software Supply Chain Security setzt eine Ebene früher und weiter an: Sie fragt nicht, ob der eigene Code sicher ist, sondern ob die gesamte Umgebung, in der dieser Code entsteht, verteilt und betrieben wird, integer ist.
Die größte Fehlannahme: „Wir nutzen doch Standard-Libraries“
Wenn es eine Überzeugung gibt, die sich in Gesprächen mit Engineering-Teams hartnäckig hält, dann diese: Bekannte Libraries sind sichere Libraries.
Die Logik dahinter klingt intuitiv. Wenn Millionen von Projekten dieselbe Library verwenden, wird sie doch intensiv geprüft, schnell gepatcht und von der Community überwacht. In der Theorie stimmt das. In der Praxis ist es diametral falsch.
Log4Shell, S1ngularity & Co.: Was diese Vorfälle gemeinsam haben
Log4J war zum Zeitpunkt der Entdeckung von Log4Shell in nahezu jeder Java-Applikation verbaut. Genau das machte den Vorfall so verheerend. Die Schwachstelle war trivial ausnutzbar, der Blast Radius global. Wer Log4J verwendete – und das tat fast jeder – war exponiert.
Ähnliches gilt für die NPM-Supply-Chain-Angriffe rund um s1ngularity und shai hulud: Pakete mit Millionen Downloads pro Tag, kompromittiert durch Angreifer, die genau wussten, dass Popularität keine Sicherheitsgarantie ist. Im Gegenteil – sie ist ein Anreiz.
Das Muster ist konsistent: Je weiter verbreitet ein Artefakt, desto attraktiver ist es als Ziel. Denn ein erfolgreicher Angriff auf eine einzige, weit verbreitete Komponente ermöglicht es, Tausende Downstream-Projekte gleichzeitig zu kompromittieren.
Warum Teams das Risiko trotzdem in Kauf nehmen
Es wäre unfair zu behaupten, dass Teams das Risiko ignorieren, weil sie es nicht kennen. Die Awareness ist in den meisten Organisationen vorhanden. Das eigentliche Problem liegt woanders: im Trade-off zwischen Geschwindigkeit und Sicherheit.
Neue Libraries bringen Features. Sie ermöglichen State-of-the-Art-Implementierungen mit minimalem Aufwand. Wer sie einsetzt, liefert schneller. Wer auf gehärtete, gescannte Artefakte wartet, verliert Zeit.
Dieser Trade-off ist real – und er wird täglich in Teams getroffen, meistens implizit, ohne formalen Prozess.
Das Ergebnis: Dependency Security wird nicht aus Unwissenheit vernachlässigt, sondern weil der kurzfristige Nutzen sichtbarer ist als das langfristige Risiko.
Die häufigsten Schwachstellen in der Praxis
In der Beratungspraxis zeigen sich über Branchen und Unternehmensgrößen hinweg immer wieder dieselben Muster. Sie betreffen selten die technische Kompetenz der Teams – sondern Prozesse, Tooling und organisatorische Strukturen.
Schritt für Schritt: So baut ihr eine sichere Software-Lieferkette auf
Der häufigste Fehler beim Aufbau einer sicheren Lieferkette ist der Big-Bang-Ansatz: Alles auf einmal, sofort, unternehmensübergreifend. Das scheitert nicht an fehlendem Willen, sondern an fehlender Grundlage.
Der richtige Ansatz ist iterativ – und er beginnt nicht mit Tooling, sondern mit Transparenz.
1. Inventarisierung – Wisst ihr, was ihr wirklich verwendet?
Bevor ihr irgendetwas absichern könnt, müsst ihr wissen, was überhaupt existiert. Das klingt trivial. In der Praxis ist es für viele Organisationen der schwierigste Schritt.
Inventarisierung bedeutet: Welche Dependencies werden verwendet? In welchen Versionen? Von welchen Teams? Aus welchen Quellen? Auf diese Fragen müssen verlässliche Antworten existieren – nicht als Excel-Liste, die einmal im Quartal aktualisiert wird, sondern als lebendiges, maschinenlesbares Inventar.
Erst wer diesen Überblick hat, kann beginnen, Risiken zu bewerten, Prioritäten zu setzen und gezielt zu handeln.
2. Zentralisierung – Eine kontrollierte Quelle für alle Teams
Der nächste logische Schritt ist die Einführung eines zentralen Artefakt-Repositories. Alle Teams, alle Applikationen, alle Build-Prozesse beziehen ihre Dependencies aus einer einzigen, kontrollierten Quelle.
Dieser zentrale Punkt wird zum Dreh- und Angelpunkt der gesamten Supply-Chain-Security-Strategie. Er ermöglicht Policy-Enforcement (welche Pakete sind erlaubt, welche nicht?), systematisches Scanning, Maturity-Level-Modelle für Artefakte und einen klaren Audit-Trail.
Solange Dependencies aus dem freien Internet gezogen werden, gibt es keinen Hebel für Kontrolle. Mit einem zentralen Repository entsteht dieser Hebel.
3. Security Gates in CI/CD etablieren
Auf Basis eines zentralen Repositories und eines vollständigen Inventars können CI/CD Gates sinnvoll eingesetzt werden. Automatisierte Scans, Policy-Checks, Pull-Request-Blockierungen bei kritischen Schwachstellen – das sind mächtige Werkzeuge.
Aber: Sie sind sinnlos ohne die Grundlage aus Schritt 1 und 2. CI/CD Security-Gates, die auf lückenhaften oder dezentralen Daten aufsetzen, geben ein falsches Sicherheitsgefühl. Der richtige Ansatz: zunächst informativ einführen (Sichtbarkeit schaffen, ohne Prozesse zu blockieren), dann schrittweise auf enforced umstellen, wenn die Grundlage stabil ist.
Der Idealzustand: Reproduzierbare, attestierte Software
Was ist das Ziel? Wohin führt dieser Weg, wenn er konsequent gegangen wird?
Der Idealzustand lässt sich in zwei Begriffen zusammenfassen: Reproduzierbarkeit und Attestierung.
Was bedeutet Reproduzierbarkeit in der Praxis?
Warum das regulatorisch relevant wird (NIS2, EU CRA)
Aus der Praxis: Zwei Beispiele aus Fullstacks-Projekten
Theorie ist das eine. Was diese Prinzipien in der Praxis bedeuten, zeigen zwei anonymisierte Beispiele aus Fullstacks-Projekten.
Elektronikhersteller: Maturity Levels für Artefakte
Bei einem großen Elektronikhersteller hat Fullstacks das Artefakt-Management grundlegend neu strukturiert. Der Ausgangspunkt: Keine einheitlichen Namenskonventionen, keine definierten Reifestufen, kein systematischer Überblick über den Sicherheitsstatus einzelner Komponenten.
Die Lösung: Ein mehrstufiges Maturity-Level-Modell für Softwareartefakte jeglicher Art. Jedes Artefakt durchläuft definierte Reifestufen – geprägt durch Scans, Policy-Abnahmen und Verifikationsschritte. Nur Artefakte, die mehrfach gescannt und durch definierte Policies abgenommen wurden, können bestimmte Produktionsumgebungen erreichen. Das Ergebnis ist ein kontrollierbarer, auditable Prozess statt eines Wildwuchses aus unkontrollierten Quellen.
Automotive: Incident Response bei einem Supply-Chain-Vorfall
In der Automotive-Branche begleitete Fullstacks ein Unternehmen, das Opfer einer gezielten Attacke auf seine Software-Lieferkette wurde. Der Vorfall zeigte in aller Deutlichkeit, was passiert, wenn keine strukturierte Incident-Response-Kompetenz vorhanden ist: Der Blast Radius wächst unkontrolliert, weil niemand weiß, welche Systeme und Artefakte betroffen sind.
Fullstacks unterstützte das Unternehmen dabei, schnell und aktiv zu reagieren, den Schaden einzugrenzen und gleichzeitig die strukturellen Voraussetzungen zu schaffen, damit ein solcher Vorfall beim nächsten Mal früher erkannt und wirksamer eingedämmt werden kann.
Was unterscheidet Teams, die jetzt handeln, von denen, die abwarten?
Die Frage ist legitim: Warum jetzt? Warum nicht warten, bis ein Vorfall passiert, und dann reagieren?
Die Antwort liegt in der Natur von Supply-Chain-Angriffen. Im Gegensatz zu einem direkten Angriff auf eine Applikation sind Supply-Chain-Kompromittierungen oft monatelang unentdeckt. Wenn sie auffallen, ist der Schaden längst angerichtet. Reaktion ist dann teuer, langsam und öffentlichkeitswirksam – selten in der gewünschten Richtung.
Teams, die ihre Software-Lieferkette proaktiv managen, haben einen fundamentalen Vorteil: Sie wissen, womit sie arbeiten. Sie können Risiken steuern – bewusst, priorisiert, bevor ein Vorfall eintreten muss. Diese Kompetenz ist nicht nur ein Sicherheitsgewinn. Sie ist ein Wettbewerbsvorteil in regulierten Märkten, bei Audits und gegenüber Kunden, die zunehmend nach Nachweisen fragen.
Wer abwartet, weiß oft gar nicht, wie seine Software wirklich zustande kommt. Und das ist – unabhängig von Branche und Unternehmensgröße – keine tragfähige Position mehr.
Fazit: Transparenz ist der erste Schritt zur Kontrolle
Software Supply Chain Security ist kein Projekt, das man abschließt. Es ist eine Kompetenz, die man aufbaut – iterativ, team- und unternehmensübergreifend, auf einem soliden Fundament aus Inventarisierung und Zentralisierung.
Der erste Schritt ist nicht der schwierigste. Er ist der wichtigste: Wisst, womit ihr arbeitet.
Fullstacks Assessment Workshop: Euer Einstieg in sichere Supply Chain Security
Wenn ihr merkt, dass euch Struktur oder Transparenz in eurer Software Supply Chain fehlt – genau hier setzen wir an. Der Einstieg bei Fullstacks ist ein halbtägiger Assessment Workshop. Wir setzen uns mit eurem Team zusammen, analysieren mit Experten aus mehreren Domänen euren konkreten Status quo und identifizieren, wo der größte Handlungsbedarf liegt. Das Ergebnis ist kein generisches Framework – sondern ein priorisierter Aktionsplan, zugeschnitten auf eure Infrastruktur, eure Teams und eure regulatorischen Anforderungen.
Weitere Blog-beiträge
70–90 % moderner Software bestehen aus fremdem Code. Ohne Transparenz, zentrale Kontrolle und sichere Prozesse werden Dependencies, Build-Pipelines und Artefakte zum Einfallstor für Angriffe, regulatorische Risiken und schwer kontrollierbare Sicherheitsvorfälle weltweit.
Application Security ist kein Thema für das Security-Team – es ist ein echtes Engineering-Problem. Die gefährlichsten Schwachstellen entstehen im Code, täglich. Was das kostet und wie Teams konkret gegensteuern können.
Software-Hersteller machen SaaS zur Default-Option – und Container zur Voraussetzung für alle, die On-Premises bleiben wollen. Für Betreiber kritischer Infrastruktur stellt sich damit nicht die Frage „ob“, sondern „auf welcher Grundlage“ entschieden wird.
Viele Unternehmen investieren massiv in Kubernetes und Cloud – doch Releases werden komplexer, Kosten steigen und Effizienzgewinne bleiben aus. Woran liegt das?
Secrets sind das unsichtbare Rückgrat moderner IT-Landschaften. API-Keys, Datenbank-Credentials, Zertifikate oder Tokens sichern Identitäten, Services und ganze Plattformen ab. Ohne sie läuft nichts – und genau deshalb gehören sie zu den sensibelsten Bestandteilen jeder IT-Architektur.
Technologie mit Verantwortung – eigentümergeführt gewachsen in Österreich, Deutschland und der Schweiz. FULLSTACKS blickt im Februar 2026 auf fünf Jahre Unternehmensgeschichte zurück. Heute sind wir 3 Unternehmen in der D-A-CH-Region.
VMware-Alternativen bieten Unternehmen die Chance, Kosten zu senken, die Kontrolle über ihre Plattformen zurückzugewinnen und gleichzeitig Stabilität und Zukunftsfähigkeit sicherzustellen. Ein strukturierter Exit-Plan, Quick Wins und ein fundierter Exit Check machen den Umstieg planbar und risikoarm.
Das Projekt Ingress-NGINX wird im März 2026 offiziell eingestellt. Bis dahin läuft nur noch„best-effort“-Maintenance – danach gibt es keine Releases, keine Bugfixes und keine SecurityUpdates mehr. Was müssen Plattform-Teams jetzt entscheiden?
München, 2. Dezember 2025 – FULLSTACKS wurde in München von Cisco / Splunk mit dem „Service Partner of the Year ALPS“ Award ausgezeichnet. Die Ehrung würdigt die außergewöhnliche [...]
Wien, 1. Oktober 2025 – FULLSTACKS, führender Anbieter für DevOps, Observability, Cloud-Native und Security im DACH-Raum, präsentiert mit Oktober 2025 sein neues Markenbild. Die visuelle Neugestaltung ist Ausdruck eines [...]