Classifying Smart Contract Vulnerabilities with Machine Learning

How Octane Uses Unsupervised Machine Learning

When you're dealing with tens of thousands of smart contract vulnerabilities, the first challenge isn’t fixing them — it’s understanding them. You can’t solve what you can’t categorize. And in security, most issues don’t arrive with neat labels or pre-defined templates. That’s where clustering comes in.

Clustering is a form of unsupervised machine learning that helps us group similar vulnerabilities together based on patterns in the data, without telling the model what to look for in advance. It’s a way of letting the data organize itself. Think of it like dropping 20,000 bugs into a room and watching them sort themselves into groups based on how similar their behavior, structure, or impact is.

In Octane’s case, we apply clustering to organize vulnerabilities by type (Denial of Service, Reentrancy), subtype (DoS via unbounded for loops), and even by shared patterns in the underlying code or language structures. Bugs that share a root cause or exploit path tend to show up close together in the cluster. The result is a topographical map of threats, where related vulnerabilities sit near each other, and outliers drift to the edges.

This has a few key benefits:

• It helps us identify high-density zones of risk. If a particular cluster contains a large volume of bugs, that’s a signal. It tells us that class of vulnerability is prevalent and likely to reappear in new codebases.
• It reveals unknown-unknowns. Some clusters form around bugs we haven’t explicitly modeled yet. That’s a strong sign we’re seeing the early stages of an exploit pattern before it even has a name.
• It gives us structure for training new detectors. Once a cluster is well-formed, we can extract its characteristics and use them to build specialized detection models.

The beauty of clustering is that it’s flexible. One run might organize bugs by semantic similarity, another by code structure. We’ve found that different views yield different insights, so we use multiple layers of clustering to interpret vulnerabilities from various dimensions: severity, frequency, language, root cause, and more.

We don’t get a neat set of labels when we’re analyzing bugs in the wild. Most of what we see is messy, unlabeled, and inconsistent. Clustering gives us a way to impose structure on that chaos. It helps us spot patterns, reduce noise, and figure out where to focus. Over time, those clusters become the foundation for how we classify vulnerabilities, build detectors, and improve our models.

Bug Taxonomy: Building the Map of Threats

Once clustering surfaces a coherent group of related vulnerabilities, the next step is interpreting what those groups represent—and giving them structure. That’s where our internal bug taxonomy comes in.

At the top level, we define broad categories like Denial of Service, Reentrancy, or Transaction Ordering. Beneath that, we break them into specific subtypes that describe how the bug manifests, like “DoS via unbounded for loops” or “TOB inflation via block timestamp manipulation.”

For each classification, we document:

• A label (e.g., DoS_Loop_Bomb)
• A short description of the behavior
• Common traits or indicators
• Known fix strategies
• Related variants or subtypes

The goal is to understand the root causes. Two bugs might look completely different on the surface but stem from the same underlying issue. The taxonomy helps us trace them back to a shared origin. And once you know the root cause, you can often fix an entire class of vulnerabilities with a single change.

This structure helps us prioritize which vulnerabilities to model. If a cluster is large, shows up frequently, and maps cleanly to a subtype in our taxonomy, it’s a strong candidate for its own dedicated detector. We’ve followed this approach to build models for signature validation issues, transaction ordering bugs, and others that show consistent, repeated behavior across different codebases.

Our taxonomy evolves constantly. As new vulnerabilities emerge, or as we revisit ambiguous clusters, we update the structure to reflect what we’re learning — whether that’s from new data, audit findings, or behavior we see on-chain.

What We’ve Learned from Classifying Thousands of Vulnerabilities

After running clustering and classification across tens of thousands of smart contract vulnerabilities, a few patterns have stood out.

The first is how often different bugs reduce to the same underlying cause. We’ve seen cases where issues flagged under completely different labels — sometimes across audits, sometimes across protocols — end up clustering tightly and share an identical fix. These patterns aren’t always obvious until you look at them from the ML side. But once they’re grouped, it becomes clear that we’re often dealing with variations on the same theme.

Another thing we’ve noticed is how inconsistent language can hide real trends. One team might describe an issue as “signature parsing mismatch,” another calls it “EIP-712 validation failure,” and a third just calls it “malformed permit.” But they all point to the same behavioral pattern. Clustering lets us cut through that ambiguity and consolidate what would otherwise be treated as separate problems.

We’ve also seen which vulnerability classes show up most frequently, and which are easy to overlook. Some high-severity issues appear less often but are consistently missed by audits. Others are low-severity but extremely common, and may signal weak development patterns across teams. Having a classification system gives us a way to track both.

One benefit is how this process highlights new opportunities for detector coverage. When we see a dense, consistent cluster that doesn’t map to any existing model, that becomes a clear signal to build one. It’s a scalable way to decide where to build coverage next, not based on intuition, but based on actual patterns in the data.

Classifying vulnerabilities at this scale has helped us step back from individual alerts and see the broader structure of how bugs behave across the ecosystem. It’s also helped us prioritize our roadmap — both in terms of model development and surfacing the issues that actually matter to users.

Next Steps: Secure Your Code With Octane

By combining unsupervised learning with a constantly evolving taxonomy, we’ve been able to surface patterns that were otherwise buried in noise, and use those insights to guide everything from model development to issue prioritization.

As we process more data and encounter new edge cases, the classification system keeps improving, and so do the detectors built on top of it.

If you’re curious to see how this works in practice, or want to understand how Octane could help you surface and prioritize vulnerabilities in your own codebase, we’re happy to walk you through it. Schedule time with us here.