Giovanni Vignone, CEO & Gründer von Octane Security – Interviewreihe

Giovanni Vignone, CEO und Gründer von Octane Security, gründete das Unternehmen im Jahr 2022, um dem wachsenden Bedarf an proaktiver Cybersicherheit im Web3 zu begegnen. Mit gerade einmal 22 Jahren machte er sich daran, eine KI‑gestützte Plattform zu bauen, die wie ein 24/7‑Security‑Engineer funktioniert – sie analysiert Smart‑Contract‑Codebasen in Echtzeit, integriert sich direkt in CI/CD‑Pipelines und erkennt Schwachstellen, die traditionelle Audits oft übersehen.

In diesem Gespräch erkunden wir die Mission von Octane, kontinuierliche, erklärbare Schwachstellenerkennung in den Software‑Entwicklungs‑Lifecycle zu integrieren – und was nötig ist, um die Zukunft von Smart Contracts zu sichern.

Was inspirierte die Entscheidung, Duke zu verlassen und Octane Vollzeit aufzubauen? Gab es einen besonderen Moment, der die Gelegenheit klar machte?

Während meines Junior-Jahres an der Duke University erhielt ich frühen Beta‑Zugang zur Plattform von OpenAI und begann, mit großen Sprachmodellen an Smart Contracts im Krypto‑Bereich zu experimentieren. Die Ergebnisse öffneten mir wirklich die Augen für das, was möglich war.

Ein konkreter Moment bleibt besonders in Erinnerung. Ich gab einen Smart Contract in die Chat‑Oberfläche ein und bat ihn, etwaige Probleme zu finden. Die Ergebnisse benötigten Nachbesserung, aber ich konnte sofort das enorme Potenzial erkennen, LLMs zu nutzen, um schwer auffindbare Schwachstellen aufzudecken. Das war im März 2023.

Das geschah etwa zur gleichen Zeit, als ich all diese Hacks und Exploits in der Branche beobachtete. Mir wurde klar, dass ein dringender Bedarf besteht, diese Sicherheitsprobleme zu beheben, und diese Modelle boten uns einen einzigartigen Ansatz, sie anzugehen. Es wurde sofort klar, dass dies der richtige Zeitpunkt war, um voll auf Octane zu setzen.

Was waren einige der größten technischen oder operativen Herausforderungen, Octane vom Konzept zur Adoption durch große Krypto‑Unternehmen zu bringen?

Die größte technische Herausforderung bestand darin, herauszufinden, wie man Schwachstellen identifiziert und sie den Nutzern so präsentiert, dass sie tatsächlich nutzbar sind. Das war sehr schwierig, weil Schwachstellen nicht schwarz‑weiß sind – sie haben mehrere Dimensionen.

Wenn wir eine potenzielle Schwachstelle betrachten, müssen wir mehrere Aspekte berücksichtigen: Was ist die Auswirkung (kann jemand Geld oder wichtigen Zustand verlieren?), wie einfach ist sie auszunutzen, was kann getan werden, um sie zu beheben, und was verursacht das Problem überhaupt. All diese Aspekte gleichzeitig zu handhaben und klar zu präsentieren, erforderte viel Arbeit.

Wir haben enorm viel Aufwand betrieben, um jede dieser Komponenten zu produktisieren, damit Kunden Octane nutzen können, um Schwachstellen zu finden, schnell zu verstehen, wie ernst sie sind, und sie sofort zu beheben. Systeme zu bauen, die diese Probleme konsistent über verschiedene Codebasen hinweg erkennen können, erforderte sowohl technisches Know‑how als auch umfangreiche Daten zu allen Arten von Schwachstellen.

Octane soll wie ein KI‑Security‑Engineer in jedem Entwicklerteam funktionieren. Welche Meilensteine sind nötig, um dieses Ziel branchenweit vollständig zu realisieren?

Unser erster großer Meilenstein besteht darin, das Denken der Entwickler bezüglich Sicherheit zu verändern – sie dazu zu bringen, Sicherheit von Anfang an zu integrieren, anstatt sie erst wenige Wochen vor dem Launch hinzuzufügen. Das bedeutet, ihnen zu zeigen, dass ein frühzeitiger Sicherheitsansatz tatsächlich Zeit spart, indem er ermöglicht, Probleme früher zu beheben.

Wir müssen außerdem den Nutzern helfen, zu sehen und zu verstehen, was passiert, wenn sie Schwachstellen frühzeitig erkennen, damit sie die Vorteile aus erster Hand erleben.

