Open Source ist nicht tot

• Cal.com stellt seinen Kerncode mit Verweis auf KI-gestützte Bedrohungen bei der Schwachstellenerkennung auf proprietär um und spricht von einer Zeit, in der „Transparenz gleich Offenlegung“ sei
• Strix ist ein Open-Source-Projekt, das autonome KI-Sicherheitsagenten entwickelt, und arbeitet mit Cal.com an einem verantwortungsvollen Verfahren zur Offenlegung von Schwachstellen
• Strix betont, dass das Schließen von Code keine Lösung für KI-Sicherheitsbedrohungen ist und vielmehr Möglichkeiten für wohlwollende Prüfungen blockiert
• KI-Angriffe können auch ohne Codezugriff im Blackbox-Verfahren eindringen; eine proprietäre Strategie bleibt anfällig für automatisierte Angriffe
• Die echte Lösung besteht darin, KI-Abwehr in den Entwicklungsprozess zu integrieren und durch kontinuierliche automatisierte Validierung die Transparenz und Zusammenarbeit von Open Source zu bewahren

---

Cal.coms Umstellung auf proprietären Code und die Open-Source-Sicherheitsdebatte

• Cal.com hat angekündigt, seine zentrale Codebasis von Open Source auf proprietär umzustellen
  • CEO Bailey Pumfleet sagte, dass wir mit KI in ein Zeitalter eingetreten seien, in dem Schwachstellen im großen Maßstab automatisch gefunden werden und „Transparenz gleich Offenlegung“ sei
  • Als Grund nannte er, dass KI Code-Scans und Exploits nahezu zu „Nullkosten“ durchführen könne
• Strix ist ein Open-Source-Projekt, das autonome KI-Sicherheitsagenten entwickelt, und hat kürzlich 24k GitHub-Stars überschritten
  • Es verarbeitet täglich mehr als 15 Milliarden LLM-Tokens, um Software-Schwachstellen zu erkennen
  • Gemeinsam mit Cal.com wurde mithilfe von Strix ein verantwortungsvoller Offenlegungsprozess für Schwachstellen durchgeführt; Details zu noch nicht gepatchten Bugs wurden nicht veröffentlicht
  • Strix erkennt an, dass Cal.coms Entscheidung aus dem Willen zum Schutz der Nutzer entstanden ist
• Dennoch betont Strix: „Das Schließen des Codes ist keine Lösung für KI-basierte Sicherheitsbedrohungen.“
  • Dass KI die Sicherheit grundlegend verändert hat, wird geteilt, der Abkehr von Open Source widerspricht Strix jedoch

Blackbox-KI kann auch in proprietären Code eindringen

• Die Annahme, dass Angreifer den Code nicht lesen können, wenn der Source Code geschlossen wird, gilt für moderne KI-Angriffsmodelle nicht
  • Für frühere statische Analysetools mochte das zutreffen, doch autonome KI-Agenten können auch ohne Codezugriff Angriffe ausführen
• Tools wie Strix sind auf Blackbox- und Graybox-Tests spezialisiert
  • Sie interagieren mit realen Endpunkten und führen Manipulation von Browser-Zuständen, Analyse von Netzwerkverkehr und Erkennung von Schwachstellen in der Geschäftslogik durch
• Proprietärer Code versperrt lediglich gutwilligen Entwicklern die Möglichkeit zur Prüfung, während die für Angreifer sichtbare Angriffsfläche durch APIs, Webhooks usw. unverändert bleibt

Die Strategie „Security through obscurity“ ist gegen automatisierte Angriffe anfällig

• Proprietärer Code stützt sich auf interne Sicherheitsteams und regelmäßige manuelle Penetrationstests
  • Angreifer suchen jedoch mit ununterbrochen laufenden KI-Bots rund um die Uhr nach Schwachstellen
• Das beruht auf der Annahme, dass internes Personal Fehler schneller finden kann als externe KI-Angriffe — realistisch ist das nicht
• Schon in der Vergangenheit ist „Security through obscurity“ gescheitert, und im KI-Zeitalter wird dieses Scheitern exponentiell schneller eintreten

Die echte Lösung: KI mit KI verteidigen

• Dass die Geschwindigkeit der Softwareentwicklung die menschliche Sicherheitsprüfung überholt hat, stimmt
  • Die Lösung besteht jedoch nicht darin, Code zu verstecken, sondern KI-Abwehr in den Entwicklungsprozess zu integrieren
• Nötig ist KI-basierte kontinuierliche Validierung (continuous validation)
  • Wenn Entwickler einen Pull Request öffnen, startet die KI sofort Angriffsversuche
  • Bei Infrastrukturänderungen validiert die KI automatisch die Angriffsfläche
