Bei dem im Dezember 2020 bekannt gewordenen Vorfall bei SolarWinds drangen Angreifer in die Build-Umgebung einer IT-Verwaltungssoftware ein, und in legitime Update-Programme wurde schädlicher Code eingeschleust. Diese Updates wurden mit der legitimen Codesignatur des Herstellers verteilt. Welche Lehre lässt sich aus diesem Vorfall am ehesten ziehen?

Antwort: C. Eine Codesignatur zeigt nur, wer signiert hat und ob nach dem Signieren manipuliert wurde; daher muss der Hersteller seine Build-Umgebung schützen, und Nutzer überwachen auch das Verhalten vertrauenswürdiger Software

Eine Codesignatur bestätigt, wer signiert hat und dass der Inhalt nach dem Signieren nicht verändert wurde; schädlichen Code, der vor dem Signieren eingeschleust wurde, kann sie nicht erkennen. Beim Vorfall bei SolarWinds, einem typischen Beispiel für einen Software-Lieferkettenangriff, wurde der schädliche Code während des Builds hinzugefügt und erreichte daher als signiertes, legitimes Update viele Organisationen. Auch bei der im März 2024 entdeckten Hintertür in xz-utils hatte eine Person, die über lange Zeit als Entwickler Vertrauen gewonnen hatte, schädlichen Code in die Dateien für die Verteilung eingeschmuggelt. Wichtig ist, dass Hersteller ihre Build-Umgebung abgetrennt schützen und die Herkunftskette von den Quellen bis zum Build aufzeichnen und prüfen und dass Nutzer auch bei vertrauenswürdiger Software verdächtige Verbindungen und verdächtiges Verhalten etwa mit EDR überwachen.