Produktseitig müssen wir mehr Sprachen unterstützen, nicht nur Solidity – weitere Smart‑Contract‑Sprachen und schließlich auch reguläre Programmiersprachen. Wir arbeiten ständig daran, unsere Modelle in Bezug auf Genauigkeit zu verbessern und mehr Arten von Schwachstellen zu erkennen.

Wie wird sich die Plattform weiterentwickeln, um komplexe, nicht‑codebasierte Bedrohungen wie Phishing oder malwarebasierte Exploits zu adressieren?

Wir behandeln bereits heute einige dieser Bedrohungen. Wir kennzeichnen Zentralisierungsrisiken, was Teams hilft zu erkennen, welche privaten Schlüssel und Rollen besonders sensibel sind.

Wir erfassen außerdem gängige Phishing‑Muster in Smart Contracts, zum Beispiel wenn jemand tx.origin für die Verifizierungslogik des Aufrufers verwendet, was zu Phishing‑Angriffen führen kann. Wir weisen die Nutzer darauf hin.

Derzeit funktioniert Octane hauptsächlich als Pre‑Deployment‑Security‑Tool und nicht als Echtzeit‑Erkennungsmechanismus. Unser Plan ist, das, was wir vor dem Live‑Gang des Codes erkennen können, weiter auszubauen, sodass Entwickler Werkzeuge erhalten, um potenzielle Probleme zu beheben, bevor sie zu echten Angriffen werden.

Was macht unüberwachtes maschinelles Lernen – speziell Clustering – zu einem effektiveren Ansatz für die Klassifizierung von Smart‑Contract‑Schwachstellen im Vergleich zu traditionellen regelbasierten Systemen?

Unüberwachtes maschinelles Lernen hat uns wirklich dabei geholfen, die vorhandenen Fehlertypen zu kartieren. Während wir weiterhin regelbasierte Techniken einsetzen, um unsere überwachten Modelle zu erstellen, unterstützt uns unüberwachtes Lernen, insbesondere Clustering, dabei zu bestimmen, welche Modelle wir bauen sollten und wie wir sie priorisieren.

Dieser Ansatz ermöglicht es uns, unsere Modelle in spezialisiertere Analyse‑Pipelines für verschiedene Schwachstellentypen zu unterteilen.

Wir nutzen tatsächlich sowohl überwachte als auch unüberwachte ML zusammen – unüberwachtes Lernen, um das Umfeld zu verstehen, und überwachte Methoden, um präzise Erkennungsfähigkeiten zu entwickeln. Diese Kombination funktioniert besser, als sich ausschließlich auf traditionelle regelbasierte Systeme zu verlassen.

Können Sie ein Beispiel nennen, bei dem Clustering eine neue Klasse von Schwachstellen aufdeckte, die in Audits oder Sicherheitsüberprüfungen bisher nicht erkannt wurde?

Clustering erzeugt nicht wirklich neue Kategorien von Schwachstellen von Grund auf – es nimmt vorhandene Daten und gruppiert sie auf sinnvolle Weise. Unsere Daten stammen aus realen On‑Chain‑Exploits, öffentlichen Schwachstellenberichten und anderen Quellen von Smart‑Contract‑Fehlern.

Was unüberwachtes Lernen besonders gut kann, ist, dass es uns hilft, unser Verständnis bestehender Schwachstellenkategorien zu verfeinern. Es erkennt Muster und Zusammenhänge zwischen verschiedenen Schwachstellen, die sonst übersehen werden könnten, und ermöglicht uns, bessere Erkennungsmethoden zu entwickeln.

Durch diese Mustererkennung und Daten­gruppierung haben wir differenziertere Modelle erstellt, die subtile Varianten bekannter Schwachstellentypen erfassen können, anstatt völlig neue Klassen von Schwachstellen zu entdecken.

Wie geht Octane mit Randfällen um, bei denen eine Schwachstelle nicht eindeutig in die bestehenden Kategorien der Taxonomie passt?

Wir versuchen, ein Gleichgewicht zwischen Spezifität und Allgemeinheit unserer Taxonomie zu finden. Je allgemeiner unsere Kategorien und Modelle sind, desto besser können wir seltsame Randfälle erfassen, die nirgendwo eindeutig passen. Spezifischere Kategorien bieten den Nutzern jedoch bessere Erklärungen und ermöglichen es uns, bekannte Fehlertypen konsistenter zu erfassen.

