Du bist seit mehr als 30 Jahren als Open Source Experte bekannt. Warum würdest du niemals deine Steuererklärung oder Familienfotos bei Microsoft und Co. speichern?

Ich möchte grundsätzlich keine persönlichen Daten aus der Hand geben, auch nicht „nur“ die sensiblen, sondern gar keine. Zu oft werden Daten gesammelt, um Geld damit zu verdienen: als Grundlage für KI-Training oder für Werbung und Analysen. Und was einmal draußen ist, lässt sich nicht verlässlich zurückholen.

Gerade wenn sich gesellschaftliche und politische Werte verschieben, will ich nicht riskieren, dass irgendwann eine Regierung mehr über mich weiß als nötig.

Private Kommunikation ist kein Verbrechen, sondern ein Bürgerrecht. Open-Source-Software hilft dabei, Daten unabhängig und kontrollierbar zu halten.

Offenheit erhöht die Angriffsfläche theoretisch. Wie stellst du sicher, dass Offenheit tatsächlich zu mehr Sicherheit führt und nicht zu neuen Bedrohungen?

Offenheit kann auf den ersten Blick wie ein Risiko wirken: Auch Angreifende können Code analysieren. Aber Schwachstellen gibt es in jeder Software, offen wie geschlossen. Entscheidend ist deshalb nicht Verbergen, sondern Finden und Beheben. Und dafür ist eine offene Kultur besser geeignet: Viele unabhängige Leute können die Software beurteilen und auf Fehler hinweisen, damit sie schnell behoben werden.

Wenn offen liegt, wie eine Software entwickelt wird und verschiedenste Personen beitragen können, den Prozess zu verbessern, sorgt das auch für mehr Qualität.

Beispiele dafür, die in der Open-Source-Entwicklung heute Standard sind: Code Reviews, aufwändige CI/CD-Pipelines, automatische Builds und Tests. Natürlich gibt es das auch in geschlossener Entwicklung, aber häufig in einem „geschlossenen Raum“, in dem man die Reviewer kennt und selten völlig neue Perspektiven dazukommen.

Angriffe wie das Einschleusen von Schadcode werden häufig rasch entdeckt. Bei proprietärer Software fehlt diese unabhängige Überprüfbarkeit, man weiß schlicht weniger.

Der „Coordinated Vulnerability Disclosure“-Prozess klingt gut auf dem Papier. Was ist das in deiner Praxis?

Der Prozess stellt die Sicherheit der Anwendenden in den Mittelpunkt. Wird eine Schwachstelle gefunden, informiert der Finder den „Hersteller“ im Regelfall vertraulich und setzt eine Frist, innerhalb derer der Hersteller einen Fix ausarbeitet und bereitstellt. Üblicherweise verständigt man sich darauf, das Problem erst dann öffentlich zu machen, wenn das Update verfügbar ist, damit die Anwendenden geschützt sind.

Manchmal betrifft ein Problem nicht nur einen Hersteller, sondern mehrere Firmen, die eine Komponente gemeinsam maintainen. Das müssen nicht unbedingt "befreundete Firmen" sein. Dann wird es komplizierter, denn auch dann muss gemeinsam agiert werden.

Auch in solchen Fällen einigt man sich auf Vorgehen und Termine, zum Beispiel darauf, wann ein sogenanntes Public Disclosure erfolgt.

So wird das in der Praxis gelebt. Es ist ein Versprechen, das wir unseren Kunden geben: Wir tun alles, um sie vor Schäden durch solche Probleme zu schützen.

Ihr teilt Informationen über Sicherheitslücken auch mit Konkurrenten im Open Source Bereich, kann das nicht auch Risiken bergen? Wie minimiert ihr das Risiko?

„Coordinated Disclosure“ ist eine seit Langem etablierte, wenn auch oft nicht-formale Vereinbarung, die genau solche Risiken minimieren soll. Der Sinn ist, dass alle betroffenen Stellen diskret informiert werden, Fixes vorbereiten können und dann koordiniert zu einem bestimmten Zeitpunkt veröffentlicht wird. Ziel ist die sicherste Behandlung des Problems für die User.

Wer sich als Maintainer diesem Prozedere entzieht, zeigt damit, dass er kein verlässlicher (Geschäfts-)Partner im Open-Source-Ökosystem ist. Diese Dinge sprechen sich schnell herum und bleiben im Gedächtnis haften.

In meinem Einflussbereich würde ich immer sicherstellen, dass solche Vereinbarungen unmissverständlich getroffen und penibel eingehalten werden – weil es neben der Seriosität der Firma und der Sicherheit der Nutzenden auch um die Verlässlichkeit der Open-Source-Szene insgesamt geht.

Warum werden denn Sicherheitslücken überhaupt veröffentlicht?

Sie sind durch den Open Source-Charakter ohnehin öffentlich, daher könnte man sie gar nicht unter den Teppich kehren. Aber viel mehr fördert das Vorgehen die Transparenz, die das Vertrauen aller Nutzenden in ein Projekt und die Art zu entwickeln steigert.

Wie gehst du mit der Kritik um, dass FOSS-Sicherheitsprozesse zu fragmentiert und inkonsistent sein könnten, wenn unterschiedliche Projekte auf dieselben Komponenten setzen?

Angesichts des oben geschilderten koordinierten Vorgehens könnte ich so einen Vorwurf nur schwer nachvollziehen. Zusätzlich gibt es übergeordnete Stellen, die zum Beispiel eindeutige Nummern für Sicherheitsprobleme vergeben, damit sie für alle besser nachvollziehbar und sauber referenzierbar sind.

Wenn Open Source so sicher ist, wie kann es sein, dass es zuletzt einen massiven Sicherheitsvorfall bei der OSS lib XZ gab?

Das war ein interessanter Fall, der nicht nur die Open Source-Szene erschüttert hat, sondern die gesamte IT-Welt. Die Mechanismen, über die der Angriff ausgeführt wurde, haben auf menschlicher Interaktion basiert. Das kann genauso in geschlossenen Umgebungen passieren.

Es zeigt eigentlich nur, dass das Thema Security nicht ernst genug genommen werden kann, und dass vor allem im "Social Engineering" immer wieder Angriffe möglich sind. Hier braucht es Wachsamkeit, klare Prozesse und ein konsequentes Mehr-Augen-Prinzip.

Und man muss auch fragen: Wie wäre ein Closed-Source-Anbieter mit so einem Vorfall umgegangen? Hätten wir überhaupt davon erfahren und hätten wir als Branche die Chance gehabt, daraus zu lernen?

Glaubst du, dass der Sicherheitsvorteil von Open Source-Software langfristig immer bestehen bleibt, oder kann Closed Source-Software durch moderne Methoden wie AI-Sicherheitsanalyse aufholen?

Ich bin eigentlich überzeugt, dass auch in der Closed Source-Welt in den meisten Fällen sehr verantwortungsbewusst mit dem Thema umgegangen wird und auch technische Hilfsmittel entsprechend eingesetzt werden. Aber wir können es nur sehr schwer überprüfen.

Oft wird auch kritisiert, dass Open Source nicht für jede Person nachvollziehbar ist. Das stimmt, aber es ist möglich, den Code von unabhängigen Expert:innen prüfen zu lassen. Und das passiert auch regelmäßig. Bei Closed Source ist genau diese unabhängige Prüfung oft eingeschränkt oder gar nicht möglich.

Bei Open Source kann man Sicherheit im Zweifel verifizieren, bei Closed Source muss man sie glauben. Und dieser feine Unterschied wird sich auch durch AI nicht überwinden lassen.