Jan Wildeboer: „Sicherheit und Standardisierung zusammen umsetzen“ Eine Vertrauenskette für Software von Red Hat

Von M.A. Jürgen Höfling 4 min Lesedauer

Anbieter zum Thema

Immer mehr Unternehmen weltweit nutzen in der einen oder anderen Form Open-Source-Software. Nur in den sicherheitstechnisch besonders sensiblen Branchen klemmt es noch. Mit seiner „Trusted Software Supply Chain“ will Red Hat dies nun ändern.

Architektur der "Trusted Software Supply Chain" von Red Hat
Architektur der "Trusted Software Supply Chain" von Red Hat
(Bild: von Red Hat)

Je deutlicher Open-Source-Software in vielen Bereichen von Wirtschaft und Gesellschaft zum Mainstream wird, desto mehr werden die konkreten Softwarepakete auch attraktiv für Kriminelle. Das erfordert engagierte Gegenmaßnahmen.

Denn wie es Jan Wildeboer, Software-Frontmann („Evangelist“) bei Red Hat EMEA bei einem Presse-Briefing formuliert: „Wir bei Red Hat wissen zwar, dass wir sichere Software anbieten, aber für besonders sensible Branchen wie die Finanzwirtschaft oder die Flugzeug- oder Autobauer muss eben bei jeder Codezeile klar sein, wann sie von wem geschrieben worden ist.“

Sensible Branchen durch Open-Source erschließen

Dass die „Leute mit dem roten Hut“ diese sensiblen Branchen zusätzlich zu dem mittlerweile Erreichten auch noch „erobern“ wollen, zeigt sich nicht zuletzt an der „Trusted Software Supply Chain“, einem Software- und Service-Konzept, das gerade auf dem Red Hat Summit 2023 in Boston vorgestellt wurde und jetzt sukzessive ausgerollt wird. Bis Ende des Jahres sollen alle Komponenten für die Kunden verfügbar sein.

Bei dem Produktangebot handelt es sich um einen „Cloud-Service, der die einzelnen Teile der Red Hat-Infrastruktur-Software in jeder Phase des Software-Entwicklungs-Zyklus mit einer Sicherheitsschiene versieht“ so der Originalton Red Hat.

Sowohl einzelne Code-Segmente als auch Applikationen auf der Cloud-Ebene wie Container-Mechanismen sind digital zertifiziert und können nur mit entsprechenden Zugangscodes benutzt werden. Diese Zugangsmechanismen sind im physischen Umfeld ebenso wie im virtuellen und im hybriden Umfeld notwendig und sie sind in vielen der heute gängigen Cloud-Umgebungen (AWS, Google, MS Azure oder IBM Cloud) verwendbar.

Trusted Content und Trusted Application Pipeline

Zu den einzelnen Komponenten: In wenigen Wochen als produktiv einsetzbare Betaversion verfügbar ist „Trusted Content“. Die Grundlage dieser Komponente bildet sicherheitsoptimierte Systemsoftware mit Tausenden von vertrauenswürdigen Paketen, die allein schon in „Red Hat Enterprise Linux“ (RHEL)zu finden ist sowie in den Ökosystemen Java, Node und Python.

Eine weitere Komponente, nämlich die „Trusted Application Pipeline“, ist schon jetzt als produktiv einsetzbare Betaversion erhältlich und hat ihre Basis in der Vorarbeit von Red Hat bei der Entwicklung, Einführung und Wartung von „Sigstore“, einem frei verfügbaren Standard für sicheres Signieren in der Cloud, sowie in den schon bisher bereitgestellten Teilen der gemeinsamen Sicherheitsinfrastruktur für viele Upstream-Communitys.

Die Trusted Application Pipeline bietet einen sicherheitsorientierten Continuous-Integration/Continuous-Delivery-Service (CI/CD), der die Übernahme der Prozesse, Technologien und Fachkenntnisse vereinfachen soll, die Red Hat für die Erstellung von Produktionssoftware einsetzt. Anwendungen können effizienter erstellt und einfacher in Linux-Container integriert und dann mit nur wenigen Klicks auf „Red Hat Openshift“ oder anderen Kubernetes-Plattformen bereitgestellt werden. Zuvor war dies häufig ein weitgehend manueller Prozess, bei dem Hunderte von Zeilen Automatisierungscode für die Erstellung, das Testen und die Bereitstellung von containerisierten Anwendungen erforderlich waren.

