Supply-chain Levels for Software Artifacts: „Eine feine Sache“ Suse-CTO Gerald Pfeifer zur Absicherung von Softwarelieferketten

Von Ulrike Ostler

Anbieter zum Thema

Die Cloud-Native-Konferenzen „KubeCon/CloudNativeCon“ in Valencia sowie die hauseigene „Susecon Digital 22“ haben kürzlich stattgefunden und auf beiden hat sich ein vergleichsweise neues Thema in den Vordergrund geschoben: die Unsicherheit in den Softwarelieferketten. Für DataCenter-Insider hat sich Suse-Manager Gerald Pfeifer, CTO sowie Chair des Opensuse-Board, bereit erklärt, dazu Fragen zu beantworten.

„Wenn eine Himbeere in einer Kiste schimmelt, breitet sich das rasch aus“, sagt Dr. Gerald Pfeifer von Suse, um die Wirkung infiltrierter Glieder in einer Softwarelieferkette zu verdeutlichen.
„Wenn eine Himbeere in einer Kiste schimmelt, breitet sich das rasch aus“, sagt Dr. Gerald Pfeifer von Suse, um die Wirkung infiltrierter Glieder in einer Softwarelieferkette zu verdeutlichen.
(Bild: gemeinfrei: 1195798 / Pixabay )

Um zu verstehen, wie drängend das Problem ist, zieht Pfeifer Zahlen des Marktforschungs- und Beratungsunternehmens Gartner aus dem Report „7 Top Trends in Cybersecurity for 2022“ vom April dieses Jahres und andere zur Bestandsaufnahme heran:

  • Bis 2025 werden 45 Prozent der Unternehmen weltweit Angriffe auf ihre Software Lieferkette erlebt haben, das prognostiziert Gartner - ein dreifacher Anstieg gegenüber 2021.
  • 42 Prozent der IT-Führungskräfte geben an, dass ihr IT-Betrieb und ihre Technologie nicht für eine ordnungsgemäße Umsetzung ihrer Strategie konfiguriert sind. (siehe: „Accenture Reinventing Operations in Asset Management“ von 2019)

Dr. Gerald Pfeifer
Dr. Gerald Pfeifer lebt und arbeitet in Wien, Nürnberg und wo immer seine Rolle als und seine Leidenschaft für Yoga und Tauchen ihn hinführen. Er hat in technischen Wissenschaften promoviert und beschäftigt sich mit Open Source, schon bevor dieser Begriff überhaupt geprägt wurde.

Bildquelle: Suse

Sichere Lieferketten (Secure Supply Chains) sind ein Thema, das uns dieser Tage von vielen Seiten erreicht. Wie erleben Sie das?

Gerald Pfeifer: Ja, Secure Supply Chains sind aktuell in vieler Munde. Und zu Recht - gerade in der modernen IT, die schneller und bunter ist als jemals zuvor. Updates erfolgen oft nicht mehr jährlich sondern viel öfter, teils wöchentlich oder noch rascher. Denken Sie nur an die Apps auf Ihrem Handy. Und für Entwicklungsteams, besonders in-house, war es noch nie so einfach, sich aus einem Buffet an Komponenten, viele davon Open Source, zu bedienen.

Die Schattenseite? Oft sind Herkunft und Qualität von Komponenten nicht einfach ersichtlich, etwa wenn ein Entwickler ein weiteres Javascript, Perl, Python, Ruby, usw. Modul einbindet.

Bei Supply Chain Security geht es, wie bei Security allgemein, ja auch nicht um eine Momentaufnahme, sondern darum, die Qualität über die Zeit zu überprüfen und sicherzustellen. Das ist viel Arbeit. Und erfordert viel Know-how.

Das ist ja ein eher neuer Themenbereich. Haben Sie da überhaupt schon Erfahrungen und Tipps?

Gerald Pfeifer: Secure Supply Chain mag für viele Anwender jetzt neu im Fokus stehen. Für Open Source Distributoren wie uns ist das seit geraumer Zeit täglich Brot. Unsere Lösungen bestehen in Summe aus tausenden Komponenten verschiedenster Provenienz, alle Open Source. In Summe ist das noch einmal eine Größenordnung mehr: Maintainer, Entwickler und deren jeweilige Infrastruktur mit der entwickelt und verteilt wird.

Hier muss ein Anbieter beziehungsweise Anwender einerseits sicherstellen, dass mit einem Update nicht Unerwünschtes mit rein rutscht: Unbeabsichtigt etwa ein Bug, oder gezielt, wie wir das unlängst im Rahmen des Krieges gegen die Ukraine gesehen haben, als Entwickler 'Peaceware' eingeschleust haben, mit teils dramatischen Auswirkungen.

Andererseits muss ein Hersteller sicherstellen, dass gerade bei sicherheitsrelevanten Aspekten wie Kryptographie, diese Komponenten eben genau das tun, was sie sollen, und sie Zertifizierungen wie FIPS 140-4 unterziehen.

