Interviews
Giovanni Vignone, CEO & grundlægger af Octane Security – Interviewserie

Giovanni Vignone, CEO og grundlægger af Octane Security, lancerede virksomheden i 2022 for at imødekomme det voksende behov for proaktiv cybersikkerhed i Web3. Som blot 22 år gammel gik han i gang med at bygge en AI-drevet platform, der fungerer som en 24/7 sikkerhedsingeniør—analysere smart contract‑kodebaser i realtid, integrere direkte i CI/CD‑pipelines og fange sårbarheder, som traditionelle revisioner ofte overser.
I denne samtale udforsker vi Octanes mission om at indlejre kontinuerlig, forklarlig sårbarhedsdetektion i softwareudviklingslivscyklussen—og hvad der kræves for at sikre fremtiden af smart contracts.
Hvad inspirerede beslutningen om at forlade Duke og bygge Octane på fuld tid? Var der et særligt øjeblik, der tydeliggjorde muligheden?
I løbet af mit juniorår på Duke fik jeg tidlig beta-adgang til OpenAIs platform og begyndte at eksperimentere med store sprogmodeller på smart contracts i crypto. Resultaterne åbnede virkelig mine øjne for, hvad der var muligt.
Der var ét specifikt øjeblik, der skiller sig ud. Jeg indtastede en smart contract i chat‑grænsefladen og bad den finde eventuelle problemer. Resultaterne krævede arbejde, men jeg kunne straks se det enorme potentiale i at bruge LLM’er til at opdage svære at finde sårbarheder. Det var tilbage i marts 2023.
Dette skete på samme tid som jeg så alle disse hacks og udnyttelser ske i hele branchen. Jeg indså, at der var et akut behov for at løse disse sikkerhedsproblemer, og disse modeller gav os en unik måde at tackle dem på. Det gik op for mig, at dette var det rette tidspunkt at gå all‑in på Octane.
Hvad var nogle af de største tekniske eller operationelle udfordringer ved at tage Octane fra koncept til adoption af store crypto‑virksomheder?
Den største tekniske udfordring var at finde ud af, hvordan man identificerer sårbarheder og viser dem til brugerne på en måde, de faktisk kan bruge. Dette var virkelig svært, fordi sårbarheder ikke er sort-hvide – de har flere dimensioner.
Når vi ser på en potentiel sårbarhed, skal vi overveje flere ting: hvad er påvirkningen (kan nogen miste penge eller vigtig tilstand?), hvor let er den at udnytte, hvad kan gøres for at rette den, og hvad forårsager problemet i første omgang. At håndtere alle disse aspekter på én gang og præsentere dem tydeligt krævede meget arbejde.
Vi lagde en masse arbejde i at produktisere hver af disse komponenter, så kunderne kunne bruge Octane til at finde sårbarheder, hurtigt forstå hvor alvorlige de er, og straks begynde at rette dem. At bygge systemer, der konsekvent kan opdage disse problemer på tværs af forskellige kodebaser, krævede både teknisk know‑how og masser af data om alle typer af sårbarheder.
Octane har til formål at fungere som en AI‑sikkerhedsingeniør indlejret i hvert udviklerteam. Hvilke milepæle er nødvendige for fuldt ud at realisere dette mål på tværs af branchen?
Vores første store milepæl er at ændre, hvordan udviklere tænker på sikkerhed – få dem til at bygge den ind fra dag ét i stedet for at tilføje den et par uger før lanceringen. Det betyder at vise dem, at en start med sikkerhed faktisk sparer tid ved at lade dem rette problemer tidligere.
Vi skal også hjælpe brugerne med at se og forstå, hvad der sker, når de opdager sårbarheder tidligt, så de kan opleve fordelene direkte.
På produkt‑siden skal vi understøtte flere sprog udover kun Solidity – andre smart contract‑sprog og efterhånden også almindelige programmeringssprog. Vi arbejder altid på at gøre vores modeller bedre med hensyn til nøjagtighed og at fange flere typer af sårbarheder.
Hvordan vil platformen udvikle sig for at håndtere komplekse, ikke‑kodebaserede trusler som phishing eller malware‑baserede udnyttelser?
Vi håndterer faktisk allerede nogle af disse trusler i dag. Vi markerer centraliseringsrisici, hvilket hjælper teams med at vide, hvilke private nøgler og roller der er særligt følsomme.
Vi fanger også almindelige phishing‑mønstre i smart contracts, som når nogen bruger tx.origin til opkalds‑verifikationslogik, hvilket kan føre til phishing‑angreb. Vi sørger for at påpege disse for brugerne.
Lige nu fungerer Octane primært som et sikkerhedsværktøj før implementering snarere end noget, der fanger trusler i realtid. Vores plan er at fortsætte med at udvide, hvad vi kan opdage, før koden går i live, så udviklere får værktøjerne til at rette potentielle problemer, før de bliver til faktiske angreb.
Hvad gør usupervised maskinlæring – specifikt clustering – til en mere effektiv tilgang til klassificering af smart contract‑sårbarheder end traditionelle regelbaserede systemer?
Usupervised maskinlæring har virkelig hjulpet os med at kortlægge, hvilke typer af fejl der findes. Selvom vi stadig bruger regelbaserede teknikker til at bygge vores supervised modeller, hjælper unsupervised læring, især clustering, os med at finde ud af, hvilke modeller vi skal bygge, og hvordan vi prioriterer dem.
Denne tilgang giver os mulighed for at opdele vores modeller i mere specialiserede analyse‑pipelines for forskellige sårbarhedstyper..
Vi bruger faktisk både supervised og unsupervised ML sammen – unsupervised læring til at forstå landskabet og supervised metoder til at bygge præcise detekteringsmuligheder. Denne kombination fungerer bedre end blot at stole på traditionelle regelbaserede systemer alene.
Kan du dele et eksempel, hvor clustering frembragte en ny klasse af sårbarheder, som tidligere ikke var genkendt i revisioner eller sikkerhedsgennemgange?
Clustering skaber egentlig ikke nye kategorier af sårbarheder fra bunden – den tager eksisterende data og grupperer dem på meningsfulde måder. Vores data kommer fra virkelige on-chain udnyttelser, offentlige sårbarhedsrapporter og andre kilder til smart contract‑fejl.
Det, som unsupervised læring gør rigtig godt, er at hjælpe os med at forfine, hvordan vi forstår eksisterende sårbarhedskategorier. Den opdager mønstre og forbindelser mellem forskellige sårbarheder, som ellers kunne gå ubemærket hen, hvilket giver os mulighed for at bygge bedre detektionsmetoder.
Gennem denne mønstergenkendelse og datagruppering har vi skabt mere nuancerede modeller, der kan fange subtile variationer af kendte sårbarhedstyper, i stedet for at opdage helt nye klasser af sårbarheder.
Hvordan håndterer Octane edge‑cases, hvor en sårbarhed ikke tydeligt passer ind i eksisterende kategorier inden for taksonomien?
Vi forsøger at balancere, hvor specifik versus generel vi gør vores taksonomi. Jo mere generelle vores kategorier og modeller er, desto bedre kan vi fange mærkelige edge‑cases, der ikke passer pænt ind nogen steder. Men mere specifikke kategorier giver brugerne bedre forklaringer og lader os fange kendte fejltyper mere konsekvent.
Når vi støder på sårbarheder, som Octane overser, eller som ikke tydeligt matcher vores eksisterende kategorier, ser vi på, om vi skal tilføje mere data om den sårbarhed til en eksisterende model, eller om vi skal oprette en helt ny model for at fange den type fejl i fremtiden.
Denne fleksible tilgang gør, at vi kan fortsætte med at forbedre vores detektionsmuligheder, mens vi bevarer en ramme, der giver mening for brugerne.
Efter at have analyseret tusindvis af fejl, hvilke tilbagevendende mønstre eller grundårsager er fremtrædende på tværs af smart contract‑sårbarheder?
Vi har set flere hårde mønstre dukke op igen og igen. Reentrancy er stadig et stort problem i smart contracts. En anden stor kategori skyldes, at transaktioner er offentligt synlige i mempoolen, hvilket skaber sårbarheder, hvor angribere kan se ventende transaktioner og stjæle information eller få transaktioner til at fejle – hvad folk kalder front‑running, selvom det sker på mange forskellige måder.
Vi har også fundet mange kritiske sårbarheder, der skyldes simple udviklerfejl. Disse blev tidligere bredt kaldt “logikfejl”, men det er for vagt. En almindelig fejl, vi ser, er at udviklere glemmer at opdatere tilstandsvariabler i visse kodeveje, hvor de virkelig skal.
Dette er kun nogle få eksempler – vi har en meget mere detaljeret privat opdeling af alle fejl, som vi har udviklet gennem vores dataanalysearbejde.
Smart contracts varierer bredt på tværs af økosystemer og sprog. Hvordan sikrer Octane, at deres modeller forbliver effektive på tværs af disse forskellige miljøer?
Mange sårbarheder følger fælles mønstre uanset det specifikke sprog eller økosystem. Dette gør, at vi kan bygge modeller, der effektivt kan opdage disse sårbarheder på tværs af forskellige kodebaser.
Vi designer vores modeller til at fokusere på de grundlæggende sikkerhedsprincipper, der gælder bredt på tværs af smart contract‑systemer, mens vi tager højde for de specifikke funktioner i forskellige sprog. Denne tilgang hjælper os med at forblive effektive på tværs af forskellige miljøer uden at skulle genopbygge alt for hvert nye sprog.
Ved at fokusere på kerne‑mønstrene af sårbarheder i stedet for overfladiske detaljer, har vi bygget modeller, der kan tilpasse sig den mangfoldige verden af smart contract‑udvikling.
AI‑baserede sikkerhedsværktøjer møder ofte skepsis omkring forklarlighed. Hvordan sikrer Octane, at klassificeringer af sårbarheder og advarsler er handlingsorienterede for udviklere?
Vi har lagt meget arbejde i vores back‑end valideringsproces for at bekræfte sårbarheder gennem ekstra tjek.
Vi sorterer omhyggeligt vores fund for at adskille kritiske sårbarheder (som faktisk kan påvirke kodebasen) fra mindre alvorlige problemer eller advarsler, der repræsenterer bedste praksis. Denne kategorisering hjælper udviklere med at fokusere på det, der betyder mest.
Vores UI er designet til at være enkel og klar, fremhævende de mest alvorlige problemer, så de får øjeblikkelig opmærksomhed i stedet for at blive begravet i en masse mindre vigtige advarsler. Ved at give klare forklaringer og fokusere på det handlingsorienterede, sikrer vi, at udviklere hurtigt kan forstå og rette de sårbarheder, vi finder.
Tak for det fantastiske interview, læsere der ønsker at lære mere bør besøge Octane Security.