Derartige 'Handarbeit' birgt das Potenzial für Reibungsverluste und menschliche Fehler, was neue Risikopunkte mit sich bringt und die Gesamtgeschwindigkeit verlangsamt. Mit der Komponente „Trusted Application Pipeline“ können Red Hat-Kunden Git-Repositorys importieren und container-native kontinuierliche Build-, Test- und Deployment-Pipelines über einen Cloud-Service in nur wenigen Schritten konfigurieren.

Des Weiteren lassen sich Quellcode und transitive Abhängigkeiten untersuchen sowie eine Software-Stückliste (Software Bills of Materials alias SBOM) innerhalb von Build-Prozessen automatisch erzeugen. Und nicht zuletzt können Container-Images über eine Policy-Engine für Freigabekriterien, die die Konsistenz mit Branchen-Frameworks wie Supply Chain Levels for Software Artifacts (SLSA) bestätigt, überprüft werden. Alles in allem verbessern die Software und die Services, die im Rahmen der Trusted Software Supply Chain bereitgestellt werden, die Immunität eines Unternehmens gegenüber Schwachstellen im gesamten Lebenszyklus der modernen Software-Entwicklung.

„Linux eignet sich als Fahrzeug-Betriebssystem“

Das Sicherheitsangebot durch die beschriebene Software-Vertrauenskette ist imposant.Gleichwohl ist es klar, dass die „freiheitlich-demokratische Philosophie“ von quelloffener Software und die „penible buchhalterische Verwaltung von Codesegmenten, Applikationen und Cloud-Strukturen“ – wenn man das einmal so zugespitzt formulieren darf – nicht unbedingt und von vornherein seelenverwandt sind.

„Wie man die Security Chain zum Beispiel in Github abbildet oder auch wie man die Vertrauenskette überhaupt in den CI /CD-Prozess abbildet, das erforderte viel Überlegung“, überlegt denn auch Wildeboer auf dem Presse-Briefing. Und man möchte hinzufügen: nicht nur viel Überlegung, sondern mitunter vermutlich auch einige Überwindung.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Aber solche Überwindung ist im doppelten Sinn notwendig, das heißt als „freiheitlich-demokratischer Software-Mensch“ sich selbst überwinden und dann aber auch den Generalverdacht mancher Anwender überwinden, dass Open Source nicht unbedingt sicher ist. „Wir wollen und wir werden sehr zeitnah in sensible Bereiche mit unserer Infrastruktur-Software hineinkommen“, zeigt sich Wildeboer überzeugt, und er nennt ein Beispiel: „Linux eignet sich beispielsweise in jeder Hinsicht als Fahrzeug-Betriebssystem, auch wenn es sich um sensible Teilkomponenten wie etwa das Bremskontrollsystem handelt.“

Mit der beschriebenen Open Source-Software-Vertrauenskette ließen sich, so der „Red Hat-Multiplikator“ Wildeboer, gerade im Automobilherstellungsbereich Sicherheit und Standardisierung gemeinsam umsetzen. Eine solche Standardisierung sei für die Automobilhersteller rein kostenmäßig alternativlos, sie könnten nicht auf ewig unzählige verschiedene Softwaresysteme (manchmal seien es fast 100 verschiedene Systeme) entwickeln und warten. „Open Source ändert die Prozesse, wie man Software entwickelt“, ist sich Wildeboer sicher.

„Buchhaltung ohne Blockchain funktioniert besser“

Eine Anmerkung zum Schluss: Angesichts der vielen Protokoll- und Kontroll-Aufgaben innerhalb der Software-Vertrauenskette liegt die Frage nahe, ob man die damit verbundene „Buchhaltung“ nicht einer Blockchain überträgt, sozusagen der demokratische Open-Source-Gedanke unter dezentraler Buchhaltung. Red Hat-Evangelist Wildeboer zeigt sich bei dieser Journalisten-Frage eher skeptisch: „Ohne Blockchain geht das schlicht besser“, meinte er.

Und er fügte ein wenig ketzerisch hinzu: Wenn es um nachträgliche Änderungen in der Blockchain gehe, und die kämen durchaus vor, sei es sehr schnell zu Ende mit dem hochgepriesenen „dezentralen Konzept“ der Blockchain. Dann kämen die „permission blockchains“ zum Zuge, und die seien letztlich purer Zentralismus, nach dem Motto: „Nur wir können das“.

(ID:49533252)