Sichere Anwendungsentwicklung – worauf Sie bei der Arbeit mit Open Source achten sollten

Wir bei T1 Cloud sprechen weiterhin über die sichere Entwicklung von Secure SDLC-Anwendungen. Heute werden wir ausführlicher auf potenzielle Schwachstellen in Komponenten eingehen Open Source und wie man sich davor schützt.

/ Unsplash.com / Chris Barbalis/ Unsplash.com / Chris Barbalis

Die überwiegende Mehrheit der Anwendungen beruht auf der Open Source. Durch Auswertung Laut den Analysten von Synopsys enthalten 99 % der proprietären Codebasen mindestens eine Open-Source-Komponente. Diese Praxis, selbst an geschäftskritischen Diensten zu arbeiten, ist nicht nur auf Einsparungen, sondern auch auf eine erhöhte Zuverlässigkeit zurückzuführen. Einmal entdeckte Fehler und Mängel werden durch die gemeinsamen Bemühungen der Community schnell behoben, sodass offene Komponenten besser geschützt sind. Aber in der Praxis gibt es Fallstricke.

Fallstricke von Open Source

Viele Open-Source-Produkte sind große Projekte wie Kubernetes oder TensorFlow. Sie werden von großen IT-Unternehmen entwickelt und finanziert, die Spezialisten einstellen, um Schwachstellen zu finden und zu beheben. Es gibt jedoch eine ganze Schicht Open Source Lösungen, an denen Enthusiasten in ihrer Freizeit arbeiten. Oft sind diese Menschen die einzigen Mitwirkenden, obwohl ihre Projekte das „Herz und die Seele“ der Infrastruktur von Banken, Mobilfunkbetreibern und anderen Organisationen sind.

Solche Projekte haben oft weder eine verlässliche finanzielle Basis noch Garantien für einen normalen Betrieb. Höchstwahrscheinlich führen sie keine eingehende Überwachung von Schwachstellen durch. Gleichzeitig hängt jedes offene Projekt von anderen ab – kleineren. Diese Abhängigkeitskette kann leicht eine Sicherheitslücke sein, lebensfähig über vier Jahre.

Also Situationen wie die passiert mit der Log4j-Logging-Bibliothek. Das Team engagiert sich ehrenamtlich für das Projekt und erhält fast kein Geld für seine Unterstützung. Ende letzten Jahres im Bibliothekscode gefunden eine Schwachstelle, die seit weit vom ersten Jahr an besteht. Es ermöglichte die Ausführung von bösartigem Code auf dem Server mithilfe des Mechanismus JNDI.

Es war ein Glück, dass im Fall von Log4j die Entwickler die Behebung von Mängeln aufgegriffen haben. Aber es gibt Tausende anderer Projekte, die entweder aufgegeben werden oder von außen nicht die gebührende Aufmerksamkeit erhalten. Open Source Gemeinschaften. Synopsys-Experten stellen fest, dass bis zu 75 % der Codebasen enthalten offene Komponenten mit “ungepatchten” Schwachstellen.

In den allermeisten Fällen sind Schwachstellen in Open Source Lösungen sind das Ergebnis eines Betreuerfehlers oder eines Fehlers in Komponenten von Drittanbietern. Es gibt jedoch Situationen, in denen böswilliger Code absichtlich in den Quellcode eines Projekts eingebettet wird. Also, im Mai, der Autor von node-ipc hinzugefügt Es enthält Malware, die alle Dateien von Geräten mit bestimmten IP-Adressen löscht. Eine ähnliche Aktion wurde Anfang des Jahres vom Betreuer der Pakete faker.js und colors.js durchgeführt. Er umgesetzt in den Code eine Endlosschleife, die eine bedeutungslose Folge von Zeichen an die Konsole ausgibt. Infolgedessen wurde die Arbeit von Tausenden von Unternehmen auf der ganzen Welt, einschließlich führender Cloud-Anbieter, gestört.

Eine ähnliche Geschichte ereignete sich 2018 mit der Node.js-Bibliothek – Event-Stream. Der Maintainer beschloss, zu anderen Projekten zu wechseln, also übertrug er die Rechte am Repository an einen Freiwilligen aus der Community. Nach einiger Zeit das umgesetzt ein Skript, das die Daten von Kryptowährungs-Wallets von Benutzern in das Dienstprogramm stiehlt.

Was tun damit

