Software-Lieferkettensicherheit für die Verteidigung: SLSA, Provenienz, Signierung

Ein im Feld eingesetztes Verteidigungs-Binärprogramm steht am Ende einer langen Vertrauenskette. Es begann als Quellcode, geschrieben von einem Entwickler, durchlief Dutzende Open-Source-Abhängigkeiten, wurde auf einem Build-Server kompiliert, paketiert, signiert und in eine Release-Registry befördert, bevor es jemals ein operatives Netzwerk erreichte. Jedes Glied dieser Kette ist ein Angriffsziel. Staatliche Gegner haben wiederholt gezeigt, dass der günstigste Weg in ein gehärtetes Verteidigungsnetzwerk nicht die Vordertür ist – es ist das Build-System oder eine vertrauenswürdige Abhängigkeit, vorgelagert kompromittiert, sodass der Schadcode signiert und abgesegnet durch die Pipeline des Opfers selbst ausgeliefert wird. Software-Lieferkettensicherheit ist die Disziplin, jedes Glied dieser Kette überprüfbar zu machen, sodass ein im Feld eingesetztes Artefakt kryptografisch über einen manipulationssicheren Build auf geprüften Quellcode zurückgeführt werden kann.

Das Bedrohungsmodell der Verteidigungs-Lieferkette

Kommerzielle Lieferkettensicherheit und Verteidigungs-Lieferkettensicherheit teilen dasselbe Vokabular, aber einen anderen Gegner. Ein kommerzielles Team sorgt sich um eine verwundbare Abhängigkeit oder ein versehentlich durchgesickertes Geheimnis. Ein Verteidigungsteam muss von einem gut ausgestatteten Akteur ausgehen, der Monate damit verbringt, ein Implantat vorzupositionieren: ein beliebtes Open-Source-Paket zu vergiften, einen Build-Runner zu kompromittieren oder einen manipulierten Compiler unterzuschieben. Der SolarWinds-Einbruch – bei dem ein Implantat im Build-System eine Hintertür in ein rechtmäßig signiertes Produktupdate einfügte – ist das kanonische Beispiel und veränderte, wie die Verteidigungsbeschaffung den Ursprung von Software behandelt.

Die Bedrohungsfläche gliedert sich in vier Zonen. Die Quellcode-Zone umfasst das Versionskontrollsystem und die Personen mit Commit-Zugriff. Die Abhängigkeiten-Zone umfasst jedes Drittanbieter-Paket, das in den Build einfließt, direkt und transitiv. Die Build-Zone umfasst den Build-Dienst, seine Runner und die Toolchain. Die Verteilungs-Zone umfasst Signierung, Release-Registry und Bereitstellung. Ein Kontrollrahmen für die Verteidigungs-Lieferkette muss alle vier adressieren – eine zu härten und eine andere offen zu lassen, verschiebt lediglich den Einstiegspunkt des Gegners.

Was dies für die Verteidigung schwieriger macht als für kommerzielle Software, ist das Konsequenzmodell. Ein kompromittiertes kommerzielles SaaS-Update lässt sich zurückrollen; ein kompromittierter Firmware-Stand auf einem im Feld eingesetzten Funkgerät oder einer Nutzlast für die elektronische Kampfführung kann unerreichbar, persistent und operativ katastrophal sein. Die Kosten eines einzigen manipulierten Artefakts sind asymmetrisch, weshalb der Rahmen präventiv statt reaktiv sein muss – das Ziel besteht darin, ein bösartiges Artefakt von vornherein an der Passage durch die Pipeline zu hindern, nicht es nach der Bereitstellung zu erkennen. Die folgenden Kontrollen sind von der Quelle bis zur Feldeinführung genau so abgefolgt, dass jede Zone geschlossen wird, bevor die nächste ihre Ausgaben erbt.

SLSA: ein Reifegradmodell für Build-Integrität

SLSA – Supply-chain Levels for Software Artifacts – ist der am weitesten verbreitete Rahmen, um über Build-Integrität nachzudenken. Er ist bewusst inkrementell und definiert aufsteigende Stufen, sodass eine Organisation messen kann, wo sie steht und was die nächste konkrete Verbesserung ist.

Stufe 1 verlangt lediglich, dass der Build-Prozess eine Provenienz erzeugt: eine Beschreibung, wie das Artefakt erstellt wurde. Dies allein deckt Fehler auf und liefert eine Grundlage für die Analyse, doch die Provenienz ist noch nicht gegen Manipulation geschützt.

Stufe 2 verlangt einen gehosteten Build-Dienst, der die Provenienz erzeugt und signiert. Da ein Dienst und nicht eine Entwickler-Arbeitsstation die Bescheinigung erstellt, wird eine Manipulation durch eine einzelne kompromittierte Maschine erkennbar.

