Ist die Zukunft von Open Source in Gefahr?

Open Source Software (OSS) ist das Rückgrat der heutigen Anwendungsarchitektur. Durch die Beschleunigung der Markteinführungszeit und die Entlastung häufig überarbeiteter Entwickler hat Open Source seine revolutionäre Position innerhalb der DevOps-Landschaft gefestigt. Obwohl Open-Source-Copy-and-Paste die Entwicklung moderner Anwendungen grundlegend verändert, stellt es weiterhin ein großes Sicherheitsrisiko für Unternehmen und Einzelpersonen dar. Um dies zu bekämpfen, ist entweder eine vollständige Blacklist von Open-Source-Code oder die proaktive Implementierung von Gegenmaßnahmen wie einer WAF-Lösung der nächsten Generation erforderlich .

Code von Drittanbietern ist für die App-Entwicklung von entscheidender Bedeutung

Bibliotheken sind unglaublich praktische Verstecke von Quellcode für Web- oder mobile Anwendungskomponenten. Diese Bibliotheken können Open-Source sein – für jeden kostenlos verfügbar – oder proprietär, wodurch der Code hinter der Zahlung gesperrt wird. Obwohl Open Source viel Ruhm beansprucht, spielt auch proprietärer Code eine Rolle für das weitere Funktionieren von Unternehmensanwendungen.

Diese Software von Drittanbietern verhindert bei verantwortungsvoller Verwendung, dass Entwickler das Rad ständig neu erfinden müssen. Dies verbessert die Effizienz des Entwicklungsprozesses drastisch und unterstützt gleichzeitig die Produktion eines hochwertigen Endprodukts. Letztendlich schafft die freie und liberale Nutzung von Open-Source-Code eine positive Feedback-Schleife, die es Entwicklern ermöglicht, ihr minimal lebensfähiges Produkt schneller zu veröffentlichen, was den Weg für eine schnelle Sammlung und Implementierung von Benutzerfeedback und -bewertung ebnet. Obwohl sich Entwickler der kritischen Position von Open Source innerhalb des DevOps-Prozesses sehr bewusst sind, sind Führungskräfte oft überrascht, wenn sie erfahren, dass 80 % des Codes , der moderne Anwendungen unterstützt, aus bereits vorhandenem Code stammen.

Die schattenhafte Gefahr transitiver Abhängigkeiten

Es ist keine Neuigkeit, dass Open-Source-Code mit Risiken verbunden ist. Kürzlich weit verbreitete Schwachstellen wie Log4j und HeartBleed haben das Open-Source-Risiko unwiderruflich auf die Landkarte gebracht. Was nach wie vor ein wachsender Bereich des Verständnisses ist, ist die schiere Häufigkeit, mit der Open Source verwendet wird, und die Heimlichkeit, mit der sich Schwachstellen in ein aktives Projekt einschleichen können. Trotz des anhaltenden Risikos, das Open Source-Projekte darstellen, wurde nur sehr wenig Forschung zu der spezifischen Art von Risiken durchgeführt, die Open Source darstellt. Forscher von Endor Labs wollten dies ändern, indem sie den Ursprung der wichtigsten OSS-Bedrohungen klären.

Innerhalb von Software beschreiben transitive Abhängigkeiten eine eindeutig indirekte Beziehung zwischen zwei Komponenten. Angenommen, Ihr Entwicklerteam fügt Paket B zu einem laufenden Projekt hinzu. Paket B wiederum lädt automatisch Paket C herunter. Während die entwickelnde Software in diesem Szenario eine direkte Beziehung zu Paket B hat, bleibt Paket C im Hintergrund lauern – integral, aber weitgehend unsichtbar. Frustrierend für jeden Versuch sichererer Entwicklungspraktiken ist die Tatsache, dass nur 5 % der Abhängigkeiten von Open-Source-Software manuell für die Implementierung innerhalb des DevOps-Prozesses ausgewählt werden. Auf diese Weise werden die meisten Abhängigkeiten einfach automatisch in die Codebasis gezogen. Dies beschreibt die Quelle einer transitiven Schwachstelle. Ein kürzlich von Endor Labs veröffentlichter Bericht ergab, dass erstaunliche 95 % der Open-Source- Schwachstellen auf transitive Abhängigkeiten zurückzuführen sind .

