Vom Sicherheitsanbieter Veracode wurde im Juni 2021 der State of Software Security (SoSS) v11: Open Source Edition-Report veröffentlicht. Dieser deckt auf, wie es aktuell um die Sicherheit von Open Source Software steht. Während der Untersuchung wurde festgestellt, dass 80 Prozent der Bibliotheken von Drittanbietern nach der Aufnahme in eine Codebasis von den Entwicklern nie aktualisiert werden. Außerdem enthalten fast alle Repositories Bibliotheken mit mindestens einer Sicherheitslücke. Keine guten Aussichten.
Anzeige
Der neue State of Software Security (SoSS) v11: Open Source Edition Report von Veracode (Download erfordert Anmeldung) zeigt, dass fast 80 Prozent der Bibliotheken von Drittanbietern nach der Aufnahme in eine Codebasis von den Entwicklern nie aktualisiert werden – trotz der Tatsache, dass mehr als zwei Drittel der Fehlerbehebungen geringfügig sind und die Funktionalität selbst der komplexesten Softwareanwendungen nicht beeinträchtigen.
Open-Source-Bibliotheken entwickeln sich ständig weiter. Was heute noch sicher erscheint, kann es morgen schon nicht mehr sein und ein erhebliches Risiko für Software-Anbieter und Anwender darstellen. Verarcode hat für den Report 13 Millionen Scans von mehr als 86.000 Repositories mit mehr als 301.000 einzigartigen Bibliotheken analysiert und außerdem fast 2.000 Entwickler befragt, um zu verstehen, wie sie Software von Drittanbietern verwenden.
Der Report zeigt im Jahresvergleich bemerkenswerte Schwankungen in der Beliebtheit und Anfälligkeit von Bibliotheken auf. So waren beispielsweise vier der fünf beliebtesten Bibliotheken in Ruby des Jahres 2019 im Jahr 2020 nicht mehr in den Top 10, während sich einige der anfälligsten Bibliotheken in Go des Jahres 2019 im Jahr 2020 als weniger angreifbar erwiesen und umgekehrt.
Da fast alle modernen Anwendungen mit Open-Source-Software von Drittanbietern erstellt werden, kann sich ein einziger Fehler oder eine Anpassung in einer Bibliothek kaskadenartig auf alle Anwendungen auswirken, die diesen Code verwenden. Das bedeutet, dass diese ständigen Änderungen einen direkten Einfluss auf die Softwaresicherheit haben.
Anzeige
Fast alle Repositories enthalten Bibliotheken mit mindestens einer Sicherheitslücke. „Die große Mehrheit der heutigen Anwendungen verwendet Open-Source-Code", kommentiert Chris Eng, Chief Research Officer bei Veracode. „Die Sicherheit einer Bibliothek kann sich schnell ändern. Daher ist es wichtig, eine aktuelle Bestandsaufnahme der in der Anwendung enthaltenen Bibliotheken zu machen. Wir haben festgestellt, dass Entwickler, die sich einmal für eine Bibliothek entschieden haben, diese nur selten aktualisieren.
Angesichts der Tatsache, dass Anbieter zunehmend mit Fragen nach der Sicherheit ihrer Lieferkette konfrontiert werden, lässt sich eine „Einstellen und Vergessen"-Mentalität jedoch nicht länger rechtfertigen. Es ist wichtig, dass Entwickler diese Komponenten auf dem neuesten Stand halten und schnell auf neue Schwachstellen reagieren, sobald diese entdeckt werden."
Die Entwicklung sicherer Anwendungen mit Open-Source-Code muss nicht anstrengend sein
Trotz der dynamischen Natur der Software-Landschaft aktualisieren Entwickler Open-Source-Bibliotheken häufig nicht mehr, wenn sie diese erst einmal in Software-Anwendungen eingebunden haben. Hinderlich kann hier ein mangelndes kontextbezogenes Verständnis dafür sein, wie eine anfällige Bibliothek mit ihrer Anwendung zusammenhängt. Entwickler, die angeben, dass ihnen diese Informationen fehlen, benötigen beispielsweise mehr als sieben Monate, um 50 Prozent der Schwachstellen zu beheben.
Dies verkürzt sich jedoch drastisch auf drei Wochen, wenn ihnen die richtigen Informationen und Hilfestellungen zur Verfügung stehen. Außerdem können sie schnell reagieren, wenn sie auf eine anfällige Bibliothek aufmerksam gemacht werden: 17 Prozent der Schwachstellen werden innerhalb einer Stunde behoben und 25 Prozent innerhalb einer Woche. Wenn sie also rechtzeitig mit genauen Informationen versorgt werden, können Entwickler die Sicherheit angemessen priorisieren und Schwachstellen schnell beheben.
Weitere wichtige Ergebnisse:
- 92 Prozent der Fehler in Open-Source-Bibliotheken können mit einem Update behoben werden und 69 Prozent der Updates bedeuten nur eine kleine oder kaum merkliche Versionsänderung.
- Selbst wenn ein Update einer Open-Source-Bibliothek weitere nach sich zieht, bestehen fast zwei Drittel davon nur aus kleinen Versionsänderungen und es ist unwahrscheinlich, dass sie selbst bei den komplexesten Anwendungen die Funktionalität beeinträchtigen.
- Nur 52 Prozent der befragten Entwickler verfolgen einen formalen Prozess bei der Auswahl von Bibliotheken von Drittanbietern. Gleichzeitig sind mehr als ein Viertel entweder unsicher – oder wissen erst gar nicht –, ob es einen formalen Prozess gibt.
- „Sicherheit" steht bei der Auswahl einer Bibliothek nur an dritter Stelle, während „Funktionalität" und „Lizenzierung" an erster bzw. zweiter Stelle stehen.
Sicherung der Software-Lieferkette rückt in den Fokus des Weißen Hauses
Erst im vergangenen Monat hat das Weiße Haus eine „Executive Order on Cybersecurity" veröffentlicht, die sich zu fast 25 Prozent auf die Sicherung der Software-Lieferkette konzentriert. Künftig müssen Software-Anbieter, die an die US-Regierung verkaufen, die Zusammensetzung ihrer Software offenlegen und sicherstellen, dass die Software-Anwendungen automatisierte Tests durchlaufen haben.
„Im Zuge der Umsetzung der Executive Order sollte jeder, der Software entwickelt, sicherstellen, dass er seine Software früh und oft im Entwicklungszyklus überprüft", ergänzt Chris Wysopal, Mitbegründer und Chief Technology Officer bei Veracode. „Die wachsende Popularität von Open-Source-Software in Kombination mit immer anspruchsvolleren Entwicklungszyklen führt zu einer höheren Wahrscheinlichkeit von Software-Schwachstellen. Indem man früher im Prozess scannt, reduziert man das Risikoprofil erheblich. Außerdem sind die meisten Fehlerbehebungen geringfügig und beeinträchtigen die Funktionalität selbst der komplexesten Software nicht."
Anzeige
So viel zu der Aussage, Open-Source generell wäre sicher.
Die Aussage gab es nie, weil sie so unsinnig ist. Wenn man überhaupt so weit geht, dann sicherer vor absolut offensichtlichen Hintertüren.
Die Prämisse war:
Du kannst reinsehen und wenn du einen Fehler findest kannst du ein Pull-Request aufmachen. Tun Firmen aber selten, weil das würde ja Geld kosten fremde Projekte zu pflegen, die man mit vollster Gratismentalität nutzt.
Also wird wie eine Heuschrecke von Bibliothek A zu B zu C gesprungen.
Positive Ausnahme: Firmen wie Red Hat.
https://en.wikipedia.org/wiki/Red_Hat#Programs_and_projects
Schon richtig, wer halbwegs intelligent ist, weiß das. Aber hier, aber vor allem b ei Heise, Golem und Co fallen immer wieder egelmäßig Schwärme von Linux-Jehovaisten und Diagonaldenkern ein, die das Gegenteil behaupten. Open-Source ist nicht per Se sicherer, nur weil man den Quellcode einsehen KANN. Man muss es auch tun, was hiermit und mit beinahe täglich, manchmal auch mehrfach täglich, einer Sicherheitswarnungs-Email vom BSI-Cert eindrucksvoll bewiesen wird.
Dass Open Source generell sicherer wäre, kann man so allgemein sicher nicht sagen. Was Open Source aber sicherer macht, ist, dass so eine Studie bei Closed Source Software gar nicht möglich ist. Hier wissen wir einfach nicht, wie viele der Closed Source-Bibliotheken nie aktualisiert werden.
Hier würde ich eher sagen, dass Open-Source funktioniert hat.
Man konnte in den Code reischauen und das Problem genau adressieren.
Genau das ist der Vorteil von Open-Source. Bei Closed-Source geht eben genau Das nicht. Soweit ist schon zu sagen, dass Open-Source vom Prinzip her bessere Sicherheit bietet. Gegen lustlose Programmierer hilft das natürlich auch nicht, jedoch findet man Fehler dort vom Prinzip her eben schneller.
Zu guter Letzt ist natürlich klar, absolute Sicherheit findet man nirgendwo.
Nein, die Studie zeigt, dass es TROTZ angeblich bester Vorraussetzungen eben NICHT funktioniert.
Die Interprätation einer Studie kann zu anderen Ergebnissen führen, je nachdem was man als Basis nimmt. Wie würde wohl eine Studie zu Closed-Source ausfallen? …
… Nur mal so dahingestellt. Wie viel Quellcode zu Windows wird über Generationen des OS mitgeschleppt und erst Jahre später werden durch Zufall Sicherheitslücken gefunden? Closed-Source funktioniert noch weniger weil man eben nicht die Chance hat in den Code zu sehen.
Vorallem stellt sich die Frage wie viele Closed Source Anwendungen eigentliche Open Source Quelltexte einkompilieren, auf die Lizenzbedingungen schei****, auch nichts aktualisieren und daher genau so anfällig sind, aber ohne das man es je merken würde (worst case -> virusinfektion mal ausgeschlossen)
Ich sehen das genauso wie 1ST1. Open Source ist für mich sogar anfälliger…
Deine Aussage ist kompletter Unsinn, weil sie total am Thema vorbei geht.
Was kann denn Open Source bzw. der Entwickler der Bibliothek dafür, dass Entwickler, die seine Bibliothek im eigenen Projekt einpflanzen, nie aktualisieren?
Der Report zeigt lediglich, dass viele Entwickler sehr schlampig arbeiten, was die Sicherheit angeht. Zu Open Source zeigen sie das Gegenteil, nämlich dass hier nachgebessert wird und die Sicherheit gegeben ist. Nur eben, dass diese Nachbesserungen in weiteren Verwertungskette nicht immer berücksichtigt werden.
Nebenbei bemerkt wird niemand behaupten, das Open Source sicherer ist. Es ist nur so, dass Fehler und Lücken wahrscheinlich schneller gefunden und geschlossen werden. Bei Closed Source können Lücken Jahrzehnte bestehen. MS demonstriert das regelmäßig aufs Neue. Open Source ist v.a. eins: VERTAUENSWÜRDIGER.
Sicher, sicherer, am sichersten?
Entscheidend ist doch wie und wie schnell man mit den Schwachstellen umgeht.
Bin mit Debian unterwegs und bin gespannt wie die Resonanz ist.
curius.de/2021/07/baustelle-linux-sicherheit-rpm-unzulaenglich/
"Der Vorfall passt in eine Reihe von Problemen und Beobachtungen. Linux-Anwender und Linux-Entwickler sind in den letzten Jahren oft in eine Haltung bräsiger Selbstzufriedenheit verfallen. Probleme mit Sicherheit hatten schließlich immer nur die anderen."
Das sitzt, "bräsige Selbstzufriedenheit"! ;-)
BSD läuft live vom Stick nebenbei, aber auch da gibt`s Schwachstellen.
>Angreifer können dieses Problem ausnutzen, um mit abgelaufenen oder zurückgezogenen Schlüsseln schädliche Pakete zu signieren und zur Installation verwenden.
>
Dazu muss ein Schlüssel überhaupt erstmal gestohlen werden. Ein abgelaufener Schlüssel bedeutet auch nicht, dass keine Sicherheit mehr gegeben ist. Der Grund warum man Schlüssel wechselt ist allein die Annahme, dass man irgendwann mit extremer Leistung die Primzahlen des Schlüssels faktorisieren könnte.
Einen zurückgezogenen Schlüssel gäbe es auch erst maximal nach einem Diebstahl.
Ja es ist ein Problem, genau wie ein defekter Airbag. Aber der Schadensfall ist zum Glück nicht eingetreten.
Da war Curveball/Chain of Fools schlimmer:
https://twitter.com/sophoslabs/status/1222935139107397639
Es gab PoCs wo Sicherheitsforscher jede beliebige EXE signieren konnten.
Microsoft selbst hat sogar rootkits signiert:
https://arstechnica.com/gadgets/2021/06/microsoft-digitally-signs-malicious-rootkit-driver/
Aber gut mei RPM-Lückchen ;)
>Das sitzt, „bräsige Selbstzufriedenheit"! ;-)
>
Nutze Windows und Linux und beide bekleckern sich nicht mit Ruhm. Wichtig ist es ein gutes Gedächtnis zu haben für Internet-Argumente. Schönen WE, Genosse!
Teilweise 7-10 Jahre offene Sichderheitslücken in diversen Bestandteilen des Linux-Basis-Systems wie Kernel und wichtiger Dienste (OpenSSH, OpenVPN, Samba, (g)libc, …) zeigt, dass es eben so nicht ist. „bräsige Selbstzufriedenheit" trifft es ganz gut, hier verlässt sich nämlich einer auf den anderen, der Quellcode ist ja einsehbar, also wird es sich IRGENDWER ja schon IRGENDWANN mal ansehen… Daher muss ICH das ja nicht tun.
Audits kosten Zeit und Geld. Microsoft hat beides.
Warum werden also immer noch Lücken in Windows gefunden?
Weil jemand gratis nachgesehen hat. Wäre Linux auf mehr PCs würden da auch mehr Forscher draufsehen.
>„bräsige Selbstzufriedenheit"
Das ist Mobbing, ich weine in mein Club Mate :(
Und wieviel Prozent des veröffentlichten Closed Code wird jemals aktualisiert? Da sieht es genauso düster aus!
Zumindestens Microsoft veranstaltet einmal im Monat einen sicherheitsrelevanten Patchday, auch diverse andere Hersteller wie Adobe folgen diesem Beispiel. Das Problem ist nur, dass man viele Softwareupdates für Anwendungen anderer Hersteller unter Windows als normaler Anwender eher nicht mit bekommt, weil die Software selbst so einen Mechanismus nkicht hat und/oder weil Windows bisher keinen Mechanismus für Software von Drittherstellern hatte, leider wird es MS auch in Windows 11 mit dem neuen Store nicht schaffen, EXE-Software, die sogar im Store heruntergeladen werden kann, über den Store zu aktualisieren. winget (eine Adaption von apt-get auf Windows, von Micrsoft über Github bereit gestellt) kann das ändern, aber momentan muss man es noch manuell installieren, und man muss erstmal auf die Idee kommen, einen z.B. wöchentlichen "winget upgrade –all –silent" Job in die Aufgabenplanung einzustellen. Hab ich bei mir privat gemacht, und es deckt aber bisher auch nur einen Bruchteil der Software ab, die installiert ist, weil die Softwarehersteller dem Winget Repository neue Versionen noch nicht hinzufügen.
Was hier außer acht gelassen wird, ist dass OpenSource-Content in ClosedSource-Content eingebaut wird und dann dort auch nie aktualisiert wird. Meldungen dieser Art gab es in den letzten Jahren zu hauf.
Im Prinzip zeigt dies doch nur die fehlende Bereitschaft, Content anderer im eigenen Content regelmäßig zu überprüfen und aktuell zu halten, unabhängig davon ob es sich um OpenSource oder ClosedSource handelt.
Es müsste eigentlich einen Code of Conduct für jegliche Art der Softwareentwicklung geben, aber wer überwacht die Einhaltung?
Mindestens einer hat den Artikel gelesen und verstanden – Danke!
Pfff nur weil so gut sind das sie nie aktualisiert werden müssen :)
Spaß beiseite hätte man eine Lücke gefunden, hatte man die entsprechende Bibliothek warscheinlich auch aktualisiert. Das heißt nicht das da keine Lücken waren. Aber wenn man sie finden würde müsste man nicht erst auf den Hersteller warten, sondern könnte sie unter Umständen sogar selber beheben. Das ist und bleibt der große Vorteil bei OpenSource. Aber ja wenn ich den typischen Linuxer mit seinem mit Linux wäre das nicht passiert höre könnt ich schon auch kotzen!
Wenn das ja so einfach wäre. Lasse 10 erfahrene Softwareentwickler über den selben Code kritisch drüberschauen, du wirst 10 verschiedene Ergebnisse bekommen. Es findet nämllich nicht jeder alle Fehler.
Sehe ich sogar ebenfalls als Vorteil für OpenSource, denn bei vielen Herstellern werden keine 10 Entwickler über den gleichen Code schauen. Und der eine der ihn erstellt hat wird den Fehler einfach nicht sehen, denn oftmals sieht man was da sein sollte und nicht was da ist. Kennt man doch selbst von simplen Textdokumenten!
Ich halte den Report ein bisschen für Effekthascherei – Lesart sowie Aufmachung entsprechen eher einer Werbebroschüre, die zudem noch die Daten potentieller Kunden beim Abruf einsammelt.
Bei der Zusammenfassung der Methodik sehe ich auch nicht durch:
Was haben die eigentlich gescannt/ausgewertet?
Die sprechen lediglich von "Applikationen die unsere Kunden übermittelt haben".
Wie viele der OSS-Projekte sind denn Kunden von denen – ich nehme mal an VeraCode arbeitet nicht umsonst? Oder haben die zuhauf Closed-Source Projekte gescannt, die gegen alte OSS Bibliotheken linken?
Veraltete Bibliotheken sind unzweifelhaft ein Problem, und es mag auch sein, dass die Abhängigkeiten in diversen Repositories nicht aktualisiert werden, nur:
Wie viel Opensource hat überhaupt statische Abhängigkeiten drin? Heutzutage läuft doch viel über Git Remotes und binär wird dynamisch gelinkt. Das ist dann eher ein Paketierungsproblem.
Bei so ziemlich allen Linux-Distributionen die ich kenne werden die Bibliotheken der Distri verwendet, und nicht gegen irgendwelchen statischen Kram gelinkt -> nicht betroffen, Sicherheitsaktualisierungen automatisch.
Ein Problem sehe ich definitiv bei Windows-Versionen der Software, die wird dann mit dem alten Kram gebaut. Da sollte man dann schon den Finger drauf legen.
Oftmals liefern Windows Programme dann gleich noch die alten Versionen im eigenen Programmverzeichnis mit, so das es auch ja nichts hilft wenn man die Redistributables aktuell hält!