Wenn wir auf Schwachstellen stoßen, die Octane übersieht oder die nicht eindeutig zu unseren bestehenden Kategorien passen, prüfen wir, ob wir mehr Daten zu dieser Schwachstelle zu einem bestehenden Modell hinzufügen sollten oder ob wir ein völlig neues Modell erstellen müssen, um diesen Fehlertyp in Zukunft zu erfassen.

Dieser flexible Ansatz ermöglicht es uns, unsere Erkennungsfähigkeiten kontinuierlich zu verbessern und gleichzeitig ein für die Nutzer nachvollziehbares Rahmenwerk beizubehalten.

Nach der Analyse von Tausenden von Bugs, welche wiederkehrenden Muster oder Grundursachen sind bei Smart‑Contract‑Schwachstellen besonders aufgefallen?

Wir haben mehrere hartnäckige Muster immer wieder beobachtet. Reentrancy bleibt ein großes Problem in Smart Contracts. Eine weitere bedeutende Kategorie resultiert daraus, dass Transaktionen im Mempool öffentlich sichtbar sind, was Schwachstellen erzeugt, bei denen Angreifer ausstehende Transaktionen einsehen und Informationen stehlen oder Transaktionen zum Scheitern bringen können – das, was man Front‑Running nennt, obwohl es auf viele Arten vorkommt.

Wir haben zudem zahlreiche kritische Schwachstellen entdeckt, die auf einfachen Entwicklerfehlern beruhen. Diese wurden früher allgemein als „Logikfehler“ bezeichnet, was zu vage ist. Ein häufiger Fehler ist, dass Entwickler vergessen, Zustandsvariablen in bestimmten Code‑Pfaden zu aktualisieren, wo dies unbedingt nötig ist.

Dies sind nur einige Beispiele – wir verfügen über eine deutlich detailliertere private Aufschlüsselung aller Bugs, die wir durch unsere Datenanalyse entwickelt haben.

Smart Contracts variieren stark zwischen Ökosystemen und Sprachen. Wie stellt Octane sicher, dass seine Modelle in diesen unterschiedlichen Umgebungen wirksam bleiben?

Viele Schwachstellen folgen gemeinsamen Mustern, unabhängig von der jeweiligen Sprache oder dem Ökosystem. Das ermöglicht uns, Modelle zu bauen, die diese Schwachstellen effektiv über verschiedene Codebasen hinweg erkennen.

Wir konzipieren unsere Modelle so, dass sie sich auf die grundlegenden Sicherheitsprinzipien konzentrieren, die allgemein für Smart‑Contract‑Systeme gelten, und gleichzeitig die spezifischen Merkmale verschiedener Sprachen berücksichtigen. Dieser Ansatz hilft uns, in verschiedenen Umgebungen wirksam zu bleiben, ohne für jede neue Sprache alles neu aufbauen zu müssen.

Indem wir uns auf die Kernmuster von Schwachstellen statt auf Oberflächendetails konzentrieren, haben wir Modelle entwickelt, die sich an die vielfältige Welt der Smart‑Contract‑Entwicklung anpassen können.

KI‑basierte Sicherheitstools stoßen oft auf Skepsis hinsichtlich der Erklärbarkeit. Wie stellt Octane sicher, dass Schwachstellenklassifizierungen und Warnungen für Entwickler handlungsfähig sind?

Wir haben viel Arbeit in unseren Backend‑Validierungsprozess investiert, um Schwachstellen durch zusätzliche Prüfungen zu verifizieren.

Wir sortieren unsere Ergebnisse sorgfältig, um kritische Schwachstellen (die den Code tatsächlich beeinträchtigen könnten) von weniger schweren Problemen oder Warnungen, die Best‑Practices darstellen, zu trennen. Diese Kategorisierung hilft Entwicklern, sich auf das Wesentliche zu konzentrieren.

Unsere Benutzeroberfläche ist einfach und klar gestaltet, hebt die gravierendsten Probleme hervor, damit sie sofortige Aufmerksamkeit erhalten, anstatt in einer Flut weniger wichtiger Warnungen unterzugehen. Durch klare Erklärungen und den Fokus auf Handlungsfähigkeit stellen wir sicher, dass Entwickler die von uns gefundenen Schwachstellen schnell verstehen und beheben können.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten Octane Security besuchen.