Continuous protection in Web3: Hacken's Q1 2026 security report

On April 16, 2026, I joined a Hacken-hosted webinar alongside Jessica Levesque from C4, Shelby Sun from KuCoin EU, and Yulia Murat from Global Ledger, moderated by Hacken CGO Igor Bershadskiy. The conversation was grounded in real Q1 data from Hacken's Security and Compliance Report, which tracked $482.6 million in losses across 44 incidents during the quarter.

The numbers tell one story. The patterns behind them tell another. Smart contract vulnerability losses surged 213% compared to Q1 2025, reaching $86.2 million across 28 incidents. Six of those exploited protocols had prior audits. Resolv Labs had 18 audits on record. Venus Protocol had five audit firms review its code. Their smart contracts functioned exactly as designed. The vulnerability in Resolv's case was entirely in the off-chain infrastructure managing the privileged signing key. None of that showed up in a code review.

What follows is a summary of the main points I raised during the webinar.

Audit versus assessment is not a small distinction

The industry has a language problem. An audit, properly defined, provides a point-in-time attestation around the effectiveness of controls you have already built. What most projects call a "smart contract audit" is something different: an assessment, a review of vulnerabilities found in the codebase at that moment.

That distinction matters because too many firms use these reports as a gold stamp of security. The logic becomes: an outside firm reviewed the code, so the system must be secure. But a point-in-time assessment does not create lasting security. New vulnerabilities can appear tomorrow. The attack surface can shift without a single line of code changing. Q1 confirmed this pattern at scale.

My criticism is not that these reviews are useless. It is that they are being used in place of a broader security program.

Supply chain is the blind spot most teams cannot even see

One of the most consistently misunderstood infrastructure risks is supply chain. The Q1 report recorded $7 million in losses from inherited and supply chain vulnerabilities, but the exposure is almost certainly larger than what gets attributed, because most teams cannot scope what they are actually running.

You need a full software bill of materials to understand the entirety of that threat model. Without one, you cannot even identify what you are exposed to. And there is a meaningful difference between installing packages from a public registry versus obtaining the actual source code, vetting it, and standing up private registries you control. That is the line between a startup security program and a mature one. Most web3 teams are still on the wrong side of it.

A pentest is not the same thing as asking whether someone can steal your crypto

There is a sharp difference between pentesting and red teaming that the industry consistently blurs.

A pentest asks whether someone can break into a specific web application. A red team exercise asks something much closer to the real business risk: can I steal your crypto? That framing changes everything. Once the objective is defined around the actual asset, the attack surface expands dramatically. It may involve infrastructure, identity, governance failures, or social engineering rather than code alone.

Maybe the attacker cannot get through the firewall. But maybe they can meet a founder at an event, hand over a USB drive, and create another route-in entirely. Step Finance lost $40 million in Q1 through exactly that kind of human-layer attack: a fake VC video call, fabricated audio issues, a malicious software download, and private keys exposed on an executive's daily-driver device. Their smart contracts were not the problem.

That is exactly the kind of adversarial thinking the industry needs more of. The goal is not to test a narrow system component. The goal is to understand whether an adversary can actually achieve the outcome that matters.

Defense in depth is a design principle, not a buzzword

When I was asked what infrastructure risk I expect to define Q2 2026, the honest answer is that there is no single risk. That framing is itself part of the problem.

Defense in depth is not a buzzword. It is a design principle that needs to be incorporated into everything you build and operate. People and processes need to be secured with the same rigor as the technology. Most teams over-index on tooling and under-invest in the two things that actually determine whether those tools work when it matters.

The Q1 data reinforces this. Failures were distributed across code, operations, and infrastructure simultaneously. Smart contract vulnerabilities, access control compromises, DNS hijacking, and social engineering all showed up in the same quarter. No single audit, certification, or monitoring tool addresses that. Layered, continuous protection is the only posture that works.

Web3 still confuses visible security with real security

Not all security work serves the same purpose. There are things security teams do for regulators. There are things they do because the board expects them. And then there are the things nobody is asking for, which are often the most important parts of a real program.

Much of web3 focuses on the minimum needed to stop criticism, satisfy surface-level expectations, or win customer trust. That is a fundamentally different posture from what large regulated financial institutions operate under. Those teams do the regulator-facing work, the governance-facing work, and the deeper technical work that may not be explicitly requested but is still necessary.

Much of web3 is not yet doing that deeper work. Q1 showed what the gap costs.

Compliance is not a list of five things

Too many companies want compliance reduced to a simple list. Tell us exactly what to do. Tell us the minimum. Tell us which controls are required. But that misunderstands how serious regulatory regimes work, and with MiCA now in active enforcement, the cost of that misunderstanding is rising fast.

Regulatory requirements are principle-based, not checklist-based. The point is not for regulators to hand firms a fixed list of actions and walk away. The point is for firms to build a defensible program and demonstrate how they are protecting client assets, managing keys, handling fraud, and supporting AML and KYC obligations, with evidence that controls are operating effectively in practice.

Asking an AI tool what you need to do to be compliant reflects the wrong mindset entirely. The question is not finding the magic answer. The question is whether your organization can explain its program, justify its design, and produce evidence that the controls work. Regulators verify that controls are effectively implemented, not merely documented.

Engineering strength does not automatically create security maturity

Many web3 projects are too engineering-led in the wrong way. Engineers and security engineers are not interchangeable. Product engineers often believe they can solve security problems with more code, more signatures, or more technical mechanisms. Without proper threat modeling and a dedicated security function, that confidence tends to be misplaced.

They think that because they are engineers and technical, they understand security and can do both. They cannot.

A useful test: look at projects that have been hacked, then look at how many actual security engineers they employed. In many cases the answer is zero. In others, there may be one visible security hire, which functions more as a symbol than a real team. That structural gap is one of the clearest weaknesses in the space, and Q1's incident data reflects it directly.

Threat modeling reveals whether a company is taking security seriously

One of the most practical questions you can ask a vendor: how would you hack yourself?

It's a way to understand whether a company has actually threat-modeled its own environment. If the answer is that it cannot be hacked, that is already a warning sign. Every organization has some pathway in. The question is whether it understands that pathway, whether it has taken steps to make the attack difficult or uneconomic, and whether it could detect it in time.

The detection gap is real and measurable. According to Global Ledger's data shared in the webinar, teams report hacks an average of 1.5 days after an incident, while attackers begin moving funds before the report in 76% of cases. For Resolv Labs in March, the attacker extracted $20 million before the team could pause the protocol. Minutes mattered. Security maturity is not about saying the right things. It is about understanding where the real weaknesses are and demonstrating that you have built around them.

Web3 has to decide what standard it wants to meet

Web3 effectively sits in one of two camps. Either it sees itself as a system that wants to disintermediate traditional financial infrastructure, or it wants to work with institutions. Whichever path it chooses, the answer is the same: it has to protect assets properly.

If it wants to challenge the existing financial system, it still has to secure user funds with seriousness. If it wants to work with institutions, it has to rise to institutional standards.

Audits, point-in-time assessments, and performative security are not enough. If web3 wants to mature, it needs real security programs built around continuous protection, adversarial thinking, and clearer operational discipline from the start.