Google hat dazu eine Initiative namens SLSA (Supply-chain Levels for Software Artifacts) ins Leben gerufen.

Gerald Pfeifer: Ja, das ist eine feine Sache. 650 Prozent, um so viel haben laut Sonatype, die das seit sieben Jahren untersuchen, Cyberattacken auf die Quellen von Open Source Ökosystemen alleine 2021 zugenommen. Also mehr als versiebenfacht. Das ist brutal.

Glücklicherweise erfüllen wir bei Suse die meisten Aspekte von SLSA Level 4, das ist der höchste Level - ohnedies seit Jahren. Wir haben an wenigen Stellen, etwa bei der langfristigen Aufbewahrung aller Artefakte, die beim Bauen anfallen, nachjustiert. SLSA ist definitiv eine gute Initiative. Ich rate daher allen zu schauen, wie sich ihre Lieferanten hier positionieren und durchaus nachzuhaken.

Wie auch sonst gilt natürlich: Sicherheit ist eine Einstellung, ein Prozess, keine einmalige Hauruckaktion. Nur wenn alle Komponenten laufend überprüft und aktuell gehalten werden, ist Sicherheit realisierbar

Wenn ich also jetzt früh und proaktiv für Sicherheit in der Lieferkette sorge, bin ich als Anwender dann ausreichend sicher?

Gerald Pfeifer: Sicherheit in der Lieferkette ist ein wesentlicher Bestandteil jedes erfolgreichen Ansatzes. Denken wir an eine Küche: Die Qualität der Zutaten ist immens wichtig und auch die lückenlose Kühlkette der Lebensmittel auf dem Weg vom Ursprung zum Verbraucher. Wenn eine Himbeere in einer Kiste schimmelt, breitet sich das rasch aus. Und wenn wir nicht auf Hygiene in der Küche und beim Kochen achten, um den IT-Terminus zu verwenden, Zugangskontrolle beachten, richten sich schnell Mäuse, Motten und Maden ein.

Sprich: Die Lieferkette ist wichtig, und dabei ist jedes Glied jeder einzelnen Lieferkette von Bedeutung im Gesamtkonzept. Ebenso wichtig ist aber der klassische Betrieb, beispielsweise Zugangskontrollen, User Security (Zwei-Faktor-Authentifizierung), nur notwendige Berechtigungen vergeben und verwenden

Dabei kann ich natürlich nicht statisch bleiben. Stagnation ist Tod. Das gilt in der Natur, und ebenso in der IT. (Auch eine Common Criteria Zertifizierung auf EAL 4+, dem höchsten Level für ein allgemeines Betriebssystem wie Suse Linux Enterprise Server, inkludiert die Bereitstellung von Updates als eine wesentliche Komponente. )

Das führt uns zurück zu den Lieferketten, und deren kontinuierlichen Fluss - vom Ursprung über meine direkten Quellen in den Betrieb. Und damit auch zu Themen wie Patchen und Updaten, glatt und möglichst ohne Unterbrechungen des laufenden Betriebs. Solches Live-Patching ist ein eigens sehr spannendes Thema.

Das klingt jetzt eher nach klassischer IT. Inwieweit ist das bei Containern, die wir ja mehr und mehr im Einsatz sehen, überhaupt relevant?

Gerald Pfeifer: Nun, Container existieren nicht im luftleeren Raum. Auch sie müssen gebaut und verteilt werden und auf einer Containerplattform laufen. Und egal wer diese betreibt, sei es ein Megascaler, ein lokaler Betreiber oder die eigene in-house IT, was wir bis jetzt besprochen haben, gilt eins-zu-eins all diese Plattformen. Im Besonderen: eine Konzentration von mehreren, im Fall von Megascalern Millionen von Anwendungen auf einer Plattform, macht die Sicherheit und Verfügbarkeit dieser umso wichtiger.

Und was läuft in Containern? Anwendungen, oft sehr feingliedrig und dynamisch aufgeteilt in Form von sogenannten Microservices, oft bestehend aus vielen Komponenten aus verschiedenen Quellen, und in vielen Fällen sehr häufig (bis hin zu mehrmals täglich) upgedatet – womit wir wieder bei sicheren Lieferketten gelandet sind.

Gerade in derart dynamischen Umgebungen, die oft auch noch sehr verteilt sind – in Clouds, kleinen Niederlassungen, Rechenzentren, Satelliten, Autos, letztlich überall wo das Internet hin kommt - ist Sicherheit a priori noch schwieriger zu garantieren als in der klassischen IT. Hier gilt es neue, andere Ansätze, um Konzepte wie Zero Trust zu fahren, also Sicherheitssysteme, die lernen, was normal und erlaubt ist, und erkennen, melden, oder gar blockieren, was ungewöhnlich scheint. Das zielt insbesondere auf Systeme wie Open Zero Trust, die nicht darauf angewiesen sind, in einer sterilen Umgebung zu laufen, sondern mit Unsicherheit, Risiken und neuen Bedrohungen behände umgehen können.

Artikelfiles und Artikellinks

(ID:48418029)