Giovanni Vignone, VD & Grundare av Octane Security – Intervjuserie

Giovanni Vignone, VD och grundare av Octane Security, lanserade företaget 2022 för att möta det växande behovet av proaktiv cybersäkerhet i Web3. Vid endast 22 år började han bygga en AI-driven plattform som fungerar som en 24/7 säkerhetsingenjör—analyserar smartkontraktskodbaser i realtid, integreras direkt i CI/CD-pipelines och fångar sårbarheter som traditionella granskningar ofta missar.

I detta samtal utforskar vi Octanes uppdrag att integrera kontinuerlig, förklarlig sårbarhetsdetektering i mjukvaruutvecklingslivscykeln—och vad som krävs för att säkra framtiden för smart contracts.

Vad inspirerade beslutet att lämna Duke och bygga Octane på heltid? Fanns det ett särskilt ögonblick som klargjorde möjligheten?

Under mitt tredje år på Duke fick jag tidig betaåtkomst till OpenAIs plattform och började experimentera med stora språkmodeller på smarta kontrakt inom kryptovalutor. Resultaten öppnade verkligen mina ögon för vad som var möjligt.

Det fanns ett specifikt ögonblick som sticker ut. Jag matade ett smart kontrakt i chattgränssnittet och bad det hitta eventuella problem. Resultaten behövde förbättras, men jag kunde omedelbart se den enorma potentialen i att använda LLM:er för att upptäcka svårupptäckta sårbarheter. Detta var i mars 2023.

Detta hände ungefär samtidigt som jag såg alla dessa hack och exploateringar som inträffade i branschen. Jag insåg att det fanns ett akut behov av att åtgärda dessa säkerhetsproblem, och dessa modeller gav oss ett unikt sätt att tackla dem. Det klickade bara att detta var rätt tid att satsa fullt ut på Octane.

Vilka var några av de största tekniska eller operativa utmaningarna med att ta Octane från koncept till antagande av stora kryptoföretag?

Den största tekniska utmaningen var att lista ut hur man identifierar sårbarheter och visar dem för användarna på ett sätt som de faktiskt kan använda. Detta var mycket svårt eftersom sårbarheter inte är svartvita – de har flera dimensioner.

När vi granskar en potentiell sårbarhet måste vi överväga flera saker: vad är påverkan (kan någon förlora pengar eller viktig status?), hur lätt är den att utnyttja, vad kan göras för att åtgärda den, och vad som orsakar problemet från början. Att hantera alla dessa aspekter samtidigt och presentera dem tydligt krävde mycket arbete.

Vi lade ner enormt mycket arbete på att produktifiera var och en av dessa komponenter så att kunderna kunde använda Octane för att hitta sårbarheter, snabbt förstå hur allvarliga de är och börja åtgärda dem omedelbart. Att bygga system som konsekvent kan upptäcka dessa problem i olika kodbaser krävde både teknisk kunskap och stora mängder data om alla typer av sårbarheter.

Octane strävar efter att fungera som en AI-säkerhetsingenjör inbäddad i varje utvecklingsteam. Vilka milstolpar behövs för att fullt ut förverkliga det målet i hela branschen?

Vår första stora milstolpe är att förändra hur utvecklare tänker på säkerhet – få dem att bygga in den från dag ett istället för att lägga till den några veckor före lansering. Detta innebär att visa dem att ett tidigt fokus på säkerhet faktiskt sparar tid genom att låta dem åtgärda problem tidigare.

Vi måste också hjälpa användarna att se och förstå vad som händer när de upptäcker sårbarheter tidigt, så att de kan uppleva fördelarna själva.

På produktsidan måste vi stödja fler språk än bara Solidity – andra smarta kontraktspråk och så småningom även vanliga programmeringsspråk. Vi arbetar ständigt med att förbättra våra modeller när det gäller noggrannhet och att upptäcka fler typer av sårbarheter.

Hur kommer plattformen att utvecklas för att hantera komplexa, icke-kodbaserade hot som phishing eller malware-baserade exploateringar?

Vi hanterar faktiskt redan några av dessa hot idag. Vi flaggar centraliseringsrisker, vilket hjälper team att veta vilka privata nycklar och roller som är särskilt känsliga.

Vi fångar också vanliga phishing-mönster i smarta kontrakt, som när någon använder tx.origin för verifieringslogik, vilket kan leda till phishing-attacker. Vi ser till att påpeka detta för användarna.

Just nu fungerar Octane främst som ett säkerhetsverktyg före driftsättning snarare än något som fångar hot i realtid. Vår plan är att fortsätta utöka vad vi kan upptäcka innan koden går live, så att utvecklare får verktygen att åtgärda potentiella problem innan de blir faktiska attacker.

Vad gör oövervakad maskininlärning—specifikt klustring—till ett mer effektivt tillvägagångssätt för att klassificera smarta kontrakts sårbarheter jämfört med traditionella regelbaserade system?

Oövervakad maskininlärning har verkligen hjälpt oss att kartlägga vilka typer av buggar som finns. Även om vi fortfarande använder regelbaserade tekniker för att bygga våra övervakade modeller, hjälper oövervakad inlärning, särskilt klustring, oss att avgöra vilka modeller vi bör bygga och hur vi ska prioritera dem.