• Sicherheitstests müssen innerhalb der CI/CD-Pipeline automatisiert werden, mit einer internen Automatisierung, die besser ist als die Automatisierung der Angreifer

Open Source ist weiterhin gültig

• Das traditionelle Prinzip „Many eyes make bugs shallow“ mag schwächer werden, doch Open Source selbst ist nicht tot
• Strix hält an Open Source fest, aus der Überzeugung, dass Transparenz Stärke schafft
  • Sicherheitswerkzeuge der nächsten Generation sollten genauso zugänglich und offen sein wie Angriffswerkzeuge
• Das Verstecken von Code kann KI-Hacker nicht aufhalten, doch wenn Entwicklern autonome Sicherheitsagenten zur Verfügung stehen, steigen die Verteidigungschancen
• Strix bietet die Möglichkeit, KI-basierte kontinuierliche Sicherheitstests kostenlos auszuprobieren

[GN⁺]

Hacker-News-Meinungen

• Ich betreibe ein Open-Source-Projekt, und in den letzten Monaten ist die Zahl der Berichte über Sicherheitslücken explodiert.
  Die meisten waren Kleinigkeiten, aber es gab auch echte Probleme, und ich habe sie alle behoben.
  Geschlossene Software bekommt solche Berichte vielleicht nicht, aber dort besteht das Risiko eines Missbrauchs durch AI.
  Deshalb stimme ich der Aussage dieses Artikels voll zu.

  • Kann man nicht auch in einem geschlossenen Projekt intern AI-Scanner laufen lassen?
    Es ist nur nach außen geschlossen, nicht für die internen Entwickler.
  • Von automatisierten Repo-Scannern kommen vielleicht keine Meldungen, aber Bug-Bounty-Programme erzeugen weiterhin viele Reports.
    Mit dem Aufkommen von AI-Tools ist allerdings auch das Problem entstanden, dass Anfänger von AI erzeugte Phantom-Reports einreichen.
    Auch geschlossene Unternehmen sollten freiwillig Sicherheitsaudits durchführen.
  • Aus Sicht eines Angreifers ist es viel lohnender, mit AI Open-Source-Repositories anzugreifen.
    Ich kann verstehen, warum Cal.com auf Closed Source umgestellt hat, aber am Ende wirkt es wie Marketing für Strix.
    Für Open-Source-Unternehmen wird der Nachteil umso größer, je länger sie öffentlich bleiben.
  • Ich habe für mein Open-Source-Projekt ebenfalls nächtliche automatische Penetrationstests eingerichtet.
    Wenn man solche Berichte regelmäßig veröffentlicht, könnte das die Vertrauenswürdigkeit der Sicherheit belegen.
    Bei bestehenden Projekten haben sich allerdings bereits Issues mittlerer und niedriger Priorität angesammelt, deren Behebung wohl Zeit braucht.
  • Unser Unternehmen kombiniert intern AI-Scanner und manuelle Penetrationstests.
    Das heißt, wir nutzen gleichzeitig AI-gestützte Schwachstellenerkennung und mehrschichtige Verteidigung, während der Code nicht öffentlich ist.

• Die Begründung des CEO, dass „AI in großem Maßstab Schwachstellen automatisch findet“, klingt wie eine Ausrede.
  Der eigentliche Grund ist wahrscheinlich, dass sich mit Open Source nur schwer ein nachhaltiges Geschäftsmodell aufbauen lässt.

  • Stimme zu. Ich kann verstehen, auf Closed Source umzustellen, um Profitabilität zu sichern, aber die Sicherheitsbegründung ist nicht ehrlich.
  • Wir haben fünf Jahre lang mit Open Source 300 % Wachstum gehalten und dabei Geld verdient.
    Die Umstellung auf Closed Source ist geschäftlich eher nachteilig, aber wir haben entschieden, dass der Schutz der Kundendaten wichtiger ist.
  • Heute wird alles gern auf AI geschoben.
    Ob Personalabbau oder Lizenzänderung – „wegen AI“ ist eine bequeme Ausrede.
  • Inzwischen ist es viel zu einfach, Open-Source-Code nicht direkt zu nutzen, sondern nur die benötigten Teile herauszuziehen und neu zusammenzusetzen.
    Seiten wie npmjs könnten bald zu reinen Referenz-Websites werden.
  • cal.diy offen zu lassen und den Enterprise-Teil zu schließen, ist eine klassische Open-Core-Strategie.
    Es den AI-Scannern anzulasten, ist nur PR-Verpackung.