Stufe 3 härtet die Build-Plattform selbst: Die Provenienz wird unfälschbar, und Builds laufen in isolierten, kurzlebigen Umgebungen, die zwischen den Durchläufen keinen Zustand übertragen. Dies ist die Stufe, auf der eine kompromittierte Abhängigkeit oder ein bösartiges Build-Skript nicht länger unbemerkt umschreiben kann, was die Provenienz meldet. Für Missionssoftware sollte SLSA-Stufe 3 als Mindeststandard und nicht als Bestrebung behandelt werden.

Die höchstgesicherte Haltung – historisch als Stufe 4 beschrieben und heute durch zusätzliche Track-Anforderungen ausgedrückt – ergänzt das Vier-Augen-Prinzip für jede Änderung sowie hermetische, reproduzierbare Builds. Ein reproduzierbarer Build erlaubt es einer unabhängigen Partei, denselben Quellcode neu zu bauen und Bit für Bit zu bestätigen, dass sie dasselbe Artefakt erhält. Für waffennahe oder kryptografische Komponenten ist Reproduzierbarkeit die stärkste verfügbare Verteidigung gegen eine manipulierte Toolchain.

Build-Provenienz: wie das Artefakt erstellt wurde

Provenienz ist das Herzstück der Lieferkettensicherung und wird häufig mit der Signierung verwechselt. Eine Signatur auf einem Binärprogramm beweist, wer es freigegeben hat und dass es sich seit dem Anbringen der Signatur nicht geändert hat. Sie sagt nichts darüber aus, ob der Build, der das Binärprogramm erzeugt hat, vertrauenswürdig war. Kompromittiert ein Gegner den Build-Runner, kann er ein bösartiges Artefakt erzeugen, das anschließend völlig rechtmäßig signiert wird – die Signatur ist gültig, das Artefakt ist vergiftet.

Die Provenienz schließt diese Lücke. Eine Provenienzbescheinigung ist ein signierter, maschinenlesbarer Datensatz, der den Quellcode-Commit, die Builder-Identität, die Build-Parameter und die kryptografischen Prüfsummen jeder Ein- und Ausgabe beschreibt. Das weit verbreitete Format ist die in-toto-Bescheinigung, die dies als strukturierte Aussage erfasst, die die Build-Plattform – nicht der Entwickler – signiert. Wenn ein Prüfer das Artefakt später kontrolliert, bestätigt er nicht nur die Signatur, sondern auch, dass die Provenienz das erwartete Quellcode-Repository, den erwarteten Builder und einen Commit benennt, der die Prüfung bestanden hat.

Was ein Prüfer kontrolliert

Eine Provenienzprüfung zum Bereitstellungszeitpunkt beantwortet eine präzise Frage: Wurde genau dieses Artefakt aus dem Quellcode und Prozess erstellt, den wir erwarten? Der Prüfer vergleicht die Prüfsumme des Artefakts mit der in der Provenienz aufgezeichneten Prüfsumme, bestätigt, dass die Provenienz mit dem Schlüssel der vertrauenswürdigen Build-Plattform signiert wurde, und stellt fest, dass die Builder-Identität und die Quellcode-URI mit einer Positivliste übereinstimmen. Eine Abweichung – ein Artefakt, dessen Provenienz einen unbekannten Builder benennt oder dessen Prüfsumme nicht übereinstimmt – wird abgelehnt, bevor es eine operative Umgebung erreicht. Dies ist die Kontrolle, die eine Substitution im Stil von SolarWinds aufgedeckt hätte.

Provenienz ermöglicht außerdem eine Reaktion auf Vorfälle, die andernfalls unmöglich wäre. Wird eine neue Schwachstelle in einem Build-Werkzeug oder einer Abhängigkeit offengelegt, kann eine Organisation mit vollständiger Provenienz genau abfragen, welche im Feld eingesetzten Artefakte mit der betroffenen Komponente, von welchem Builder und aus welchem Commit erzeugt wurden – und verwandelt damit eine hektische Schätzung in eine präzise Antwort über den Wirkungsradius. Provenienz, die über die gesamte operative Lebensdauer eines Artefakts aufbewahrt wird, ist daher nicht nur ein Gate vor der Bereitstellung, sondern auch ein Audit-Bestand, der sich noch Jahre nach dem Build auszahlt.

Artefaktsignierung in Verteidigungs-Pipelines

Die Signierung bleibt unverzichtbar; sie ist nur für sich genommen nicht ausreichend. Die moderne Praxis ist die schlüssellose Signierung, gestützt durch ein Transparenzprotokoll: Ein kurzlebiger Schlüssel wird gegen eine verifizierte Workload-Identität ausgegeben, zum Signieren des Artefakts und seiner Bescheinigungen verwendet, und das Signiervorgang wird in einem anhängungssicheren öffentlichen oder privaten Transparenzprotokoll aufgezeichnet. Dies beseitigt den betrieblichen Aufwand und das Risiko langlebiger Signierschlüssel, die auf Build-Servern liegen.