Detta tillvägagångssätt låter oss dela upp våra modeller i mer specialiserade analyspipelines för olika typer av sårbarheter..

Vi använder faktiskt både övervakad och oövervakad ML tillsammans—oövervakad inlärning för att förstå landskapet och övervakade metoder för att bygga precisa detekteringsmöjligheter. Denna kombination fungerar bättre än att bara förlita sig på traditionella regelbaserade system.

Kan du ge ett exempel där klustring avslöjade en ny klass av sårbarheter som tidigare inte identifierats i granskningar eller säkerhetsgranskningar?

Klustring skapar egentligen inte nya kategorier av sårbarheter från grunden—den tar befintliga data och grupperar dem på meningsfulla sätt. Våra data kommer från verkliga on-chain-exploateringar, offentliga sårbarhetsrapporter och andra källor till smarta kontraktsbuggar.

Det som oövervakad inlärning gör riktigt bra är att den hjälper oss att förfina hur vi förstår befintliga sårbarhetskategorier. Den upptäcker mönster och samband mellan olika sårbarheter som annars kan gå obemärkt förbi, vilket låter oss bygga bättre detekteringsmetoder.

Genom denna mönsterigenkänning och datagruppering har vi skapat mer nyanserade modeller som kan fånga subtila variationer av kända sårbarhetstyper, snarare än att upptäcka helt nya klasser av sårbarheter.

Hur hanterar Octane edge‑fall där en sårbarhet inte tydligt passar in i befintliga kategorier i taxonomin?

Vi försöker balansera hur specifik respektive generell vår taxonomi är. Ju mer generella våra kategorier och modeller är, desto bättre kan vi fånga märkliga edge‑fall som inte passar någonstans. Men mer specifika kategorier ger användarna bättre förklaringar och låter oss fånga kända bugtyper mer konsekvent.

När vi stöter på sårbarheter som Octane missar eller som inte tydligt matchar våra befintliga kategorier, överväger vi om vi ska lägga till mer data om den sårbarheten i en befintlig modell, eller om vi behöver skapa en helt ny modell för att fånga den typen av bugg i framtiden.

Detta flexibla tillvägagångssätt låter oss fortsätta förbättra våra detekteringsmöjligheter samtidigt som vi behåller ett ramverk som är begripligt för användarna.

Efter att ha analyserat tusentals buggar, vilka återkommande mönster eller grundorsaker har framträtt i smarta kontrakts sårbarheter?

Vi har sett flera svåra mönster dyka upp om och om igen. Återinträde är fortfarande ett stort problem i smarta kontrakt. En annan stor kategori beror på att transaktioner är offentligt synliga i mempoolen, vilket skapar sårbarheter där angripare kan se väntande transaktioner och stjäla information eller få transaktioner att misslyckas—det som folk kallar front‑running, även om det sker på många olika sätt.

Vi har också hittat många kritiska sårbarheter som beror på enkla utvecklarmisstag. Dessa kallades tidigare brett för “logikfel”, men det är för vagt. Ett vanligt misstag vi ser är att utvecklare glömmer att uppdatera tillståndsvariabler i vissa kodvägar där de verkligen måste.

Detta är bara några exempel—vi har en mycket mer detaljerad privat uppdelning av alla buggar som vi har utvecklat genom våra dataanalysinsatser.

Smarta kontrakt varierar kraftigt mellan ekosystem och språk. Hur säkerställer Octane att deras modeller förblir effektiva i dessa olika miljöer?

Många sårbarheter följer gemensamma mönster oavsett specifikt språk eller ekosystem. Detta låter oss bygga modeller som effektivt kan upptäcka dessa sårbarheter i olika kodbaser.

Vi designar våra modeller för att fokusera på de grundläggande säkerhetsprinciperna som gäller brett över smarta kontraktsystem, samtidigt som vi tar hänsyn till de specifika funktionerna i olika språk. Detta tillvägagångssätt hjälper oss att förbli effektiva i olika miljöer utan att behöva bygga om allt för varje nytt språk.

Genom att fokusera på kärnmönstren av sårbarheter snarare än ytliga detaljer har vi byggt modeller som kan anpassa sig till den mångsidiga världen av smarta kontraktsutveckling.

AI‑baserade säkerhetsverktyg möter ofta skepsis kring förklarbarhet. Hur säkerställer Octane att sårbarhetsklassificeringar och varningar är handlingsbara för utvecklare?

Vi har lagt ner mycket arbete på vår back‑end‑valideringsprocess för att verifiera sårbarheter genom ytterligare kontroller.

Vi sorterar noggrant våra fynd för att separera kritiska sårbarheter (som faktiskt kan påverka kodbasen) från mindre allvarliga problem eller varningar som representerar bästa praxis. Denna kategorisering hjälper utvecklare att fokusera på det som är viktigast.

Vårt UI är designat för att vara enkelt och tydligt, och markerar de allvarligaste problemen så att de får omedelbar uppmärksamhet istället för att begravas bland en mängd mindre viktiga varningar. Genom att ge tydliga förklaringar och fokusera på det som är handlingsbart ser vi till att utvecklare snabbt kan förstå och åtgärda de sårbarheter vi hittar.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka Octane Security.