Diese Seite ist ganz oder teilweise automatisch übersetzt.

Nachricht schreiben an

Sie haben keinen Betreff angegeben, möchten Sie die Nachricht ohne Betreff versenden?
Bitte beachten Sie, dass Ihre Nachricht maximal 1000 Zeichen lang sein darf
Sonderzeichen '<', '>' sind im Betreff und in der Nachricht nicht erlaubt
reCaptcha ist ungültig.
reCaptcha ist aufgrund eines Serverproblems gescheitert.

Ihre Nachricht wurde gesendet

Sie finden die Nachricht jetzt in Ihrem persönlichen Bereich unter „Meine Nachrichten“.

Es ist ein Fehler aufgetreten

Bitte versuchen Sie es nochmal.

Termin vereinbaren mit

Damit Sie einen Termin vereinbaren können, wird der Kalender auf dem persönlichen Profil Ihres Ansprechpartners in einem neuen Tab geöffnet.

Vor-Ort-Termin vereinbaren mit

Damit Sie einen Vor-Ort-Termin vereinbaren können, wird die Terminanfrage in einem neuen Tab geöffnet.

Foren it-sa Expo Knowledge Forum A

Supply Chain Security für Software - wichtiger denn je

Kennen Sie die Sicherheitslücken in Ihrer Software Supply Chain? Oder vertrauen Sie darauf, bekannte CVEs zu finden?

calendar_today Mi, 26.10.2022, 10:00 - 10:15

event_available Vor Ort

Action Video

south_east

Actionbeschreibung

south_east

Speaker

south_east

Produkt

south_east

Themen

Trendthemen Awareness / Phishing / Fraud

Event

Diese Action ist Teil des Events Foren it-sa Expo

Action Video

close

Dieses Video steht der it-sa 365 Community zur Verfügung. 
Bitte registrieren Sie sich oder melden Sie sich mit Ihren Login-Daten an.

Actionbeschreibung


Zum Jahreswechsel 2021/2022 zeigte die in der Protokollbibliothek log4j gefundenen Schwachstellen eindrucksvoll auf, wie stark die Sicherheit von Anwendungen, Systemen, und Infrastrukturen von der Sicherheit der einzelnen Komponenten abhängt. Eine standardmäßig verwendete, weit verbreitete Open Source-Bibliothek für ein Randthema wie Protokollierung führte zu hektischen Patches und Updates großer Webservices und kritischer Unternehmensanwendungen. Mitarbeiter wurden aus dem Weihnachtsurlaub zurückgerufen, Anwendungen vorsorglich abgeschaltet. Die ersten Patches für log4j stellten sich als unzureichend heraus, und innerhalb kurzer Zeit musste erneut nachgebessert werden. Jede neue log4j-Version zog Updates der ausgerollten Anwendungen nach sich, und mit jedem Zwischenstand verblieben Angriffsmöglichkeiten.

Spätestens seit dieser Erfahrung steht das Thema Supply Chain Security weit oben auf der Agenda vieler Sicherheitsverantwortlicher. Dabei steht SBOM, der „Software Bill of Materials“, und damit die Frage, welche Bibliotheken und Komponenten überhaupt in der eigenen Software zum Einsatz kommen, am Anfang jeder Untersuchung. Eine solche Liste manuell von den Entwicklern pflegen zu lassen, ist in der Praxis nicht realistisch. Neu aufgenommene Open Source-Komponenten werden nicht nachgetragen, oder die Versionsstände im manuellen SBOM sind längst veraltet. Zudem steht in ein solcher manueller Dokumentationsaufwand einem agilen Entwicklungsprozess, der den Code in den Mittelpunkt stellt und auf den Code selbst als zentrale Informationsquelle setzt, im Wege. Lösen lässt sich dieses Problem nur durch Automatisierung. Während traditionelle Ansätze sich auf das Repository und damit den Entwickler fokussieren, bieten sie kaum Möglichkeiten für den Endverwender, die Abhängigkeiten eingekaufter Software zu prüfen. Mit einem Binärcodescanner lässt sich hingegen die ausgeführte Datei prüfen, ohne Zugriff auf den Quellcode oder die Entwicklungsumgebung zu benötigen. Dies ermöglicht eine eigene Kontrolle der Abhängigkeiten, ohne rein auf die Angaben des Herstellers vertrauen zu müssen.

Selbst wenn alle Komponenten bekannt sind, und für keine dieser Komponenten eine Schwachstelle öffentlich bekannt ist, indem z.B. eine CVE-Nummer existiert, bedeutet dies keine Sicherheit. Die Sicherheitslücke in log4j war jahrelang unentdeckt vorhanden, obwohl die Bibliothek vielfach verwendet wurde und als Open Source-Projekt für Jedermann zur Einsicht bereitstand. Dieses Beispiel zeigt einerseits, dass auch populären Open Source-Komponenten unerkannt verwundbar sein können, d.h. ein Community-basierter Prüf- und Korrekturprozess ist auch hier trotz Quelloffenheit nicht hundertprozentig gegeben. Andererseits zeigt das Beispiel, dass CVE-Nummern lediglich Schwachstellen abbilden, die bereits bekannt sind, also eine Reaktion ggf. erst zu spät ermöglichen. Ist die Schwachstelle bekannt, sind gemeinhin auch Exploits dafür bekannt.

Um dieses Problem zu lösen, können Codescanner erneut einen wichtigen Beitrag leisten. Mit einem Binärcodescanner wird die final ausgeführte Software geprüft, einschließlich aller Abhängigkeiten. Unabhängig davon, ob eine Codezeile ursprünglich aus einer Bibliothek stammt oder aus dem primären Anwendungscode, ist sie ein Bestandteil der finalen Software, der finalen Installations- oder Ausführungsdatei, und kann somit von einem Binärcodescanner begutachtet werden. Durch den Binärcodescan verschwindet die Unterscheidung zwischen Programm und Bibliothek, und Fehler in den Bibliotheken werden genauso sichtbar wie Fehler im Programm selbst, da der Code als Einheit geprüft wird. Auf diesem Prinzip beruht der Tiefenscan unseres VUSC-Scanners für Java-(Enterprise) Anwendungen, Spring Boot Webanwendungen, Android Apps, und anderen Plattformen.

... mehr lesen

Sprache: Deutsch

Action beinhaltet Q&A: Nein

Speaker

Mehr anzeigen

Produkte

close

Diese Inhalte oder Funktionen stehen der it-sa 365 Community zur Verfügung. 
Bitte registrieren Sie sich oder melden Sie sich mit Ihren Login-Daten an.