Im Dezember\u00a02020 meldete SolarWinds, dass das Produkt \u201eOrion\u201c des Unternehmens Opfer eines gro\u00df angelegten Angriffs geworden war. Dieser er\u00f6ffnete dem Angreifer zudem eine Hintert\u00fcr zur Infrastruktur zahlreicher Kunden von SolarWinds, darunter auch mehrere Beh\u00f6rden. Das Ausma\u00df dieses Versto\u00dfes hat dazu gef\u00fchrt, dass Lieferketten-Schwachstellen und der Bedeutung von Drittanbieter-Abh\u00e4ngigkeiten f\u00fcr die Sicherheit von Softwaresystemen gro\u00dfe Aufmerksamkeit zuteil wurde. Auch wenn keine dieser Bedrohungen neu sind, hat die zus\u00e4tzliche Beachtung, die diesem Bereich geschenkt wurde, bei den Organisationen das starke Bed\u00fcrfnis geweckt, ihren Sicherheitsstatus zu verbessern, um nicht demn\u00e4chst selbst Opfer eines Angriffs zu werden. F\u00fcr Software-Engineering-Teams besteht die h\u00e4ufigste Interaktion mit der Lieferkette in der Auswahl der externen Bibliotheken, die sie in ihre Anwendungen integrieren m\u00f6chten.<\/p>\n
Eine gut gepflegte externe Bibliothek kann einen gro\u00dfen Vorteil f\u00fcr die Entwicklungsbem\u00fchungen ausmachen und unz\u00e4hlige Arbeitsstunden von Technikern einsparen, sodass Sie sich auf die wesentlichen Alleinstellungsmerkmale Ihres eigenen Produkts konzentrieren k\u00f6nnen, anstatt \u00fcbliche Funktionen neu zu implementieren. Im Gegensatz dazu kann die Nutzung sich bei schlecht umgesetzten Bibliotheken schwierig gestalten, und diese k\u00f6nnen Sicherheitsschwachstellen verursachen, die Risiken f\u00fcr Ihre Organisation und Ihre Kunden mit sich bringen. Im Extremfall k\u00f6nnen sie sogar den Betrieb von Teilen Ihres Dienstes st\u00f6ren, die gar nicht mit ihnen in Zusammenhang stehen, oder gar Ihre ganze Architektur beeintr\u00e4chtigen. In diesem Artikel stelle ich viele der \u00dcberlegungen vor, die ich angestellt habe, um Bibliotheken im Hinblick auf die Tragf\u00e4higkeit ihrer Entwicklungspraktiken und die zu erwartenden Auswirkungen auf die Sicherheit zu bewerten. Diese Ans\u00e4tze sollten als Ausgangspunkt verstanden werden, nicht als Anleitung. Finden Sie einen Ansatz, der Ihren eigenen Anforderungen entspricht. Zwar gibt es in diesem Bereich kein Wundermittel, aber wenn Sie sicherstellen, dass Ihr Projekt sich nur auf hochwertige Abh\u00e4ngigkeiten st\u00fctzt, k\u00f6nnen Sie Ihre Angriffsfl\u00e4che deutlich verkleinern und die Erweiterung und Wartung Ihres Produkts erleichtern.<\/p>\n
Diese erste \u00dcberlegung ist sehr wichtig, weil sie bestimmt, wie eingehend die Bewertung sein muss. Wie viele Funktionen liefert die Bibliothek? Wie wichtig sind diese Funktionen f\u00fcr die Funktion Ihres Produkts? Eine einfache Bibliothek mit geringen Auswirkungen erfordert weit weniger Aufmerksamkeit als ein umfangreiches Rahmenwerk, dass eng in Ihren eigenen Code integriert wird. Einige Indikatoren, die bei wichtigen Funktionen als Warnsignale betrachtet werden w\u00fcrden (z.\u00a0B. unregelm\u00e4\u00dfige Updates), k\u00f6nnen bei kleineren Bibliotheken, die nur einem extrem begrenzten Zweck dienen, als normal gelten bzw. erwartbar sein.<\/p>\n
Eine Frage, die damit zusammenh\u00e4ngt, ist, wie Sie die Bibliothek nutzen m\u00f6chten. Entwicklungsabh\u00e4ngigkeiten (etwa ein statisches Analysetool oder eine Komponente f\u00fcr ein Komponententest-Framework) stellen ein weit geringeres Risiko dar als Laufzeitabh\u00e4ngigkeiten. Fehler in Ihrer Entwicklungspipeline k\u00f6nnen zwar die Ver\u00f6ffentlichung einer Version verz\u00f6gern oder andere kurzfristige Probleme f\u00fcr die Entwickler hervorrufen, aber sie beeintr\u00e4chtigen weder die Benutzer noch stellen sie in der Regel ein Risiko f\u00fcr die Sicherheit der Anwendung selbst dar.<\/p>\n
Die schnellste M\u00f6glichkeit, sich einen \u00dcberblick \u00fcber den Projektstatus insgesamt zu verschaffen, besteht darin, sich den Quellcode-Verwaltungsverlauf anzuschauen. Wann wurde die letzte Version ver\u00f6ffentlicht? Wie oft werden neue Versionen ver\u00f6ffentlicht und hoch ist die Bearbeitungsrate des Quellcode-Repositorys? Es ist gut, wenn Projekte h\u00e4ufig aktualisiert werden, denn dann ist auch die Wahrscheinlichkeit h\u00f6her, dass die Bibliothek auch in Zukunft weiter gepflegt werden wird. Im Gegensatz dazu k\u00f6nnen Projekte, die f\u00fcr l\u00e4ngere Zeit unbeachtet geblieben sind, nicht behobene Fehler enthalten oder Kompatibilit\u00e4tsprobleme mit neuen Versionen verbreiteter Abh\u00e4ngigkeiten oder sogar der Sprachlaufzeit selbst verursachen.<\/p>\n
Auch ein Blick in das \u00c4nderungsprotokoll von Bibliotheken kann sehr n\u00fctzlich sein. Manchmal werden die \u00c4nderungen, die in den Versionen jeweils vorgenommen wurden, auf der Seite mit den Versionsangaben beschrieben. Manchmal ist das \u00c4nderungsprotokoll aber auch eine Datei auf der obersten Ebene des Quellcode-Repositorys. Wenn diese Informationen nicht ohne Weiteres verf\u00fcgbar sind, ist das ein wichtiges Warnsignal. Ich suche nach eindeutigen Beschreibungen der in einer Version im Vergleich zur vorherigen Version vorgenommenen \u00c4nderungen und achte darauf, dass eventuelle Abw\u00e4rtsinkompatibilit\u00e4ten eindeutig dokumentiert sind. Wenn allerdings sehr h\u00e4ufig \u00c4nderungen vorgenommen wurden, die zu Abw\u00e4rtsinkompatibilit\u00e4ten gef\u00fchrt haben, ist das allein schon besorgniserregend, denn es deutet darauf hin, dass die Entwickler bei der Planung von \u00c4nderungen und der Fehlerkorrektur vor der Ver\u00f6ffentlichung nicht mit der gebotenen Sorgfalt vorgehen.<\/p>\n
Bei einer eingehenderen Bewertung k\u00f6nnen auch das Fehlerprotokoll eines Projekts oder andere \u00f6ffentliche Kommunikationskan\u00e4le durchsucht werden. Wie schnell haben die Maintainer auf Benutzermeldungen reagiert? Haben Sie freundlich und zug\u00e4nglich auf Feedback reagiert oder war ihr Ton eher aggressiv? Wie sieht das Verh\u00e4ltnis von ge\u00f6ffneten zu geschlossenen F\u00e4llen aus? K\u00fcmmern sich die Maintainer aktiv um Bedenken von Benutzern oder lassen Sie Fehlermeldungen l\u00e4ngere Zeit unbeachtet liegen? Wie umfangreich ist die Dokumentation, und wie effektiv weist sie die Benutzer auf Best Practices bei der Implementierung hin? Scheint sich es eine lebhafte Community im Zusammenhang mit diesem Projekt zu geben? Ist beispielsweise der prim\u00e4re Maintainer gr\u00f6\u00dftenteils allein f\u00fcr den Support zust\u00e4ndig, oder sind andere Mitglieder der Community bereit und in der Lage, unterst\u00fctzend einzugreifen? Bei Projekten, die eine gesunde Beziehung zur jeweiligen Community pflegen, ist die Wahrscheinlichkeit h\u00f6her, dass es die Anforderungen der Benutzer erf\u00fcllt und schnell an ver\u00e4nderte Umst\u00e4nde angepasst wird.<\/p>\n
Diese Bewertung ist ein wenig aufwendiger, als einfach die H\u00e4ufigkeit der Versionen zu z\u00e4hlen, aber sie bietet Zugang zu einer wahren Schatzkammer voller Informationen. Zun\u00e4chst einmal m\u00f6chte ich herausfinden, wie viele weitere Abh\u00e4ngigkeiten einer Bibliothek bestehen und insbesondere, ob sie \u00fcberfl\u00fcssige Abh\u00e4ngigkeiten verursacht. Abh\u00e4ngigkeiten, die wichtige Funktionen einer Bibliothek bereitstellen, sind weit weniger bedenklich, als wenn viele weitere Bibliotheken f\u00fcr v\u00f6llig andere Aufgaben einbezogen werden. Jede zus\u00e4tzliche Abh\u00e4ngigkeit erzeugt zus\u00e4tzliche Komplexit\u00e4t und ein zus\u00e4tzliches Lieferkettenrisiko. Im Zweifelsfall k\u00f6nnen Sie das ganz einfach bewerten, indem Sie die Bibliothek in einem Docker-Container installieren und schauen, wie viele zus\u00e4tzliche Bibliotheken dabei hinzugef\u00fcgt werden.<\/p>\n
Die gr\u00f6\u00dfte Sorge in dieser Kategorie ist, wie leicht wir Abh\u00e4ngigkeiten aktualisieren k\u00f6nnen, wenn neue Schwachstellen erkannt werden. Daher sollte im Rahmen der Bewertung unbedingt \u00fcberpr\u00fcft werden, ob eine Abh\u00e4ngigkeit restriktiv (nur durch eine bestimmte Version einer Bibliothek erf\u00fcllbar) oder permissiv (durch mehrere Versionen erf\u00fcllbar) ist. Restriktive Abh\u00e4ngigkeiten sind \u00e4u\u00dferst problematisch, weil sie das Patching erschweren oder sogar Downgrades bei Bibliotheken erzwingen k\u00f6nnen, die wir f\u00fcr andere Funktionen brauchen. Es ist auch wichtig, wie aktuell diese transitiven Abh\u00e4ngigkeiten sind. Eine versionsgebundene Abh\u00e4ngigkeit, die eine zwei Monate alte Version erfordert, ist weit weniger bedenklich als eine Abh\u00e4ngigkeit von einer zwei Jahre alten Version. Ebenso ist es ein Zeichen f\u00fcr ein gut gef\u00fchrtes Projekt, wenn regelm\u00e4\u00dfig Aktualisierungen vorgenommen werden, durch die Abh\u00e4ngigkeiten auf dem neuesten Stand gehalten werden.<\/p>\n
Sie sollten besonders aufmerksam sein, wenn Pakete, die in einer Programmiersprache geschrieben sind, zus\u00e4tzliche Abh\u00e4ngigkeiten in einer anderen Sprache aufweisen (beispielsweise Bibliotheken in Python, in die Erweiterungen in C kompiliert wurden). Wenn die sekund\u00e4ren Abh\u00e4ngigkeiten eine Sprache oder Programmierumgebung beinhalten, mit der Sie nicht so vertraut sind, ist es schwieriger, ihre Qualit\u00e4t insgesamt zu bewerten. Au\u00dferdem gelten f\u00fcr unterschiedliche Sprachen oft auch unterschiedliche Packaging-Konventionen, und die Maintainer f\u00fcr gemischtsprachige Projekte kennen oft nicht die Best Practices f\u00fcr alle Programmiersprachen, mit denen sie arbeiten, wodurch Patching und Aktualisierungen noch weiter erschwert werden.<\/p>\n
Kryptografische Bibliotheken verdienen aufgrund der damit verbundenen algorithmischen Komplexit\u00e4t und der gro\u00dfen Auswirkungen potenzieller Schwachstellen in diesem Bereich besondere Beachtung. Sie sollten diese Bibliotheken besonders sorgf\u00e4ltig pr\u00fcfen und sicherstellen, dass Sie nur mit sorgf\u00e4ltig gepr\u00fcften und bew\u00e4hrten Bibliotheken arbeiten. Einige sichere Optionen sind OpenSSL f\u00fcr C und C++, BouncyCastle f\u00fcr Java und die Kryptografiebibliothek von PyCA f\u00fcr Python. Die Sicherheitsrichtlinie oder Compliance-Vorgaben Ihres Unternehmens k\u00f6nnen Ihre Optionen einschr\u00e4nken. Sie sollten bekannte Schwachstellen in kryptografischen Bibliotheken kennen und sich im Hinblick auf neue Versionen auf dem Laufenden halten. Von allen Abh\u00e4ngigkeiten von Drittanbietern haben sie die gr\u00f6\u00dften Auswirkungen auf die Sicherheit.<\/p>\n
Die Bewertungen in diesem und dem n\u00e4chsten Abschnitt sind sehr aufwendig, aber in F\u00e4llen mit h\u00f6herem Risiko kann dieses Ma\u00df an Aufmerksamkeit gerechtfertigt sein. Wenn ich mir einen \u00dcberblick \u00fcber die allgemeine Codequalit\u00e4t eines Projekts verschaffen m\u00f6chte, versuche ich, Quellcode zu finden, der Funktionen verwendet, mit denen ich mich bereits gut auskenne, und bewerte, wie gut dieser kleine Ausschnitt aus der Codebasis geschrieben ist. Manchmal schaue ich mir die Qualit\u00e4t der Dokumentation zu dem Projekt an und konzentriere mich dabei darauf, wie klar sie formuliert ist und wie effektiv komplexe Konzepte dargestellt sind. In beiden F\u00e4llen versuche ich so herauszufinden, ob die Maintainer sehr auf Details achten oder ob sie eher nachl\u00e4ssig arbeiten. Die Erwartung dahinter ist, dass die Sorgfalt, die bei diesem Teil des Projekts an den Tag gelegt wird, auf den Gesamtzustand \u00fcbertragen werden kann.<\/p>\n
Wenn ich mir als konkretes Beispiel den Umgang des Python-Projekts mit SSL anschaue, achte ich auf Folgendes:<\/p>\n
Bei einer solchen Bewertung erwarte ich solide Designprinzipien und dass Standard-Idiome wiederverwendet werden. Au\u00dferdem sollte der Autor m\u00f6gliche Bed\u00fcrfnisse der Benutzer vorhersehen und f\u00fcr eine geeignete Erweiterbarkeit sorgen, um sie zu erf\u00fcllen.<\/p>\n
Ich behandle diesen Punkt zuletzt, weil dies normalerweise ein Eindruck ist, der sich bei mir erst im Laufe der Zeit entwickelt und der bei einer ersten Bewertung nicht unbedingt hilfreich ist. Er h\u00e4ngt auch sehr stark davon ab, wie verbreitet und sicherheitsrelevant eine bestimmte Bibliothek ist. Allerdings kann dieser Faktor durchaus eine Rolle bei der Entscheidung spielen, ob eine vorhandene Bibliothek weiter verwendet oder der Versuch unternommen werden sollte, auf einen Ersatz umzustellen.<\/p>\n
Einfach ausgedr\u00fcckt versuche ich zu bewerten, wie schnell die Projekt-Maintainer reagieren, wenn es darum geht, Schwachstellen zu schlie\u00dfen, und wie leicht wir die Vorteile dieser Patches in unseren eigenen Bereitstellungen nutzen k\u00f6nnen. Ein Projekt, f\u00fcr das h\u00e4ufig Schwachstellen gemeldet werden, ist in einem gewissen Ma\u00dfe besorgniserregend, aber dies kann ebenso leicht darin begr\u00fcndet sein, dass es weit verbreitet und sicherheitsrelevant ist, wie in der allgemeinen Codequalit\u00e4t und den Wartungspraktiken. Ein geeigneteres Kriterium ist, was geschieht, wenn eine Schwachstelle bekannt wird. Werden Patches schnell in neue Versionen aufgenommen? Wie einfach sind Upgrades, wenn Versionen mit Patches ver\u00f6ffentlicht wurden? Wenn das Projekt h\u00e4ufig weitreichende \u00c4nderungen vornimmt und insbesondere wenn sie regelm\u00e4\u00dfig die Abw\u00e4rtskompatibilit\u00e4t st\u00f6ren, werden dann Fehlerbehebungen r\u00fcckg\u00e4ngig gemacht und wieder auf die alten Versionen zur\u00fcckgegriffen? Wenn die Bibliothek Teil einer Linux-Distribution ist, sind eher die f\u00fcr die Distribution zust\u00e4ndigen Maintainer daf\u00fcr verantwortlich, Patches r\u00fcckg\u00e4ngig zu machen, als die urspr\u00fcnglichen Entwickler. Allerdings k\u00f6nnen die gleichen Fragen auch gestellt werden, wenn es darum geht, wie der Paketersteller mit der Bibliothek umgeht (Distributionen unterscheiden h\u00e4ufig zwischen Kern-Paketen mit aktiver Wartung und eher peripheren Paketen, die in der Regel Upstream-Versionen mit minimalen \u00c4nderungen verfolgen).<\/p>\n
Wenn eine Bibliothek in der Vergangenheit nicht gut mit Schwachstellen umgegangen ist oder in einer Weise vorgeht, die es schwierig macht, Sicherheitspatches zu nutzen, empfehle ich meinem Team oft, auf einen Ersatz umzustellen.<\/p>\n
Die Bewertung der Gesamtqualit\u00e4t von Softwareprojekten und der Communitys, die sie umgeben, ist eine wichtige F\u00e4higkeit, die umso wichtiger wird, je st\u00e4rker Softwareprojekte voneinander abh\u00e4ngig werden. Es ist zudem eine au\u00dferordentlich individuelle F\u00e4higkeit. Sie werden oft wohl am meisten profitieren, wenn Sie die Entscheidungen von Maintainern f\u00fcr Bibliotheken aus Ihrem eigenen Fachgebiet untersuchen. Da es noch schwieriger ist, potenzielle Lieferanten in allen Einzelheiten zu beurteilen, als die Funktionen selbst zu entwickeln, wird bei diesem Bewertungsprozess ein gewisses Ma\u00df an Vertrauen aufgebaut und Ma\u00dfnahmen ergriffen, die sicherstellen sollen, dass dieses Vertrauen auch berechtigt ist. Letztendlich tr\u00e4gt es entscheidend zum Aufbau einer Entwicklungskultur, die sich durch Verantwortung f\u00fcr die Sicherheit und Zuverl\u00e4ssigkeit von Produkten auszeichnet, bei, wenn man lernt, Drittanbieter-Abh\u00e4ngigkeiten zu bewerten.<\/p>\n
Jacob Emmert-Aronson<\/a> ist leitender Ingenieur im Mindmeld-Team, das zu Webex Intelligence geh\u00f6rt. Er geh\u00f6rt zu den f\u00fchrenden K\u00f6pfen in den Bereichen Sicherheit, DevOps und Softwarepflege und besch\u00e4ftigt sich insbesondere mit den Schnittmengen dieser Themenbereiche.<\/p>\n M\u00f6chten Sie im MindMeld-Team mitarbeiten? Senden Sie eine E-Mail an mindmeld-jobs@cisco.com!<\/span><\/p><\/blockquote>\n F\u00fcr Webex anmelden<\/a><\/p>\n Besuchen Sie unsere Homepage<\/a> oder kontaktieren Sie uns<\/a> direkt, wenn Sie Unterst\u00fctzung ben\u00f6tigen.<\/p>\n