Für die höchstgesicherten Komponenten – kryptografische Module, Bootloader, alles, was an einen Hardware-Vertrauensanker gebunden ist – verwenden Verteidigungsprogramme hardwaregestützte Schlüssel, die in einem Hardware-Sicherheitsmodul (HSM) gehalten werden. Der private Schlüssel verlässt das HSM nie; Signiervorgänge werden darin ausgeführt. Dies passt natürlich zu Secure Boot, bei dem die Geräte-Firmware die Signatur jeder Stufe verifiziert, bevor sie sie ausführt, und so die Vertrauenskette der Lieferkette bis hinunter zum Silizium ausdehnt.

Abhängigkeitsprüfung und die SBOM

Der Großteil des Codes in jeder modernen Verteidigungsanwendung wird nicht vom Programm geschrieben – er wird als Open-Source-Abhängigkeiten eingebracht. Die Überprüfung dieser Abhängigkeiten ist daher die wirkungsvollste Kontrolle in der gesamten Kette. Mehrere Praktiken verstärken sich hier gegenseitig.

Festlegen und Hashing. Jede Abhängigkeit wird auf eine bestimmte Version und einen kryptografischen Hash festgelegt, sodass der aufgelöste Abhängigkeitsbaum deterministisch ist. Ein Build kann nicht unbemerkt auf eine neue, bösartige Version eines Pakets abdriften, da der Hash dann nicht mehr übereinstimmen würde.

Internes Spiegeln. Freigegebene Pakete werden in eine interne Registry gespiegelt, und Builds beziehen nur aus diesem Spiegel – niemals direkt aus einer öffentlichen Registry zur Build-Zeit. Dies verschafft dem Programm einen kontrollierten Prüfpunkt und durchbricht die Abhängigkeit des Builds von der Internet-Erreichbarkeit, was für air-gapped und klassifizierte Umgebungen zwingend ist.

Schwachstellen-Scan. Jede Abhängigkeit wird gegen Schwachstellendaten wie die OSV advisory database gescannt, und die Ergebnisse steuern die Beförderung. Das Resultat der Aufzählung jeder transitiven Komponente ist eine Software-Stückliste. Zu den beschaffungsgetriebenen Anforderungen, die nun an dieses Artefakt geknüpft sind, siehe unsere Analyse zur Software-Stückliste (SBOM) für die Verteidigung. Die SBOM wird in einem Standardformat – CycloneDX oder SPDX – erzeugt und als signierte Bescheinigung an das Artefakt angehängt, sodass sie mit dem Binärprogramm mitreist.

Richtliniendurchsetzung: das Zulassungs-Gate

Keine dieser Kontrollen zählt, sofern sie nicht ein nicht-konformes Artefakt daran hindert, ins Feld gebracht zu werden. Der Durchsetzungspunkt ist das Zulassungs-Gate – der Moment unmittelbar bevor ein Artefakt in eine Release-Registry befördert oder in eine operative Umgebung bereitgestellt wird. An diesem Gate führt eine Richtlinien-Engine eine Reihe verpflichtender Prüfungen durch: Sie verifiziert die Signatur des Artefakts, validiert die Provenienz gegen die erwarteten Quellcode- und Builder-Identitäten, prüft die SBOM gegen Schwachstellendaten und eine Liste verbotener Komponenten und bestätigt, dass die Änderung die erforderliche Prüfung nach dem Vier-Augen-Prinzip bestanden hat.

Die entscheidende Gestaltungsregel lautet, dass die Richtlinie blockieren und nicht bloß markieren muss. Ein häufiges Versagen besteht darin, früher in der Pipeline Scanner laufen zu lassen, die Warnungen ausgeben, während der Beförderungsschritt kein hartes Gate hat – sodass ein markiertes Artefakt dennoch ausgeliefert wird, wenn ein Ingenieur unter Termindruck darüber hinweggeht. Das Zulassungs-Gate muss im Fehlerfall schließen: Lässt sich die Provenienz nicht verifizieren, wird das Artefakt nicht bereitgestellt. Diese Gates als Code einzubetten, geprüft und versionskontrolliert wie jede andere Pipeline-Phase, ist die natürliche Erweiterung einer DevSecOps-Praxis für die Verteidigung, bei der Sicherheitskontrollen Teil jedes Sprints sind statt eines Audits vor der Freigabe.

Den Betrieb der Kette in klassifizierten Umgebungen

In einer air-gapped oder klassifizierten Enklave muss die gesamte Kette ohne Internetzugang laufen. Interne Spiegel halten geprüfte Abhängigkeiten bereit, der Build-Dienst und das Transparenzprotokoll laufen innerhalb der Enklave, und Verifizierungsschlüssel werden über genehmigte Kanäle verteilt. Aktualisierungen des Abhängigkeitsspiegels treffen über kontrollierte domänenübergreifende Transfers ein, jede mit eigener Provenienz, sodass die Enklave den Ursprung erneut verifizieren kann, bevor sie ein Paket zulässt. Die Lieferkette von der ersten Sprint-Iteration an für den Offline-Betrieb zu entwerfen – statt sie nachzurüsten – macht den Unterschied zwischen einem Kontrollrahmen, der die Akkreditierung übersteht, und einem, der beim Kontakt mit einer echten klassifizierten Bereitstellung zusammenbricht.