Es gibt - und wird immer geben - Schwachstellen in Software. So wie es keine perfekte Sicherheit gibt, gibt es auch keine perfekte Codebasis. Das wirft die Frage auf: Wie lassen sich Softwareprobleme am besten beheben, vor allem in großem Maßstab? Wie so oft, wenn es um Sicherheitsfragen geht, lautet die Antwort: "Das kommt darauf an."

Gute Bugs, böse Bugs?

Open-Source-Software erlaubt es jedem - im Guten wie im Schlechten -, einen Blick unter die Haube zu werfen und hoffentlich Sicherheits- oder Funktionsprobleme zu beheben. Aber sie können auch Hintertüren einführen, die manchmal jahrelang unbemerkt bleiben, so eine Studie aus dem Jahr 2022, die auf dem 31. USENIX Security Symposium veröffentlicht wurde.

Closed-Source-Software hingegen verlässt sich auf die Geheimhaltung ihres Quellcodes und das Fachwissen ihrer eigenen Softwareentwickler, eine Art "interner Geheimsoße", die hoffentlich gut von Sicherheitsexperten wird, deren Fachwissen zumindest gut genug ist, um Kunden zu binden und im Geschäft zu bleiben. Unabhängig davon, ob sie ihren Quellcode zur Verfügung stellen oder nicht, können Entwickler von Dokumenten wie den OWASP Top Ten und den SEI CERT Coding Standards profitieren, die die Entwicklung von sicheren Code-Praktiken fördern.

Obwohl die Wurzeln von Open-Source-Software bis in die 1950er Jahre zurückreichen, wurde Software in den Vereinigten Staaten erst in den frühen 1980er Jahren als urheberrechtsfähig eingestuft. Dies hatte unter anderem zur Folge, dass viele Anbieter, die zuvor den Quellcode als Teil ihrer Produkte lieferten, dies nicht mehr taten. In den 1980er Jahren und bis in die 2000er Jahre hinein sahen einige Softwareunternehmen wie Microsoft Open-Source-Software als eine Art existenzielle Bedrohung für ihr Geschäft an, bevor sie sich in den 2010er Jahren darauf einließen.

Heute fördert Big Tech zunehmend die öffentlich-private Zusammenarbeit bei der Sicherheit von Open-Source-Software, was so weit geht, dass das Weiße Haus im Jahr 2022 ein Gipfeltreffen zur Sicherheit von Open-Source-Software abhielt, möglicherweise ausgelöst durch die weit verbreitete Ausnutzung von Schwachstellen in Open-Source-Software. Während ich diesen Artikel schrieb, kündigte die CISA die Veröffentlichung ihrer Sicherheits-Roadmap für Open-Source-Software an und unterstrich damit sowohl ihre Anerkennung der Bedeutung, die Open-Source-Software im Technologie-Ökosystem hat, als auch ihr Engagement, zu deren Sicherheit beizutragen.

Unternehmen, die Closed-Source-Software vertreiben, können auch jemanden damit beauftragen, die Software zu aktualisieren, sobald Probleme auftauchen. Open-Source-Software ist im Allgemeinen mehr auf eine Schar von Freiwilligen angewiesen, die sich beteiligen und Probleme beheben, sobald sie auftauchen - eine Eigenschaft, die als Linus' Gesetz bekannt ist: "Wenn es genug Augen gibt, sind alle Fehler augenscheinlich". Aber da Freiwillige schwer zu gewinnen sind, ist es schwieriger, sie zu zwingen, die tägliche Arbeit der rechtzeitigen Fehlerbehebung zu erledigen - der Teil der Sicherheit, der nicht gerade fancy ist - und Updates können sich verzögern. Das könnte sich jedoch ändern: Bug-Bounty-Programme, die von Google und Huntr angeboten werden, sind eine Möglichkeit, das Auffinden und Beheben von Schwachstellen in Open-Source-Software zu Geld zu machen.

Die Realität moderner Software liegt irgendwo dazwischen, denn viele Closed-Source-Projekte stützen sich in hohem Maße auf Open-Source-Software, um die Grundlagen zu schaffen, bevor sie ihre "geheime Soße" darüber legen. Es ist zum Beispiel sinnvoll, eine E-Mail-Anwendung nicht von Grund auf neu zu entwickeln, um administrative Benachrichtigungen zu erledigen: Es gibt gut getestete Open-Source-Projekte, die das problemlos erledigen können.

