Sichere Lieferketten mit Univention Nubus: Überblick über SBOM, VEX und Signaturen

Angriffe auf Open Source Projekte sind inzwischen zur Normalität geworden und gefährden damit auch die Lieferkette von Univention Produkten. Um die notwendige Absicherung und Transparenz zu gewährleisten, setzen wir in Univention Nubus auf Signaturen, SBOMs und VEX. Den dahinterliegenden Nutzen möchte ich im Folgenden erläutern.

Die „Lieferkette” einer Software umfasst alle Beteiligten – vom Schreiben des Quellcodes bis hin zur Inbetriebnahme im Rechenzentrum. In den meisten Umgebungen besteht sie aus einer Mischung aus Inhouse-Entwicklung und extern bezogener Software.

Die externe Software kann sowohl frei verfügbar aus dem Internet stammen als auch von kommerziellen Anbietern. Für Fragen der Verantwortlichkeit und Lizenzbedingungen ist diese Unterscheidung relevant – für die grundsätzliche Absicherung der Lieferkette jedoch weniger entscheidend.

Nahezu alle Risiken in der Software-Lieferkette lassen sich zwei Bereichen zuordnen:

1. Schwachstellenmanagement
   Sowohl vor der Inbetriebnahme als auch im laufenden Betrieb benötigen Betreiber einen aktuellen Überblick über bekannte oder neu entdeckte Schwachstellen. Daraus lassen sich Maßnahmen wie Updates oder Konfigurationsanpassungen ableiten. Da kontinuierlich neue Schwachstellen veröffentlicht werden, sollte dieser Prozess automatisiert und regelmäßig erfolgen.
2. Eingeschleuster Schadcode
   Ein zunehmend verbreiteter Angriffsvektor ist das Einschleusen von Schadcode – entweder über kompromittierte Download-Server oder direkt im Source Code. Angreifer verschaffen sich dazu Zugriff auf Code Repository, Download Server oder Infrastruktur und manipulieren die zum Download bereitgestellte Software. Betreiber müssen daher sicherstellen, dass unzulässige Veränderungen erkannt werden, bevor Software produktiv eingesetzt wird.

Um der hohen Dynamik beim Schwachstellenmanagement Schritt zu halten, sind automatisierte Prozesse unerlässlich. Dabei hat sich folgende Prozesskette etabliert:

1. Update-Möglichkeiten identifizieren
   Automatisierte Mechanismen erkennen verfügbare Updates für Softwareprodukte und deren Abhängigkeiten. Betreiber definieren Regeln, welche Updates automatisiert eingespielt werden und wann ein manueller Eingriff erforderlich ist.
2. Quellen verifizieren
   Es wird festgelegt, welche Quellen als vertrauenswürdig gelten. Die Prüfung erfolgt sowohl auf Ebene der zulässigen Quell-Server als auch der Herausgeber einzelner Software-Pakete. Software aus nicht vertrauenswürdigen Quellen wird nicht verwendet.
3. Schwachstellen identifizieren
   Schwachstellen werden nach dem Release von Software gemeldet und können daher sowohl bereits ausgerollte als auch neu in Betrieb zu nehmende Software betreffen. Betreiber führen deshalb regelmäßige Analyse aller in Betrieb befindlicher Software durch, um Risiken zu erkennen und Maßnahmen einzuleiten. Diese Analysen werden auch auf neu einzuführende Software angewendet.
4. Maßnahmen auswählen
   Im einfachsten Fall können die Schwachstellen bereits durch einzuspielende Updates (Schritt 1) adressiert werden. Da dies jedoch nicht immer der Fall ist, setzen Betreiber im Risikomanagement häufig Dashboards ein, anhand derer Verantwortliche den Handlungsbedarf erkennen können. Alternativen zu Updates können beispielsweise Konfigurationsänderungen, die zeitweise Deaktivierung von Funktionen oder das gezielte Erkennen von Angriffen über diese Schwachstellen sein.

Im Folgenden möchte ich die wichtigsten technischen Maßnahmen beschreiben, die für diesen Prozess notwendig sind.

Als Standardmechanismus zur Prüfung der Vertrauenswürdigkeit haben sich Signaturen etabliert – unabhängig davon, ob Software in UCS als „.deb“-Paket, als Container oder unter Windows installiert wird. Auch wenn sich die Umsetzungen im Detail zwischen verschiedenen Paketformaten und Repository-Servern unterscheidet, basiert sie immer auf einem Schlüsselpaar: einem privaten Schlüssel, der sich in Besitz des Software-Erstellers befindet, und einem öffentlichen Schlüssel, den Betreiber zur Prüfung nutzen können, beispielsweise auf Basis der GPG Implementierung.

Bei der Bereitstellung der Software verwendet der Software-Ersteller – beispielsweise Univention – den privaten Schlüssel, um entweder die Softwarepakete selbst oder, wie bei Debian-Repositories, die Prüfsummen zu signieren. Diese Signaturen sind Bestandteil der Softwarebereitstellung. Beim Betrieb von Nubus mit Univention Corporate Server werden die von „apt“ implementierten Mechanismen genutzt, während bei Nubus für Kubernetes Container und Helm-Charts signiert werden (siehe unten). Da beide Verfahren weit verbreitet sind, ist eine automatisierte Prüfung mit Standardmitteln möglich.