Die Daten wurden aus dem Census II-Bericht von Core Infrastructure zusammengestellt, der die beliebteste kostenlose Open-Source-Software auflistet. Diese Daten wurden dann mit anderen Quellen angereichert, die es Endor-Forschern ermöglichten, beliebte Paketmanager und OSS-Bibliotheken zu scannen. Die Forscher entdeckten, dass – von 254 in den Census II-Daten erwähnten Paketen – die meisten unter durchschnittlich 14 transitiven Abhängigkeiten leiden. In einem Vakuum mag 14 nicht erschreckend hoch erscheinen, aber die meisten Anwendungen beruhen auf Dutzenden – wenn nicht Hunderten – direkter Abhängigkeiten; ihre transitiven Gegenstücke skalieren exponentiell.

Die größte Sorge der Forscher beruht auf der weit verbreiteten Unterschätzung des Problems durch die Industrie. Führungskräfte untergraben weiterhin die Menge an Quellcode, die im Entwicklungsprozess verwendet wird – transitive Abhängigkeiten sind noch nicht einmal auf dem Radar. Die schiere Tiefe der Sicherheitsprobleme lauert weiterhin unter der Oberfläche und vergrößert den Explosionsradius von Typosquatting- und Remote-Code-Execution-Angriffen. Wenn die ständige Wiederverwendung von Open-Source-Code ihr Potenzial voll ausschöpfen soll, muss die Sicherheit innerhalb des DevOps-Prozesses eine höhere Priorität erhalten.

So schützen Sie sich vor lauernden Schwachstellen

Der Prozess der Aufrechterhaltung eines sicheren Tech-Stacks war noch nie so komplex. Da Patch-Warnungen schnell überwältigend werden, ist es für die Unternehmenssicherheit an der Zeit, automatisierten, patchfreien Schutz zu priorisieren. Herkömmliche Maßnahmen, die der Perimetersicherheit neben statischen und dynamischen Analysen Priorität einräumen, verlassen sich auf manuelle Updates, was bedeutet, dass es keinen Schutz vor Zero-Days gibt. Der Backdoor-Code, den Angreifer im Rahmen des berüchtigten SolarWinds-Angriffs verwendeten, wurde von keiner statischen Analyse erkannt, da es technisch keine Fehler gab.

Das Identifizieren und Blockieren von Ausnutzungsversuchen erfordert eine kleine Suite ineinandergreifender Software. Um zunächst den Perimeter einer Anwendung zu definieren und zu schützen, kann eine Web Application Firewall (WAF) der nächsten Generation bereitgestellt werden. An der Grenze zwischen extern und intern sitzend, überwacht die WAF den gesamten Datenverkehr zu und von einer Anwendung. Der Next-Gen-Aspekt ermöglicht es dieser WAF, neue Richtlinien automatisch anzupassen und umzusetzen. Die automatisierte Bereitstellung dieser ständigen Weiterentwicklung setzt dem Sicherheitsteam viel Zeit und Energie frei, die eine WAF der alten Schule andernfalls verbrauchen würde.

Während WAF alle externen Versuche, Code auszuführen, im Griff behält, schützt Runtime Application Self Protection (RASP) vor internen Schwachstellen und Code-Injektionen. Dieses Schutzniveau wertet alle Payloads (z. B. SQL-Abfragen und Betriebssystembefehle) in Echtzeit aus. Dieser Prozess erfordert weder Unterschriften noch eine Lernphase und findet vollständig im Anwendungskontext statt. Da dies innerhalb der Anwendung operiert, deckt es fast alle Kontexte ab. Das bedeutet, dass selbst wenn ein Exploit das Durchbrechen des Perimeters ermöglicht, ein Angreifer daran gehindert wird, sich seitlich zu bewegen, da jedes verdächtige Anwendungsverhalten eine RASP-Abschaltung auslöst. Dadurch werden die verdächtigen Aktivitäten beendet und die Sicherheitsteams alarmiert. Auf diese Weise ist RASP komplementär zu einer WAF der nächsten Generation; Während die WAF dazu beiträgt, den schlechten Datenverkehr fernzuhalten, wird das Risiko durch lauernde, transitive Exploits durch RASP gemindert. Mit diesen Komponenten, die einen Tech-Stack schützen, wird die Belastung, die OSS derzeit der Sicherheit auferlegt, erheblich erleichtert.