Supply Chain Security: Drittanbieter-Risiken managen
Das Wichtigste in Kürze
- Der SolarWinds-Angriff 2020 hat gezeigt: die Software-Lieferkette ist ein bevorzugter Angriffsvektor — Angriffe über kompromittierte Open-Source-Pakete und Build-Pipelines nehmen weiter zu
- Ein ISO-27001-Zertifikat eines Dienstleisters sagt wenig darüber aus, wie sicher die konkrete Integration in Ihre Umgebung ist — die relevanten Fragen sind konkreter
- Software Bill of Materials (SBOM) schaffen Transparenz darüber, welche Komponenten in Ihrer Software enthalten sind und welche bekannten Schwachstellen bestehen
- Nicht alle Abhängigkeiten haben dasselbe Risikoprofil: Ein Identity Provider hat ein grundlegend anderes Risiko als ein Paket für Datumsformatierung — Risikoklassifizierung ist Pflicht
- Supply-Chain-Security ist keine einmalige Aufgabe: ein regelmäßiger Review-Zyklus, mindestens quartalsweise für kritische Abhängigkeiten, ist notwendig
Der SolarWinds-Angriff hat 2020 einer breiten Öffentlichkeit gezeigt, was Sicherheitsexperten längst wussten: Die Software-Lieferkette ist ein bevorzugter Angriffsvektor. Seitdem hat sich die Bedrohungslage nicht entspannt — im Gegenteil. Angriffe über kompromittierte Open-Source-Pakete, manipulierte Build-Pipelines und unsichere Drittanbieter-Integrationen nehmen zu.
Für Unternehmen, die Cloud-Dienste nutzen, SaaS-Anwendungen einsetzen und auf Open-Source-Bibliotheken aufbauen, ist die Frage nicht ob, sondern wie sie ihre Supply-Chain-Risiken managen.
Warum klassische Ansätze nicht ausreichen
Viele Unternehmen verlassen sich bei der Bewertung von Drittanbietern auf Fragebögen und Zertifizierungen. Ein ISO-27001-Zertifikat eines Dienstleisters ist ein positives Signal, aber es sagt wenig darüber aus, wie sicher die konkrete Integration in Ihre Umgebung ist.
Die relevanten Fragen sind konkreter: Welche Berechtigungen hat die Drittanbieter-Software in Ihrer Umgebung? Welche Daten fließen wohin? Was passiert, wenn der Anbieter kompromittiert wird? Wie schnell würden Sie es bemerken?
Ein strukturierter Ansatz
1. Inventar erstellen
Der erste Schritt ist trivial, wird aber häufig übersprungen: ein vollständiges Inventar aller Drittanbieter-Abhängigkeiten. Das umfasst nicht nur direkte Lieferanten, sondern auch Open-Source-Bibliotheken, SaaS-Integrationen, API-Verbindungen und Build-Tools.
Software Bill of Materials (SBOM) sind hier ein nützliches Werkzeug. Sie schaffen Transparenz darüber, welche Komponenten in Ihrer Software enthalten sind und welche bekannten Schwachstellen diese aufweisen.
2. Risikobewertung nach Kritikalität
Nicht jede Abhängigkeit stellt das gleiche Risiko dar. Ein Open-Source-Paket, das nur Datumsformatierung übernimmt, hat ein anderes Risikoprofil als ein Identity Provider, der Zugang zu allen Unternehmenssystemen kontrolliert.
Bewerten Sie jede Abhängigkeit nach: Zugriffsprivilegien, Datenzugang, Ersetzbarkeit und Auswirkung bei Kompromittierung. Konzentrieren Sie Ihre Maßnahmen auf die kritischsten Abhängigkeiten.
3. Technische Kontrollen implementieren
Für Software-Abhängigkeiten: Verwenden Sie Dependency-Scanning in Ihrer CI/CD-Pipeline, fixieren Sie Versionen statt automatisch Updates zu ziehen, und überprüfen Sie kritische Updates vor dem Deployment.
Für SaaS-Dienste: Beschränken Sie Berechtigungen auf das Minimum (Least Privilege), überwachen Sie API-Zugriffe, und definieren Sie Notfallprozesse für den Fall eines Anbieter-Ausfalls oder einer Kompromittierung.
4. Vertragliche Absicherung
Technische Kontrollen allein reichen nicht. Ihre Verträge mit Drittanbietern sollten Sicherheitsanforderungen definieren, Audit-Rechte einräumen, Meldepflichten bei Sicherheitsvorfällen festlegen und SLAs für Sicherheitsupdates enthalten.
Kontinuierliche Überwachung
Supply-Chain-Security ist keine einmalige Aufgabe. Neue Schwachstellen werden täglich entdeckt, Anbieter ändern ihre Praktiken, und Ihre eigene Abhängigkeitslandschaft entwickelt sich weiter. Ein regelmäßiger Review-Zyklus — mindestens quartalsweise für kritische Abhängigkeiten — ist notwendig.
Wenn Sie Ihre Supply-Chain-Risiken strukturiert bewerten und Ihre Schutzmaßnahmen verbessern möchten, sprechen Sie uns an.
Haeufig gestellte Fragen
Was ist ein Software Bill of Materials (SBOM) und brauche ich es wirklich?
Ein SBOM ist eine strukturierte Liste aller Komponenten, die in einer Software enthalten sind — ähnlich einem Zutatenverzeichnis auf einer Lebensmittelpackung. Es ermöglicht, bei einer neu entdeckten Schwachstelle (z. B. Log4Shell) sofort zu prüfen, welche eigenen Systeme betroffen sind. Für Unternehmen, die eigene Software entwickeln oder einsetzen, ist ein SBOM zunehmend Pflichtanforderung — auch regulatorisch (z. B. im Rahmen von DORA und NIS2).
Wie bewerte ich, welche Drittanbieter-Abhängigkeiten kritisch sind?
Vier Kriterien sind entscheidend: Zugriffsprivilegien der Software auf Ihre Systeme, Zugang zu sensiblen Daten, Ersetzbarkeit (wie schwer wäre ein Anbieterwechsel?) und Auswirkung bei Kompromittierung. Abhängigkeiten, die mehrere dieser Kriterien erfüllen, sollten intensiver überwacht und vertraglich stärker abgesichert werden.
Reichen vertragliche Sicherheitsanforderungen an Drittanbieter aus?
Vertragsklauseln sind notwendig, aber nicht ausreichend. Sie definieren den Rahmen und geben Ihnen Rechte (z. B. Audit-Recht), können aber einen tatsächlichen Angriff über einen kompromittierten Anbieter nicht verhindern. Technische Kontrollen — beschränkte Berechtigungen, überwachte API-Zugriffe, Dependency-Scanning — sind komplementär und unverzichtbar.
Was sollte ich tun, wenn einer meiner SaaS-Anbieter einen Sicherheitsvorfall meldet?
Erstens: den Schweregrad und den Umfang der Betroffenheit einschätzen — welche Daten und Zugänge sind betroffen? Zweitens: prüfen, welche Berechtigungen der Anbieter in Ihrer Umgebung hat, und ggf. temporär einschränken oder deaktivieren. Drittens: prüfen, ob Meldepflichten (DSGVO, NIS2) ausgelöst wurden. Ein vorab definierter Notfallprozess für Anbieterausfälle spart in diesem Moment erheblich Zeit.