Als Softwareunternehmen erhalten Sie selbst immer häufiger einen Sicherheitsfragebogen von einem Kunden, der unter das Cybersecurity-Gesetz fällt. Dieselbe Sorgfaltspflicht, die Ihren Kunden gegenüber gilt, verpflichtet auch Sie selbst zu etwas: zu bewerten, welche Ihrer eigenen Lieferanten Auswirkungen auf die Sicherheit dessen haben, was Sie bauen und liefern. Eine Lieferantenpolitik ist die Möglichkeit, diese Bewertung wiederholbar zu machen, anstatt jedes Mal neu zu überlegen, wem Sie eigentlich vertrauen.
Kurze Antwort: Sie beginnen mit einer Übersicht darüber, wer sich in Ihrer Entwicklungspipeline und in Ihrer gelieferten Software befindet, Sie teilen diese Lieferanten nach dem Risiko ein, das sie darstellen, und Sie legen pro Kategorie fest, welche Anforderungen Sie stellen und wie Sie diese überprüfen. Diese Übersicht und diese Einteilung bilden zusammen die Lieferantenpolitik.
Zwei Arten von Lieferanten, ein blinder Fleck
Bei der Softwareentwicklung verlaufen zwei Ketten ineinander, und das macht eine Lieferantenpolitik komplizierter als bei einem Unternehmen, das nur physische Waren einkauft.
Die erste Kette ist Ihre Entwicklungspipeline: die Quellcodeverwaltung, die CI/CD-Pipeline, die Cloud-Umgebung, in der Sie arbeiten, die Tools zum Testen und Bereitstellen. Eine Schwachstelle dort betrifft in erster Linie Ihren eigenen Betrieb.
Die zweite Kette ist das, was in Ihr Produkt fließt: Open-Source-Bibliotheken, APIs von Dritten, eingekaufte Komponenten. Eine Schwachstelle dort betrifft nicht nur Sie, sondern auch jeden Kunden, der Ihre Software nutzt. Genau diesen Unterschied berücksichtigt viele Lieferantenpolitiken nicht ausreichend: Die Aufmerksamkeit geht an die erste Kette, weil sie in der täglichen Arbeit sichtbar ist, während die zweite Kette oft erst sichtbar wird, wenn etwas schiefgeht.
Inventarisieren: Beginnen Sie mit dem, was bereits läuft
Eine Lieferantenpolitik beginnt nicht mit einer Vorlage, sondern mit einer Liste. Für die Softwareentwicklung bedeutet das mindestens: welche Cloud-Anbieter Sie nutzen, welche Paketmanager und Registries Ihr Build-Prozess abruft, welche externen APIs Ihr Produkt aufruft, und welche dieser Parteien auf Code, Geheimnisse oder Produktionsdaten zugreifen können.
Für jeden Lieferanten ist die Frage nicht nur, was er tut, sondern was passiert, wenn er ausfällt oder kompromittiert wird. Ein Paketmanager, aus dem hunderte Abhängigkeiten stammen, wird anders bewertet als ein Rechnungspaket, das unabhängig von der Entwicklungspipeline läuft.
Risikoeinteilung: Nicht jeder Lieferant verdient die gleiche Aufmerksamkeit
Nach der Inventarisierung folgt eine Einteilung, normalerweise in zwei oder drei Ebenen. Lieferanten mit Zugriff auf Quellcode, Geheimnisse oder Produktionsumgebungen erfordern die strengsten Anforderungen: starke Authentifizierung, Protokollierung, einen festen Ansprechpartner bei Sicherheitsvorfällen. Lieferanten, die nur indirekt mitarbeiten, wie ein Tool für Projektplanung, erfordern weniger.
Die Richtlinie und das nationale Gesetz schreiben keine feste Einteilung vor; Aufsichtsbehörden prüfen dabei, ob die Maßnahmen in Relation zum Risiko stehen. Das bedeutet, dass die Einteilung, die Sie wählen, erklärbar sein muss: warum dieser Lieferant in die schwere Kategorie fällt und jener nicht.
Was Sie fragen und was Sie selbst bereits beantworten
Eine Lieferantenpolitik funktioniert in zwei Richtungen. Nach außen hin nutzen Sie sie, um Fragen an Ihre eigenen Lieferanten zu stellen: Wie gehen sie mit Schwachstellen um, haben sie einen Prozess für mehrstufige Authentifizierung, wie schnell melden sie einen Sicherheitsvorfall an Sie. Nach innen hin bildet sie die Grundlage dafür, was Sie selbst auf Fragebögen Ihrer Kunden antworten, denn ein Kunde, der Sie bewertet, möchte oft wissen, ob Sie Ihre eigene Lieferkette erfasst haben.
Die beiden Seiten hängen zusammen: Eine Lieferantenbewertungspolitik, die Sie nur für sich selbst verfassen, entspricht meist nicht den Fragen, die Sie von Kunden erhalten. Wer die Politik von Anfang an mit Blick auf das ausarbeitet, was ein Abnehmer fragt, muss sie später nicht umschreiben.
Dokumentieren: von der Politik zum Nachweis
Eine Politik, die nur in einem Textdokument steht, ist schwierig zu untermauern, wenn ein Kunde oder eine Behörde danach fragt. Praktischer ist eine aktuelle Übersicht: pro Lieferant die Risikokategorie, die letzte Bewertung, den Nachweis wie eine Erklärung, ein Zertifikat oder eine Antwort auf Ihre eigene Frageliste, und wer in Ihrer Organisation diesen Lieferanten überwacht.
Eine solche Übersicht muss nicht groß sein, um nützlich zu sein. Für ein Softwareunternehmen mit einer Handvoll kritischer Lieferanten ist eine Tabelle mit ein paar Spalten oft ausreichend, sofern diese aktuell gehalten wird, wenn ein Lieferant wechselt oder ein Vertrag erneuert wird.
Möchten Sie zunächst wissen, ob Ihre Organisation selbst unter die Sorgfaltspflicht fällt, oder werden Sie nur über Ihre Kunden betroffen? führen Sie die kostenlose Überprüfung in ein paar Fragen durch und lesen Sie auf der Seite mit allen Themen wie die Lieferantenbewertung mit den anderen Anforderungen zusammenhängt. Neugierig, woher die Informationen auf dieser Plattform stammen und wie aktuell sie sind? Das wird erläutert auf der Seite über die Funktionsweise. Wer die Übersicht der Lieferanten in ein Dossier mit Nachweisen und Verantwortlichen umwandeln möchte, findet auf der Seite mit Abonnements was dafür erforderlich ist.