Cal.com wechselt wegen KI-Sicherheitsbedrohungen von Open Source zu Closed Source

• Cal.com, das fünf Jahre lang als Open Source betrieben wurde, hat aufgrund der zunehmenden KI-basierten Sicherheitsbedrohungen entschieden, auf Closed Source umzusteigen
• Mit dem Beginn eines Zeitalters, in dem KI Codebasen automatisch analysiert und Schwachstellen findet, wird öffentlich zugänglicher Code zu einem direkten Hinweis für Angreifer
• Das Unternehmen entschied sich zum Schutz der Kundendaten gegen Open Source und für die Minimierung des Sicherheitsrisikos
• Um den Open-Source-Gedanken fortzuführen, wurde das Projekt Cal.diy unter der MIT-Lizenz veröffentlicht und eine selbst hostbare Community-Version bereitgestellt
• Da sich KI mit einer Geschwindigkeit entwickelt, die bestehende Sicherheitsmechanismen überrollt, erklärt Cal.com seine Absicht, nach einer Stabilisierung der Sicherheitslage zu Open Source zurückzukehren

---

Cal.coms Entscheidung zum Ende von Open Source und die KI-Sicherheitsbedrohung

• Cal.com wurde fünf Jahre lang als Open Source betrieben, hat sich aber wegen des starken Anstiegs KI-basierter Sicherheitsbedrohungen für einen Wechsel zu Closed Source entschieden
  • Der Schutz von Kundendaten hat oberste Priorität, und das Unternehmen kam zu dem Schluss, dass die Beibehaltung von Open Source nicht länger sicher ist
  • Man erklärte, es sei „keine leichte Entscheidung“ gewesen
• Früher erforderte das Ausnutzen von Anwendungsschwachstellen Zeit und Aufwand durch erfahrene Hacker, doch nun hat sich die Lage zu einem Zeitalter gewandelt, in dem KI Codebasen automatisch scannt und Schwachstellen findet
  • Open-Source-Code sei für Angreifer „wie die Baupläne eines Tresors bereitzustellen“
  • Da KI-Sicherheits-Startups diese Fähigkeit kommerzialisieren, erkennen sie jeweils unterschiedliche Schwachstellen, wodurch es schwierig wird, einen vertrauenswürdigen einheitlichen Sicherheitsstandard festzulegen
• Cal.com erklärte, man habe zwischen zwei Optionen wählen müssen
  • Open Source beibehalten und das Risiko für Kundendaten in Kauf nehmen oder
  • zu Closed Source wechseln, um das Risiko zu verringern
  • Es sei keine perfekte Lösung, werde aber als unvermeidbare Entscheidung zum Schutz der Nutzer betrachtet
• Um den Open-Source-Gedanken fortzuführen, wurde ein separates Projekt namens Cal.diy unter der MIT-Lizenz veröffentlicht
  • Cal.diy ist eine offene Version für Entwickler und Hobby-Nutzer, eine community-orientierte, selbst hostbare Version
  • Die Codebasis des eigentlichen Dienstes wurde in zentralen Bereichen wie Authentifizierung und Datenverarbeitung stark verändert und ist technisch von Cal.diy getrennt
• KI verändert die Sicherheitslandschaft rasant; erwähnt wird auch ein Fall, in dem KI eine 27 Jahre alte Schwachstelle im BSD-Kernel in wenigen Stunden fand und einen Exploit erzeugte
  • Diese Geschwindigkeit und Präzision übertrifft bestehende Sicherheitsreaktionssysteme
  • Cal.com ergreift nach eigenen Angaben alle möglichen Maßnahmen, um Kunden, Anwendungen und sensible Daten zu schützen, und bekundet die Absicht, wieder zu Open Source zurückzukehren, wenn sich die Sicherheitslage stabilisiert

Zukünftige Richtung und Botschaft

• Derzeit haben die Minderung von Sicherheitsrisiken und der Schutz der Nutzer oberste Priorität
• Die Beziehung zur Open-Source-Community soll über Cal.diy aufrechterhalten werden
• Langfristig bleibt die Möglichkeit einer Rückkehr zu Open Source entsprechend der Entwicklung der Sicherheitslage offen
• Diese Entscheidung zeigt, dass die Sicherheitsrealität im KI-Zeitalter direkte Auswirkungen auf Software-Vertriebsmodelle hat