Zu einer vollständigen Prüfung gehören neben den Signaturen auch die Prüfsummen. Diese werden vom Ersteller des Paketes mithilfe standardisierte Hash-Algorithmen erzeugt. Der Betreiber wendet denselben Algorithmus an und erhält im Normalfall das gleiche Ergebnis, also dieselbe Prüfsumme. Gelingt es einem Angreifer, das Paket auf dem Download-Server zu verändern, weicht die Prüfsumme ab, und der Angriff wird erkannt. Dank der Signatur der Prüfsummen würden auch Manipulationen an diesen erkannt werden.

Den Überblick darüber zu behalten, welche Software und insbesondere welche Bibliotheken aktuell ausgerollt sind, ist je nach Umgebung unterschiedlich aufwändig. Für die Bewertung möglicher Schwachstellen ist eine solche „Software-Inventur“ jedoch unerlässlich.

Wird Nubus auf Univention Corporate Server (UCS) ausgerollt, lassen sich die wichtigsten Bestandteile dank des von Debian übernommenen Paketmanagements noch relativ einfach mit Tools wie „dpkg“ und „apt“ ermitteln. Bei Container-Images, die über Docker auf UCS oder bei Nubus für Kubernetes eingesetzt werden, ist dies deutlich weniger offensichtlich. Da es unterschiedliche Methoden gibt, Software in Container zu integrieren, sind verschiedene Analyse-Tools erforderlich, um alle Inhalte zu erfassen.

Nubus für Kubernetes stellt daher die Inhalte der Container Images in einem standardisierten Format als sogenannte „Software Bill of Materials“ (SBOM) bereit. Dadurch kann für jedes Container-Image einfach und automatisiert ermittelt werden, welche Software in welcher Version enthalten ist – einschließlich der verwendeten Bibliotheken.

Zusätzlich zu den für das Schwachstellenmanagement benötigten Informationen enthalten sowohl die Debian-Pakete von UCS als auch die SBOMs der Container-Images Lizenzinformationen, die für das Compliance-Management genutzt werden können.

Dank SBOMs erhalten Betreiber einen detaillierten Einblick in die Software und Bibliotheken, die aus vertrauenswürdigen Quellen bezogen wurden. Auf dieser Grundlage ist ein automatisierter Abgleich mit Schwachstellen-Datenbanken möglich, die typischerweise auf „Common Vulnerabilities and Exposures“ (CVE) IDs basieren.

Automatisierte Schwachstellenscanner vergleichen in der Regel die Versionsstände der eingesetzten Software mit den Versionen, die von Schwachstellen betroffen sind. Ist die eingesetzte Version betroffen, melden sie eine potenzielle Schwachstelle.

Solche Meldungen sind häufig berechtigt und müssen immer geprüft werden. Allerdings handelt es sich nicht selten um sogenannte „False Positives“, also Fehlalarme. Die häufigsten Ursachen dafür sind:

1. Keine Versionsänderung bei zurückportierten Fixes
   Um die Kompatibilität zu erhalten, werden insbesondere in Long-Term-Support-Umgebungen Sicherheitsfixes gezielt auf ältere Versionen zurückportiert („Backport“). Da sich die Versionsnummer dabei nicht bzw. nur geringfügig ändert, melden Scanner eine Schwachstelle, obwohl diese bereits behoben ist. Das ist insbesondere bei Debian-Paketen verbreitet.
2. Keine Ausnutzbarkeit der Schwachstelle
   In vielen Konfigurationen wird nicht der gesamte Funktionsumfang einer Software oder Bibliothek genutzt. Tritt eine Schwachstelle nur in einer Funktion auf, die in der konkreten Umgebung gar nicht verwendet wird, ist sie faktisch nicht ausnutzbar. Da Schwachstellenscannern dieses Kontextwissen fehlt, melden sie dennoch ein Risiko. Wenn ein Update jedoch mit Komplikationen oder Inkompatibilitäten verbunden ist, kann es sinnvoller sein, eine nicht ausnutzbare Schwachstelle zu akzeptieren.

Als Software-Hersteller bewertet Univention solche Fälle systematisch und entscheidet, ob eine Lücke ausnutzbar ist und ob ein Fix als Update oder Backport bereitgestellt wird – dieser Prozess wird als „Triagieren“ bezeichnet. Um diese Information auch Betreibern zur Verfügung zu stellen, wurde das Format „Vulnerability Exploitability eXchange“ (VEX) entwickelt. Es ergänzt SBOMs um Informationen zu Schwachstellen, die nicht durch ein einfaches Versionsupdate behoben werden konnten. Univention stellt VEX-Informationen für alle Container-Images von Nubus für Kubernetes bereit.

