Dein Blog zum Thema digitales Business

Auf der Website steht: „Sicherheit hat bei uns höchste Priorität.“ Im Lieferanten-Assessment steht die Gegenfrage: „Zeig mir das.“ Zwischen diesen beiden Sätzen liegt die eigentliche Arbeit, und genau da scheitern die meisten Anbieter, nicht weil sie unsicher sind, sondern weil sie nichts vorzeigen können, das ihre Aussagen deckt.

Was ein Assessment strukturell will

Ein Sicherheitsfragebogen, den ein Kunde ausfüllt, fragt nach Selbstauskunft. Ein Assessment, das ein Prüfer, ein Security-Team oder ein Zertifizierer durchführt, fragt nach Artefakten. Der Unterschied ist nicht graduell, er ist kategorial: Auf „Verschlüsseln Sie Daten im Transit?“ reicht in der Selbstauskunft ein Ja. Im Assessment folgt die Nachfrage, welches Werkzeug das protokolliert, wo dieses Protokoll liegt, und wer es sich zuletzt angesehen hat. Wer an dieser Stelle nur die Aussage wiederholt, hat die Frage nicht beantwortet.

Was in so einem Fragebogen typischerweise abgefragt wird, haben wir kürzlich getrennt behandelt: Was Kunden im Sicherheitsfragebogen wirklich wissen wollen.

SBOM und Komponenten-Transparenz

Die erste konkrete Forderung in praktisch jedem technischen Assessment ist eine Stückliste der Software: Welche Komponenten, welche Version, welche Lizenz, welche bekannten Schwachstellen. Standardformate dafür sind SPDX und CycloneDX, beide offen spezifiziert und maschinenlesbar. Ein Prüfer will nicht hören, dass „alle Abhängigkeiten aktuell gehalten werden“. Er will die Liste, das Erstellungsdatum, und im besten Fall den Prozess, der sie bei jedem Build automatisch neu erzeugt. Eine SBOM, die einmal jährlich von Hand zusammengetragen wird, beantwortet die Frage formal, aber nicht inhaltlich: Sie zeigt keinen Prozess, nur eine Momentaufnahme.

Wie eine solche Stückliste vom einmaligen Excel-Sheet zum bei jedem Build automatisiert erzeugten Dokument wird, haben wir in einem eigenen Beitrag beschrieben: Von der Excel-Liste zum SBOM.

Nachweisketten für Build und Deployment

Die zweite Ebene betrifft nicht das, was ausgeliefert wird, sondern wie es dorthin kam. Wer hat den Build ausgelöst, mit welchem Commit, über welche Pipeline, mit welcher Signatur am Ende. Das Konzept dahinter heißt Provenienz: eine lückenlose, überprüfbare Kette vom Quellcode bis zum Artefakt, die sich nicht auf Vertrauen stützt, sondern auf Protokolle. Frameworks wie SLSA beschreiben Reifegrade genau dafür, von „Build ist irgendwie automatisiert“ bis „jeder Schritt ist signiert und rückverfolgbar“. Ein Assessment fragt konkret danach, ob ein Artefakt im Betrieb sich eindeutig auf einen Commit zurückführen lässt, und ob diese Zuordnung manipulationssicher ist oder nur in einem Ticket steht, das jeder nachträglich ändern kann.

Secrets-Handling unter der Lupe

Beim dritten Themenblock wird es am schnellsten unangenehm, weil hier die Antwort meistens Improvisation offenlegt statt System. Gefragt wird: Wo liegen Zugangsdaten, wer hat Zugriff, wie werden sie rotiert, was passiert, wenn ein Mitarbeiter das Unternehmen verlässt. Ein Secret, das in einer Konfigurationsdatei im Repository liegt, beantwortet diese Fragen alle negativ, selbst wenn das Repository privat ist. Ein Prüfer fragt nicht nach der Existenz eines Tresors, er fragt nach dem Rotationsintervall, nach der Zugriffsprotokollierung und danach, ob ein abgelaufener Zugriff tatsächlich technisch entzogen wird oder nur organisatorisch als erledigt gilt.

Wie ein Rotationsprozess für Pipeline-Secrets konkret aussieht, haben wir separat durchgespielt: Pipeline-Secrets rotieren.

Was in der Praxis meistens fehlt

Nicht die Technik ist das häufigste Problem, sondern die Lücke zwischen einzelnen Maßnahmen und einer durchgehenden Kette. Ein Unternehmen hat eine SBOM, aber sie wird nicht bei jedem Release neu erzeugt. Es hat eine Pipeline mit Signaturen, aber niemand kann in fünf Minuten zeigen, welches Artefakt zu welchem Commit gehört. Es hat einen Secrets-Manager, aber die Rotation läuft nicht automatisch. Jede Maßnahme für sich existiert, aber die Verbindung zwischen ihnen fehlt, und genau diese Verbindung ist es, die ein Assessment sehen will. Eine Behauptung auf der Website kostet nichts. Eine durchgehende Nachweiskette kostet Arbeit, und genau deshalb ist sie der Unterschied, der im Assessment zählt.

Wie du das angehst

Der Aufbau einer durchgehenden Nachweiskette, von der SBOM über signierte Build-Provenienz bis zum kontrollierten Secrets-Handling, ist genau das Themenfeld für Lieferanten, die ein Assessment vor sich haben statt eines hinter sich. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Schreib mir an mm@mhm-dl.de.