Giovanni Vignone, CEO and Founder of Octane Security, launched the company in 2022 to tackle the growing need for proactive cybersecurity in Web3. At just 22, he set out to build an AI-powered platform that acts like a 24/7 security engineer—analyzing smart contract codebases in real time, integrating directly into CI/CD pipelines, and catching vulnerabilities that traditional audits often miss.
In this conversation, we explore Octane’s mission to embed continuous, explainable vulnerability detection into the software development lifecycle—and what it takes to secure the future of smart contracts.
What inspired the decision to leave Duke and build Octane full-time? Was there a particular moment that clarified the opportunity?
During my junior year at Duke, I got early beta access to OpenAI’s platform and started experimenting with large language models on smart contracts in crypto. The results really opened my eyes to what was possible.
There was one specific moment that stands out. I fed a smart contract into the chat interface and asked it to find any issues. The results needed work, but I could immediately see the huge potential of using LLMs to spot hard-to-find vulnerabilities. This was back in March 2023.
This happened around the same time I was seeing all these hacks and exploits happening throughout the industry. I realized there was an urgent need to fix these security problems, and these models gave us a unique way to tackle them. It just clicked that this was the right time to go all-in on Octane.
What were some of the biggest technical or operational challenges in taking Octane from concept to adoption by major crypto companies?
The biggest technical challenge was figuring out how to identify vulnerabilities and show them to users in a way they could actually use. This was really hard because vulnerabilities aren’t black and white – they have multiple dimensions.
When we look at a potential vulnerability, we need to consider several things: what’s the impact (could someone lose money or important state?), how easy is it to exploit, what can be done to fix it, and what’s causing the problem in the first place. Handling all these aspects at once and presenting them clearly took a lot of work.
We put a ton of effort into productizing each of these components so customers could use Octane to find vulnerabilities, quickly understand how serious they are, and start fixing them right away. Building systems that could consistently spot these issues across different codebases required both technical know-how and lots of data on all kinds of vulnerabilities.
Octane aims to function like an AI security engineer embedded in every dev team. What milestones are needed to fully realize that goal across the industry?
Our first big milestone is changing how developers think about security – getting them to build it in from day one instead of tacking it on a few weeks before launch. This means showing them that starting with security actually saves time by letting them fix issues earlier.
We also need to help users see and understand what happens when they catch vulnerabilities early, so they can experience the benefits firsthand.
On the product side, we need to support more languages beyond just Solidity – other smart contract languages and eventually regular programming languages too. We’re always working on making our models better in terms of accuracy and catching more types of vulnerabilities.
How will the platform evolve to address complex, non-code-based threats like phishing or malware-based exploits?
We actually already handle some of these threats today. We flag centralization risks, which helps teams know which private keys and roles are especially sensitive.
We also catch common phishing patterns in smart contracts, like when someone uses tx.origin for caller verification logic, that can lead to phishing attacks. We make sure to point these out to users.
Right now, Octane mainly works as a pre-deployment security tool rather than something that catches threats in real-time. Our plan is to keep expanding what we can detect before code goes live, giving developers the tools to fix potential problems before they become actual attacks.
What makes unsupervised machine learning—specifically clustering—a more effective approach for classifying smart contract vulnerabilities than traditional rule-based systems?
Unsupervised machine learning has really helped us map out what kinds of bugs exist out there. While we still use rule-based techniques to build our supervised models, unsupervised learning, especially clustering, helps us figure out which models we should be building and how to prioritize them.
This approach lets us break down our models into more specialized analysis pipelines for different vulnerability types..
We actually use both supervised and unsupervised ML together—unsupervised learning to understand the landscape and supervised methods to build precise detection capabilities. This combination works better than just relying on traditional rule-based systems alone.
Can you share an example where clustering surfaced a new class of vulnerabilities that wasn’t previously recognized in audits or security reviews?
Clustering doesn’t really create new categories of vulnerabilities from scratch—it takes existing data and groups it in meaningful ways. Our data comes from real-world on-chain exploits, public vulnerability reports, and other sources of smart contract bugs.
What unsupervised learning does really well is it helps us refine how we understand existing vulnerability categories. It spots patterns and connections between different vulnerabilities that might otherwise go unnoticed, which lets us build better detection methods.
Through this pattern recognition and data grouping, we’ve created more nuanced models that can catch subtle variations of known vulnerability types, rather than discovering completely new classes of vulnerabilities.
How does Octane handle edge cases where a vulnerability doesn’t clearly fit into existing categories within the taxonomy?
We try to balance how specific versus general we make our taxonomy. The more general our categories and models are, the better we can catch weird edge cases that don’t fit neatly anywhere. But more specific categories give users better explanations and let us catch known bug types more consistently.
When we run into vulnerabilities that Octane misses or that don’t clearly match our existing categories, we look at whether we should add more data about that vulnerability to an existing model, or if we need to create a completely new model to catch that type of bug in the future.
This flexible approach lets us keep improving our detection capabilities while maintaining a framework that makes sense to users.
After analyzing thousands of bugs, what recurring patterns or root causes have stood out across smart contract vulnerabilities?
We’ve seen several tough patterns come up over and over. Reentrancy is still a major issue in smart contracts. Another big category comes from the fact that transactions are publicly visible in the mempool, which creates vulnerabilities where attackers can see pending transactions and steal information or cause transactions to fail—what people call front-running, though it happens in many different ways.
We’ve also found lots of critical vulnerabilities that come from simple developer mistakes. These used to be broadly called “logic errors,” but that’s too vague. One common mistake we see is developers forgetting to update state variables in certain code paths where they really need to.
These are just a few examples—we have a much more detailed private breakdown of all bugs that we’ve developed through our data analysis efforts.
Smart contracts vary widely across ecosystems and languages. How does Octane ensure that its models remain effective across these diverse environments?
A lot of vulnerabilities follow common patterns regardless of the specific language or ecosystem. This lets us build models that can effectively spot these vulnerabilities across different codebases.
We design our models to focus on the basic security principles that apply broadly across smart contract systems, while accounting for the specific features of different languages. This approach helps us stay effective across various environments without having to rebuild everything for each new language.
By focusing on the core patterns of vulnerabilities rather than surface-level details, we’ve built models that can adapt to the diverse world of smart contract development.
AI-based security tools often face skepticism around explainability. How does Octane ensure that vulnerability classifications and alerts are actionable for developers?
We’ve put a lot of work into our back-end validation process to verify vulnerabilities through additional checks.
We carefully sort our findings to separate critical vulnerabilities (that could actually impact the codebase) from less severe issues or warnings that represent best practices. This categorization helps developers focus on what matters most.
Our UI is designed to be simple and clear, highlighting the most serious issues so they get immediate attention instead of being buried in a bunch of less important alerts. By giving clear explanations and focusing on what’s actionable, we make sure developers can quickly understand and fix the vulnerabilities we find.
Thank you for the great interview, readers who wish to learn more should visit Octane Security.