Das schwächste Glied sitzt beim Lieferanten

TL;DR:
Problem: Angreifer greifen zunehmend nicht mehr direkt Unternehmen an, sondern deren Lieferanten. Ein einziger kompromittierter Lieferant kann den Zugang zu Dutzenden von Organisationen ermöglichen (Beispiel: SolarWinds).
Warum Audits nicht ausreichen: Ein ISO/IEC-27001-Zertifikat oder ein ausgefüllter Fragebogen belegen keine tatsächliche Widerstandsfähigkeit. Eine sichere Softwareversion ist wertlos, wenn der Entwicklungsprozess selbst kompromittiert wurde.
Was zu tun ist: Fordern Sie praktische Nachweise wie Penetrationstests, Red Teaming, sichere CI/CD-Prozesse, Secure SDLC und ein transparentes SBOM.
Regulatorik: NIS2 und der Cyber Resilience Act verlagern die Verantwortung für die Sicherheit der Lieferkette bereits heute direkt auf das Management.

Die Digitalisierung in Europa bringt ein bislang beispielloses Maß an Vernetzung zwischen Unternehmen, ihren Lieferanten und Technologiepartnern mit sich. Lieferketten spielen nicht nur in der Fertigungs- und Automobilindustrie eine entscheidende Rolle, sondern auch in Bereichen wie IT, Telekommunikation, Energieversorgung und anderen Sektoren der kritischen Infrastruktur. Genau diese Vernetzung eröffnet neue Möglichkeiten für Angreifer, die sich zunehmend nicht mehr direkt auf Unternehmen, sondern auf deren Lieferanten konzentrieren. In diesem Artikel zeigen wir, warum ein Audit oder eine Zertifizierung allein nicht mehr ausreicht, um die tatsächliche Widerstandsfähigkeit eines Lieferanten objektiv zu bewerten, und wie neue europäische Regulierungen den Ansatz zur Cybersicherheit im gesamten Lieferketten-Ökosystem verändern.

Lieferanten als Einfallstor

Obwohl große Unternehmen oft Millionen von Euro in den Schutz ihres Perimeters, ihrer Infrastruktur und die Schulung ihrer Mitarbeitenden investieren, wählen Angreifer häufig den Weg des geringsten Widerstands. Anstatt Unternehmen direkt anzugreifen, konzentrieren sie sich auf kleinere Lieferanten oder Dienstleister, über die sie deutlich einfacher an ihr eigentliches Ziel gelangen können. Ein bekanntes Beispiel ist der SolarWinds-Vorfall, bei dem Angreifer den Entwicklungs- und Update-Prozess einer Software kompromittierten. Dadurch gelangte Schadcode eines Softwareanbieters zu Tausenden von Organisationen, darunter Regierungsbehörden und große Unternehmen.

Neue Trends

Auch Unternehmen selbst reagieren auf die wachsenden Risiken in der Lieferkette. Ein wichtiger Treiber ist die strengere Regulierung durch Vorgaben wie die NIS2-Richtlinie oder den Cyber Resilience Act. Die NIS2-Richtlinie erweitert den Kreis der regulierten Unternehmen, führt strengere Anforderungen an das Management von Cyberrisiken – einschließlich der Sicherheit der Lieferkette – ein und erhöht die Verantwortung des Managements für die Cybersicherheit erheblich.

Das gestiegene Interesse ist jedoch auch auf die zunehmende Zahl von Sicherheitsvorfällen zurückzuführen. Unternehmen verlangen von ihren Lieferanten immer häufiger konkrete Nachweise technischer Resilienz, etwa in Form von Penetrationstests für Anwendungen oder IT-Lösungen vor deren Beschaffung – und nicht nur ausgefüllte Sicherheitsfragebögen oder Audits nach ISO/IEC 27001.

Auch Citadelo beobachtet diesen Trend. Während 2024 der Finanzsektor die Nachfrage nach Penetrationstests anführte, zeigt unser Ethical Hacking Report 2025, dass Softwareentwickler (Software Houses) inzwischen das zweithäufigste getestete Segment darstellen und 11 % aller Projekte ausmachen. Gleichzeitig erkennen Unternehmen zunehmend, dass der Mensch weiterhin das schwächste Glied in der Sicherheitskette ist. Dies zeigt sich unter anderem im steigenden Interesse an simulierten Phishing- und Vishing-Angriffen, die die Reaktionsfähigkeit von Mitarbeitenden auf reale Bedrohungen überprüfen.

Möglichkeiten zur Überprüfung der Sicherheit von Lieferanten

Immer mehr Unternehmen ergänzen daher klassische Penetrationstests durch fortgeschrittene Verfahren zur Bewertung der Widerstandsfähigkeit von Lieferanten, beispielsweise durch Red Teaming. Dabei wird das Verhalten eines realen Angreifers über technische und organisatorische Ebenen hinweg simuliert.