[GN⁺]

Hacker-News-Kommentare

• Drew Breunig kam in einem gestern veröffentlichten Beitrag zum genau gegenteiligen Schluss
  Da Sicherheitslücken inzwischen zu einer Ressource geworden sind, die sich mit Tokens finden lässt, sei Open Source im Gegenteil wertvoller
  Bei Open Source können mehrere Projekte sich die Audit-Kosten teilen, während man bei Closed Source alle Schwachstellen allein finden muss

  • Der Beitrag wurde hier erneut gepostet. Der Titel lautet Cybersecurity looks like proof of work now
  • Der eigentliche Grund scheint eher zu sein, dass man verhindern will, dass KI das Produkt copyright-wäscht. Sicherheit wirkt eher wie ein Vorwand
  • Dieser Schluss klingt plausibler. Mythos ist erst seit ein paar Wochen da, und die Prinzipien so schnell zu ändern, wirkt seltsam. Vermutlich gab es geschäftliche Gründe, und jetzt hat man nur eine gut verkäufliche Begründung für die Öffentlichkeit gefunden
  • Auch wirtschaftlich ist das schlüssig. Am Ende muss man entweder genug Wert schaffen, um die Token-Kosten zu tragen, oder den wirtschaftlichen Nutzen der Schwachstellenfindung senken
    Das ist möglich, indem man den Bereitstellungsumfang reduziert oder die Systemrechte einschränkt.
    Künftig dürfte es sich zu „offene Spezifikation + modellbasierte Codegenerierung“ entwickeln. Sicherheit und Governance würden dann auf der Modellebene stattfinden
  • Die Aussage „Um ein System zu härten, muss man mehr Tokens ausgeben als der Angreifer“ klingt seltsam. Bei stabiler Software nimmt die Angriffsfläche ab, und Mythos erzeugt keine neuen Schwachstellen. Der Verteidiger sollte bei Tokens im Vorteil sein

• Ich leite das Thunderbird-Projekt. Unser Terminplanungs-Tool Thunderbird Appointment wird dauerhaft Open Source bleiben
  Es wird dazu eingeladen, es gemeinsam im GitHub-Repository weiterzuentwickeln. Wir wollen helfen, damit es Cal.com ersetzen kann

  • Es wäre gut, Screenshots im README oder auf der Seite vor dem Login hinzuzufügen. Das Tool sieht gut aus, aber ich würde gern den Preis der gehosteten Version wissen
  • Auf älteren Linux-Laptops ist Thunderbird aber viel zu schwergewichtig. Bitte berücksichtigt auch Nutzer mit schwächerer Hardware. Die Bitte ist, das Internet auf einem tragbaren Niveau zu halten
  • Ich bin auf die Seite gegangen, habe meine E-Mail eingegeben, wurde auf eine Warteliste gesetzt und am Ende wurde meine E-Mail blockiert. Die User Experience war nicht gut
  • Auf das „Baut es mit uns zusammen“ kam als Witz die Frage: „Braucht man dafür dann einen Termin (appointment)?“
  • Es gab auch positive Reaktionen, dass es wie eine gute Alternative aussieht

• Wenn LLMs Schwachstellen im Code wirklich so gut finden, könnte man dann nicht einfach vor jedem Release einen eigenen LLM-Pentest laufen lassen?
  Es wirkt, als würde Linus’ Gesetz (Link) jetzt endlich Realität werden

  • Nach dem Release können Angreifer den Code jedoch unbegrenzt lange und mit immer intelligenteren LLMs analysieren.
    Um sich zu verteidigen, müsste man alles, was der Angreifer tun kann, vor jedem Release im Voraus durchführen
  • Mit der Weiterentwicklung der LLMs steigen bei der FOSS-Wartung Zeit- und Personalkosten stark an.
    KI-erzeugte minderwertige Issues oder PRs nehmen zu, wodurch der Anreiz sinkt, Open Source zu pflegen.
    Solche Wechsel dürften häufiger werden, wenn kommerzielle Produkte auf einem FOSS-Kern basieren
  • Bei Closed Source kann man LLMs intern nutzen, um die Sicherheit zu stärken.
    Trotzdem ist nachvollziehbar, dass man schließt, um keine externen Angriffsmöglichkeiten offenzuhalten
  • In Umgebungen mit häufigen Commits müsste man jedes Mal die gesamte Codebasis mit einem LLM scannen, wodurch die Kosten explodieren.
    Auch bei GitHub sind die Kosten für statische Analyse bereits hoch
  • Am Ende sei es wohl am besten, einfachen Code zu schreiben und LLM-Sicherheitstests auch auf Compiler-Ebene durchzuführen

