Beyond Chains and Contracts: How Squads Thinks About Application Security Now

Why Squads expanded code security beyond the program

Gio: Web3 security has traditionally concentrated enormous effort on the smart contracts and programs themselves. What changed for you?

Sean: We spent years hyper focused on the program. We spent considerable time and money auditing it and formally verifying it. Squads V4 is still used by teams as a test case for formal verification because it’s a straightforward but very critical program.

So I wouldn’t describe what happened next as discovering an existing gap. I’d call it a shift of focus.

For years the questions were: Is the program secure? Is the program formally verified? Is the program audited?

Then the Safe frontend gets compromised in the Bybit attack. That was essentially an enterprise security and OpSec failure, not a smart contract vulnerability. An AWS session was compromised and suddenly the client side mattered enormously. Similarly, Drift got compromised without an attacker needing to find any bug in its smart contracts.

Users interact with Web3 through a browser. They’re not sitting there using a CLI to send everything manually. That means, as protocols mature, the relevant surface area changes.

A secure onchain footprint does not mean the application around it is secure.

Squads changed too. It used to be relatively slim: here is an interface for the program. As we built a real application around it, with more functionality, more integrations, DeFi features, NFT support and more data moving through different systems, code security at the web application layer became more important.

We were also seeing attackers get more creative. You have attacks designed simply to get somebody to click something, copy an address and eventually send funds somewhere they shouldn’t. Somebody has really thought through that attack chain.

So I think Web3 application security is expanding beyond the programs and contracts. The focus is moving upstream into the browsers, interfaces and infrastructure around them.

Separately, enterprise security expectations are maturing too. Now you go to conferences and there are lawyers and compliance teams asking about SOC 2. They want formalized controls and policies.

Within that broader security posture, what we needed from Octane was continuous code security analysis across the web applications and infrastructure that are becoming more critical to our product.

Why not just do it yourself?

Gio: You were already experimenting with models internally. Where did that stop being enough?

Sean: The big problem with doing code security analysis internally is your priors.

You build the thing. You have assumptions about how it works. Then you use your own process to audit the thing you built. It’s very difficult to get away from that.

We had dependency scanning. We brought in teams for manual black box penetration testing, and we experimented with frontier models and security prompting.

But with the frontier tooling, the problem was that we were in largely unknown territory. How do you build the harness? How do you give a general system enough context to understand a product that spans onchain programs, offchain services, DeFi integrations and multiple sources of truth?

Advanced cyber capabilities don’t necessarily give you any useful insight without a proper threat model, a workflow that fits and a team willing to work through the system with you hands on.

We could have pointed Daybreak at the code with essentially zero guidance, and naturally we wanted to compare it with Mythos. But that becomes an experiment in its own right. When you need to ship, you don’t necessarily have the bandwidth to design the harness, run the comparison and work out which system is actually giving you useful signal.

Better context changes both sides

Gio: Working off of that, one thing we keep finding is that better analysis depends on better context. What happened when you worked to improve the threat model you gave Octane?

Sean: This was actually one of the more valuable feedback loops.

We wanted better findings. To get better findings, we needed better context.

So we went back through all of our previous audits. We updated our risk register. We used AI to scan the repo and help formalize things. We looked at the surface area across the newer application and mapped risks to potential solutions and potential product improvements.

We reevaluated roughly 40 items in the risk register for the web application.

And this was all done just so we could get you a good model.

But the process forces you to ask useful questions yourself. What are the things that scare us? Are these risks still relevant? What changed as the application changed? Where are the external boundaries? What should actually be permissible?

There were concerns I already had that Octane validated. There were also longstanding issues that we were aware of but had never had the cycles to formalize.

That’s a very normal product problem. You know there is something you don’t love, but you also have to ship.

Now Octane can turn one of those concerns into a finding. It lands in triage. Somebody reviews it. If it’s valid, it goes into the cycle.

That’s exactly what I wanted.

And the findings have improved as the context has improved. Early on, there were findings that misunderstood parts of the threat model. Once we brought in more context, the relevance got better. Now when we ship code and something comes back against the diff, it is much more likely to be applicable.

There’s a loop there. We make the system understand Squads better, and, in doing that, we understand and document Squads better ourselves.

Finding can become product problems

Gio: Once a finding reaches Linear, what happens to it?

Sean: At this point it’s very hands off.

At the end of a cycle, I grab the findings, assign them to somebody, they validate them and then they fix them.

It’s just another ticket.

But the bigger story for me is using this to drive product decisions.

Every time you add a security guard to Squads, you’re doing this dance around usability. We want the application to be secure, but we also want people to be able to use it without fighting the product.

So a security finding can raise another question: is there friction in the product at this exact point?

A simple example is: why are we letting people click on something if we already know the transaction is going to fail? Could we identify that earlier? Could there be a heuristic around it? Could we change the feature?

Now the finding isn’t just “patch this code.” It can cause us to rethink what we present to the user, what actions we permit or how the feature should work.

Sometimes you implement the obvious security fix and it makes the product clunky. Then the really useful question is: how do we make it less clunky and still secure?

That is one of the core things I like about the arrangement.

Code is free, but correctness isn’t

Gio: You’ve said before that code is becoming close to free. What happens to security if that continues?

Sean: Code is free. You can make a whole lot of it.

Auditing, verifying, linting, all of that becomes far more important if you want to maintain agentic speed.

I think you’re going to see people going back to computer science in a serious way. More definitions of models. More properties. More invariants. More pipelines from code into things like TLA+ and Lean.

For a long time there has been this divide between software engineering and the more formal side of computer science. AI changes the economics.

People decide what to build, and the agent decides how to build it.

– Anthropic, Agentic coding and persistent returns to expertise

If producing the code is cheap, you can spend more time and effort asking if it’s actually correct.

LLMs will help with the specs too, but it isn’t going to be an LLM all the way down. You’re going to use systems built around formal methods for some properties. You’re going to have models helping you generate and reason about software. Then everything still has to come together inside a real application with real dependencies.

That is where the Jenga tower idea comes back.

You can prove individual pieces and have beautiful abstractions. Then you compose them with a browser, a framework, an API, a wallet, a dependency and some third party service somebody else maintains.

The whole system still has to be tested.

Gio: That’s why I keep coming back to one principle: you still need a way to test a clean result.

A system telling you it found nothing is not evidence by itself that you’re in the clear. As more of development becomes automated, the security layer has to independently test what those agents produced and the assumptions holding the pieces together.

Sean: I think AI-native code security is a must have now. The target has shifted from the onchain programs to the web applications, and the speed at which people are shipping code due to agentic AI is only going to create a larger surface area for threat actors.

Those two forces are happening at the same time. That’s the reason why Octane, for us, is a must have.

‍