Unabhängig davon, ob der Code kostenlos oder proprietär ist, muss er geprüft und gewartet werden, da sonst ein Sicherheitsrisiko für jede Software besteht, die ihn verwendet. Macht erstmal Sinn bilden Katalog aller Beteiligten Open Source Lösungen und Bibliotheken. Es sollte die Versionen der verwendeten Produkte und bevorstehende Updates widerspiegeln. Mit diesem Ansatz können Sie sich ein vollständiges Bild machen – welche Open Source in dem Projekt verwendet wird (und wo genau).

Gleichzeitig ist es notwendig, Tools zum Scannen von Software-Kompositionsanalyse (SCA)-Schwachstellen zu konfigurieren. Das sind Lösungen, um Fehler im Code zu finden und zu beseitigen und externe Bibliotheken zu kontrollieren. Sie analysieren Versionen, Abhängigkeiten und andere Unterscheidungsmerkmale und gleichen sie dann mit Schwachstellendatenbanken wie NVD ab. Mit SCA-Systemen können Sie den Schweregrad einer Schwachstelle und ihre potenziellen Auswirkungen auf Geschäftsprozesse bewerten sowie Schritte zur Problemlösung vorschlagen.

/ Unsplash.com / Matthew Feeney/ Unsplash.com / Matthew Feeney

Das Scannen innerhalb von SCA ist einfach genug eingebettet in der CI/CD-Pipeline. Beispielsweise können Entwickler automatische Benachrichtigungen über Probleme mit den Komponenten erhalten, die sie verbinden möchten. Wenn Sie sich frühzeitig mit Schwachstellen befassen, können Sie Geld sparen – einigen Schätzungen zufolge sind die Kosten für die Behebung von Fehlern nach der Veröffentlichung bis zu dreißig Mal höher. Natürlich können Sie scannen, wenn das Projekt bereits in Produktion gegangen ist. Jeden Tag werden neue Fehler gefunden, und die 0-Tage-Benachrichtigung über Injektionen und Schwachstellen minimiert potenzielle Schäden.

Jedes Unternehmen kann solche Tools selbst aufsetzen, wenn es über App Sec-Expertise verfügt. Aber Sie können diese Themen auf die Schultern des Cloud-Anbieters verlagern – zum Beispiel bieten wir die notwendigen Tools in T1 Cloud an. Plattform Cloud-sichere Entwicklungsplattform ist in der Lage, eine Analyse der Sicherheit externer Komponenten (OST) durchzuführen. Es meldet bekannte Schwachstellen und andere Einschränkungen in Bibliotheken und Frameworks.

Die Lösung schützt vor Bedrohungen, wenn Informationen über die Schwachstelle veröffentlicht werden, die Entwickler jedoch keine Zeit hatten, den Fehler zu beheben, oder der Patch bereits veröffentlicht wurde, die anfällige Version der Komponente jedoch weiterhin in Geschäftsprozessen verwendet wird. Dies ist besonders wichtig vor dem Hintergrund, dass Informationssicherheitsspezialisten immer weniger Zeit haben, Schwachstellen zu identifizieren – der erste Exploit ist ziemlich Kann erscheinen in einer Woche. Das OST-System in der T1 Cloud basiert auf dem Tool Abhängigkeitscheck in Partnerschaft mit Spezialisten von SolidLab. Um den Dienst zu verbinden, benötigen Sie:

  • Wenden Sie sich an den technischen Support und füllen Sie ein Formular aus, in dem die mit dem Service verbundenen Produkte angegeben sind.

  • Besprechen Sie mit den Ingenieuren von SolidLab die Anforderungen für den Analyseprozess für externe Komponenten und bestimmen Sie die Implementierungskosten. Sie wird individuell sein, da sie von Umfang und Umfang der Anwendungen, der Anzahl der Mitarbeiter und anderen Infrastrukturmerkmalen abhängt.

  • Führen Sie eine „Bereitschaftskarte“ aus: Weisen Sie die erforderlichen Ressourcen zu, gewähren Sie Zugriff und so weiter.

  • Verbinden Sie den Dienst und integrieren Sie OST-Analyzer mit CI/CD-Tools.

Schließlich bleibt es, die Entwickler darin zu schulen, mit den Tools zum Analysieren und Analysieren der erkannten Mängel zu arbeiten. Unsere Spezialisten des technischen Supports und SolidLab-Vertreter helfen Ihnen auch bei diesen Fragen.

Zuverlässige Anwendungsentwicklungsserie:

Weitere Lektüre auf unserem Blog:

Similar Posts

Leave a Reply

Your email address will not be published.