Zu Red-Teaming-Projekten gehören häufig auch Social-Engineering-Angriffe wie Phishing- oder Vishing-Kampagnen, mit denen die Reaktionsfähigkeit der Mitarbeitenden auf Angriffe überprüft wird. Gerade die Kombination aus technischen Tests und der Überprüfung des menschlichen Faktors liefert ein realistischeres Bild der tatsächlichen Cybersicherheitslage eines Lieferanten.

Bei Citadelo beobachten wir seit Jahren, dass Unternehmen zunehmend genau solche praktischen Nachweise der Sicherheitsresilienz verlangen, anstatt sich ausschließlich auf die formale Erfüllung von Audit-Anforderungen zu verlassen.

KI-Dienste als Teil des Lieferketten-Ökosystems

Mit der zunehmenden Nutzung von künstlicher Intelligenz und Large Language Models (LLMs) rückt auch die Sicherheit von KI-Systemen stärker in den Fokus. Unternehmen beschäftigen sich nicht mehr nur mit der Sicherheit ihrer eigenen Anwendungen, sondern auch mit den Risiken, die durch externe KI-Modelle entstehen. Daher wird das Penetrationstesten von KI-Modellen und Chatbots zunehmend zu einem festen Bestandteil moderner Sicherheitsprüfungen.

Die jüngsten Einschränkungen beim Zugang zu ausgewählten Modellen des Unternehmens Anthropic für europäische Nutzer haben zudem gezeigt, dass die Abhängigkeit von einem einzigen KI-Anbieter erhebliche betriebliche und lieferkettenbezogene Risiken mit sich bringen kann.

Softwaresicherheit beginnt im Entwicklungsprozess

Trotz des steigenden Interesses an Sicherheitstests für Softwareprodukte sehen wir weiterhin erhebliches Verbesserungspotenzial bei der Absicherung von Softwareentwicklungsprozessen – insbesondere bei der Einführung von Secure-SDLC-Prinzipien und dem Schutz von CI/CD-Pipelines.

Letztlich spielt es keine Rolle, wie sicher eine bestimmte Softwareversion zum Zeitpunkt eines Tests erscheint, wenn der Lieferant die Sicherheit des Entwicklungsprozesses selbst vernachlässigt. Risiken durch Insider Threats, Kompromittierungen über Drittanbieter-Abhängigkeiten infolge von Dependency-Confusion-Angriffen oder sogar schädliche Erweiterungen in Entwicklungsumgebungen können dazu führen, dass die fertige Anwendung kompromittiert wird.

So kann unmittelbar nach einem erfolgreich bestandenen Penetrationstest bereits eine neue, kompromittierte Version der Anwendung beim Kunden ausgerollt werden.

Sicherheit muss im gesamten SDLC verankert sein

Sicherheit darf nicht nur anhand der fertigen Anwendung bewertet werden. Sie muss über den gesamten Software Development Life Cycle (SDLC) hinweg integriert sein.

Sicherheit beginnt bei der Architekturplanung und setzt sich über die Arbeit mit dem Quellcode, die Verwaltung von Zugriffsrechten, die Kompilierung, das Testen und die Bereitstellung fort. Zu den grundlegenden Maßnahmen gehören geschützte Branches in Code-Repositories (Protected Branches), Code Reviews, Zugriffsmanagement sowie automatisierte Sicherheitsscans wie SAST, DAST und Dependency Scanning.

Ein weiterer wichtiger Baustein ist Transparenz hinsichtlich der verwendeten Bibliotheken und Pakete, beispielsweise durch ein Software Bill of Materials (SBOM). Erst die Kombination dieser und vieler weiterer Maßnahmen stellt sicher, dass sich Sicherheit nicht nur auf das Endprodukt beschränkt, sondern den gesamten Prozess von der Entwicklung bis zur Bereitstellung und den späteren Updates umfasst.

Strategische Perspektive auf die Sicherheit des Lieferketten-Ökosystems

Die Sicherheit der Lieferkette geht längst über den Bereich der IT-Sicherheit hinaus und ist zu einem strategischen Geschäftsrisiko geworden. In der heutigen vernetzten IT-Welt reicht es nicht mehr aus, ausschließlich in den Schutz der eigenen Infrastruktur zu investieren. Entscheidend ist ein systematisches Risikomanagement über das gesamte Lieferanten-Ökosystem hinweg sowie die Bewertung der tatsächlichen Sicherheit – und nicht nur des deklarieren Sicherheitsniveaus – jener Partner, von denen interne Prozesse und der Geschäftsbetrieb abhängig sind.