• Dieser Artikel wirkt wirklich wie ein Lehrbuchbeispiel für Content-Marketing.

  1. Mit einer provokanten Überschrift Aufmerksamkeit erzeugen
  2. Verständnis für die Position von Cal.com zeigen und so Sympathie der Leser gewinnen
  3. Eine ernsthafte Lösung für das Problem präsentieren
  4. Und am Ende ganz natürlich zur Werbung für das eigene Produkt überleiten
     Ein Fall, in dem sich Aufrichtigkeit und Marketing raffiniert vermischen.
  • Ich habe es genauso gelesen. Das Unternehmen hinter dem Text verkauft einen AI-Dienst zum Scannen auf Schwachstellen, also dient es letztlich dazu, Registrierungen zu fördern.
    Strix hat den Code von Cal.com tatsächlich gescannt, dabei aber viele Schwachstellen übersehen.
    Keine Plattform ist perfekt, und AI-Scanner allein reichen nicht aus.
  • Schade, dass dieser Beitrag so viele Upvotes bekommen hat. Die inhaltliche Dichte reicht gerade für einen Kommentar.
  • Ich persönlich nutze kein AI. Im Moment ist es marketingtechnisch einfach, auf den AI-Hype aufzuspringen, aber ob dahinter echter Wert steckt, ist fraglich.

• Security through obscurity ist nur dann ein Problem, wenn man sich ausschließlich darauf verlässt.
  Als zusätzliche Abschreckungsschicht, die die Kosten für Angreifer erhöht, ist es eine wirksame Strategie.
  Letztlich ist Sicherheit ein Kampf darum, welche Seite mehr Ressourcen investieren kann.
  AI ist nur effizienter als Menschen, aber die grundlegende Rechnung zwischen offen und geschlossen ändert sich dadurch nicht.

• Ich frage mich, ob Cal.com wirklich um Sicherheit besorgt ist oder ob das nur ein Vorwand ist, um die Schwierigkeiten von Open-Source-SaaS zu verdecken.
  Diese Logik wurde schon vor Jahrzehnten als falsch widerlegt.

• Ich glaube nicht, dass Security through obscurity der wahre Grund ist.
  Sie denken wohl einfach, dass sie mehr Umsatz machen können, wenn sie Open Source schließen.

  • Genau. Es ist ihr Produkt, also können sie damit machen, was sie wollen.
    Eine der hässlichen Seiten von Open Source ist, dass Menschen gratis geleistete Arbeit als selbstverständlich ansehen.
    Statt Entwicklern zu danken, die jahrelang kostenlos gearbeitet haben, werden sie wütend, wenn diese nicht weiter gratis arbeiten.
    Dabei würden sie selbst auch nicht ohne Gehalt arbeiten.

• Nach dem Artikel klingt es so, als hätte Cal.com mit einem Red-Team-Bot auf Schwachstellen testen lassen.
  Weil Bugs zu schnell gefunden wurden, könnte der CEO die Kosten für die Behebung als Belastung empfunden und den Code geschlossen haben.
  Es wirkt fast wie eine öffentliche Erklärung, dass der Code von Cal.com viele Schwachstellen hat.

  • Oder der Scanner hat vielleicht zu viele False Positives erzeugt, was das eigentliche Problem war.
    Wenn man das feinjustiert, übersieht man echte Schwachstellen, und dadurch steigen am Ende die Validierungskosten.
    Bei Open Source werden solche Reports öffentlich und können dem Ruf schaden, bei Closed Source ist das nicht so.
    Auch das könnte ein Grund für die Umstellung gewesen sein.

• Das eigentliche Risiko ist nicht die Erkennung von Schwachstellen, sondern dass LLMs Open-Source-Projekte in andere Sprachen umschreiben und so Lizenzen umgehen können.

  • Bei geschlossenen Projekten wäre theoretisch Ähnliches möglich, aber es gibt viel mehr Einschränkungen.
  • Das passiert in der Praxis häufig. AI erzeugt den Code fast unverändert neu und macht daraus ein Klonprojekt.
    Rechtlich ist das unklar. Wenn ein Mensch etwas studiert und danach neu schreibt, ist das in Ordnung, aber wenn AI es macht, ist es faktisch ein kompliziertes Copy-and-paste.
    Es ist unklar, wie Lizenzen in solchen Fällen angewendet werden.
  • Viele Open-Source-Lizenzen erlauben Forks und Wiederverkauf.
    Allein mit offengelegtem Code lässt sich kein Geschäft aufbauen; wichtiger ist die Fähigkeit zum Betrieb.

• Ich stimme der Aussage zu, dass Sicherheitstests im CI/CD-Workflow automatisiert werden sollten.
  Aber das beweist nicht die Notwendigkeit von Open Source.

• Das Gleichgewicht von Open Source ist schon vor langer Zeit zerbrochen.
  Schon lange nutzen Unternehmen Open-Source-Code, um kostenpflichtige Produkte zu bauen, ohne etwas zurückzugeben.
  PHP ist ein Beispiel für eine Sprache, die weltweit verwendet wird, aber unterfinanziert ist.