• Diese Entscheidung wirkt eher wie eine geschäftliche Entscheidung als eine Sicherheitsmaßnahme.
  Dank KI wird Self-Hosting einfacher, wodurch die Einnahmen aus kostenpflichtigem Hosting bei Open-Source-Projekten sinken

  • Leute nutzen LLMs, um „Pro-Features“ direkt selbst zu bauen oder Erweiterungspunkte zu finden. Sicherheit ist dabei nur Fassade
  • KI dafür verantwortlich zu machen, ist eine Ausrede. KI hat ohnehin schon aus Code gelernt. Genetische Algorithmen + Fuzzing lernen viel schneller als Menschen
  • Heute wird alles der KI angelastet. Personalabbau, Produktabkündigungen und das Schließen des Source Codes — alles soll plötzlich wegen KI passieren
  • Das Produkt wird bereits zur Commodity, etwa wie das Terminplanungstool von Google Workspace
  • Am Ende fiel auch der Vorwurf, man habe sich einfach „verkauft“

• Als potenzieller Kunde bin ich von der Entscheidung von Cal.com enttäuscht.
  Open Source kann durch einen transparenten SSDLC Vertrauen schaffen, während man bei Closed Source dem Anbieter einfach glauben muss
  Mit Drew Breunigs Argument stimme ich nicht überein. Die Zahl der Bugs ist endlich, und wenn ein ausreichend starkes Modell den Code regelmäßig scannt, sinkt die Wahrscheinlichkeit verbleibender Schwachstellen stark

• „Wenn KI Open-Source-Code scannen kann?“ → Dann behebt man die Bugs eben.
  Diese Logik ist überhaupt nicht überzeugend

• „Wir machen zu, weil KI Zugriff auf den Code hat“ ist nur ein Vorwand

  • Der eigentliche Grund ist weder KI noch Sicherheit, sondern dass es zu viele Klonprojekte gibt und dadurch die Einnahmen sinken

• Solche Entscheidungen wirken am Ende wie Security through Obscurity.
  Seit wann das das richtige Modell sein soll, ist fraglich

  • Obskurität ist nur dann sinnvoll, wenn sie kein primäres Verteidigungsmittel, sondern eine ergänzende Abschreckung ist
  • Die Angriffsfläche zu reduzieren ist keine Obskurität, sondern eine Strategie zur Minimierung von Angriffsvektoren
  • Trotzdem meinten manche, es sei immer noch besser als „Sicherheit ohne Obskurität“
  • Ein Mitgründer sagte, „der 16-Jährige von nebenan könne es in 15 Minuten für 100 Dollar hacken“
  • Es wirkt, als hätte man vergessen, warum das Konzept „keine Sicherheit durch Obskurität“ überhaupt entstanden ist.
    Nicht weil frühere Generationen dumm waren, sondern weil es ein Ansatz war, der auf den ersten Blick gut wirkte, aber gescheitert ist

• Cal.coms Aussage „Wir haben an Open Source geglaubt“ klingt hohl.
  Wenn es ernst gemeint gewesen wäre, hätte man sich nicht mit solchen sinnlosen Ausreden herausgeredet

• Das ist eine Ausrede, die es auch schon vor KI gegeben hätte.
  Es wirkt wie ein Versuch, die Umsätze zu schützen, weil das Kernprodukt nicht ausreichend differenziert ist.
  Am Ende ist es nur eine Maßnahme zum Schutz des Umsatzes