Einige eher Open-Source-orientierte Unternehmen tragen dagegen aktiv zu Open-Source-Softwareprojekten bei, die sie für wichtig halten, und da sie kommerzielle Kunden haben, können sie aufgrund ihrer kommerziellen Einnahmen jemanden einstellen, dessen Aufgabe es ist, Fehler zu beheben.

Aber dieses seltsame Zusammenspiel von Kräften kann immer noch Probleme wie die Log4j-Schwachstellen ermöglichen, die die Infrastruktur untergraben und vielleicht immer noch eine Hintertür bieten, unabhängig davon, ob der gesamte Stack, den Sie als Produkt verwenden, offen, geschlossen oder höchstwahrscheinlich etwas dazwischen ist.

Ein Nebeneffekt von Open-Source-Software ist, dass sie ganzen Communities, die sicher agieren wollen, wie z. B. bei Kommunikationssoftware, auf die Sprünge hilft, da sie nicht alles von Grund auf neu entwickeln müssen, um die Kryptografie richtig hinzubekommen.

Das ist es, was einige der populärsten Softwareprojekte zum Schutz der Privatsphäre in der Welt tun, wie Proton und Signal, die beide einen soliden Ruf und eine lange Geschichte haben, wenn es darum geht, Dinge privat und sicher zu halten.

Die Autoren von Signal laden jeden ein, ihren Code zu überprüfen, und da die persönliche Nachrichtenübermittlung eine so wichtige Funktion für die Gesellschaft ist, konzentrieren sich Scharen von Sicherheitsfachleuten genau darauf, denn eine Schwachstelle oder eine kryptografische Schwäche kann so weitreichende Folgen haben.

EBENFALLS INTERESSANT: BadBazaar: Android-Spyware durch trojanisierte Signal und Telegram Apps

Das in der Schweiz ansässige Unternehmen Proton hat seine Anfänge im Bereich der supersicheren E-Mail gemacht und sich dann auf eine Reihe anderer Dienste zum Schutz der Benutzeridentität ausgedehnt - eine weitere enorm wichtige Funktion für die Gesellschaft, die im Falle eines Fehlers schwerwiegende Folgen hat.

Damit Sie nicht denken, dass Closed-Source-Software eine bessere Erfolgsbilanz hat: Selbst die am weitesten verbreitete Closed-Source-Software der Welt kann über Jahre, wenn nicht Jahrzehnte, Schwachstellen aufweisen. Nehmen Sie CVE-2019-0859. Bei dieser von Kaspersky Lab entdeckten Sicherheitslücke handelt es sich um eine Use-after-free-Schwachstelle, die in Microsoft Windows-Betriebssystemen aus zehn Jahren gefunden wurde, von Windows 7 über Windows 8 und Windows 8.1 bis hin zu Windows 10 auf der Desktop-Seite und den Windows Server-Versionen 2008 R2, 2012, 2012 R2, 2016 und 2019.

Der Teufel steckt im Detail

Die Wahrheit ist, dass weder Open-Source- noch Closed-Source-Software von Natur aus sicherer ist als die andere. Was zählt, ist der Prozess, in dem Software entwickelt und Schwachstellen behoben werden. Die Zuverlässigkeit dieser Korrekturen und die Geschwindigkeit, mit der sie implementiert werden können, sind das, worauf sich Unternehmen bei der Festlegung ihres Sicherheitsstatus konzentrieren sollten - nicht die Art der Softwarelizenz.

Letzten Endes kommt es darauf an, wie sehr das Unternehmen auf die breitere Sicherheitsgemeinschaft eingeht. ESET beispielsweise leistet einen wichtigen Beitrag zum MITRE ATT&CK®-Framework und stellt viele andere Sicherheitstools zur Verfügung, die oft kostenlos oder als Open Source erhältlich sind.

In der hybriden Welt der Software, die fast immer eine Mischung aus Open- und Closed-Source-Software ist, wird dies zum Lackmustest: ob das Unternehmen oder die Organisation offen für Vorschläge und Beiträge ist und ob es in die Sicherheitsgemeinschaft reinvestiert. Und auch wenn die perfekte Sicherheit schwer zu erreichen sein wird, können großartige Teams mit einem guten Ruf sicherlich helfen.