Wie bei Softwarepaketen und Container-Images ist es auch bei VEX und SBOMs wichtig, die Signaturen zu prüfen. Manipulationen durch Angreifer könnten sonst dazu führen, dass Schwachstellen verborgen werden. Durch Signaturprüfung lassen sich solche Änderungen zuverlässig erkennen.

Mit Nubus für Kubernetes deckt Univention alle Aspekte der Lieferkettenabsicherung ab. Alle Bestandteile („Artefakte“) eines Releases – also Container-Images, Helm- Charts, SBOMs und VEX – werden signiert. Die Umsetzung basiert auf dem verbreiteten „Sigstore“-Projekt, das in vielen Kubernetes-Umgebungen bereits eingebunden ist. Details zur Implementierung sowie Beispiele zur Prüfung der Authentizität der Artefakte finden sich im Kapitel „Supply Chain Security“ des Nubus for Kubernetes Operation Manual.

Das Bundesamt für Sicherheit in der Informationstechnologie (BSI) berücksichtigt die Lieferkettenabsicherung sowohl im BSI-Grundschutzkatalog als auch in verschiedenen technischen Richtlinien. Alle Implementierungen von Nubus für Kubernetes sind darauf ausgerichtet, diese Vorgaben praxisnah umzusetzen.

Gute Einstiegspunkte in die umfassenden Informationen des BSI sind:

1. Die Technische Richtlinie BSI TR-03183 zu Anforderungen an Hersteller und Produkte, basierend auf der im „Cyber Resilience Act“ (CRA) enthaltenen Lieferkettenabsicherung. Die Richtlinie besteht aus drei Teildokumenten, von denen sich Teil 2 u.a. mit SBOMs und Teil 3 mit VEX befasst.
2. Die Anforderungen an Software-Hersteller wie Univention im BSI Grundschutzkatalog, beschrieben in CON.8 „Software-Entwicklung“. Dazu gehören z.B. CON.8.A6 (Verpflichtung zur Nutzung vertaruenswürdiger Softwarekomponenten) und CON.8.A8 (Bereitstellung von Prüfsummen und Signaturen).
3. Die Anforderungen an Betreiber von Software, beschrieben in den „OPS“-Modulen, z.B. OPS.1.1.3.A10 (Prüfung von Signaturen vor der Nutzung von Softwarepaketen) und OPS.1.1.3.A15 (Umgang mit Aktualisierungen zum Schutz vor neu bekannt gewordenen Schwachstellen).

SBOMs enthalten nicht nur die Versionsnummern der verwendeten Software, sondern auch die jeweiligen Lizenzinformationen. Dabei kann es sich sowohl um Open-Source-Lizenzen als auch um proprietäre Lizenzen handeln. Betreiber haben damit die Möglichkeit, Compliance-Prüfungen durchzuführen, um festzustellen, ob die Lizenzbedingungen für die eigene Organisation akzeptabel sind und eingehalten werden können. Dank des standardisierten Formats von SBOMs lassen sich diese Prüfungen automatisieren.

Ein typisches Vorgehen ist die Definition zulässiger Lizenzen innerhalb der Organisation, gegen die der Inhalt der SBOMs geprüft wird. Wird neue Software hinzugefügt oder ändert eine bereits genutzte Software ihre Lizenz, erkennt eine automatische Prüfung, wenn die neue Lizenz nicht den Vorgaben entspricht. Die Organisation bleibt dadurch handlungsfähig, bevor die Software ausgerollt wird und die Lizenzbedingungen gegebenenfalls bereits greifen.

Frei verfügbare Open-Source-Projekte weisen leider einen sehr unterschiedlichen Reifegrad bei der Absicherung der Lieferkette auf. Inzwischen ist die Bereitstellung von Signaturen und Prüfsummen üblich, da diese von den meisten Build-Prozessen automatisch erzeugt werden. SBOMs oder gar VEX-Informationen sind hingegen selten und bei einzelnen Software-Bibliothek oft auch nicht sinnvoll.

Open-Source-Software-Hersteller wie Univention befinden sich bei der Lieferkettenabsicherung in einer Doppelrolle: Einerseits sichern sie die Lieferkette der ihren Produkten verwendeten Software ab, andererseits sind sie selbst Teil einer solchen Lieferkette gegenüber ihren Kunden. Als Hersteller schließen sie daher eine Lücke, indem sie aus den Basisinformationen der Open-Source-Projekte beispielsweise vollständige SBOMs generieren.

Univention nimmt diese Verantwortung ernst und stellt sicher, dass Software, die Teil der ausgelieferten Produkte wird, aus vertrauenswürdigen Quellen stammt, mit Sicherheitsupdates versorgt werden kann und unter OSI-konformen Open-Source-Lizenzen bereitgestellt wird. Dazu kommen intern die in diesem Artikel beschriebenen Techniken und Automatisierungen zum Einsatz.

Als Kunde von Univention erhalten Sie im Rahmen der Subskriptionsvereinbarung die Gewährleistung, dass diese Absicherungsmaßnahmen bereits umgesetzt wurden.