Beyond the Audit: Building an Always-On Security Culture for Web3

Transcript

Hello. Hello. Can you hear me? Great. Hello everybody. My name is Dan. I'm with Sherlock. I'm head of sales at Sherlock. And um I'm going to cover a very interesting topic. Oh, the time didn't start. I have more than five minutes. That's great. Um so I want to talk to you about uh a recent trend that we noticed uh while doing more than 100 audits this year is the difference in approach uh from teams and the real differentiation between teams. uh looking at security as a point in time approach or something that they do continuously and we have to understand that uh we have some great power in web 3 uh coming from transparency and transparency is very good for the user but it's also very good for the black

hat because he can look into the codebase always and uh in the name of the philosopher uncle Ben with great power comes great responsibility and we need to take care of the code that is on chain so how do we do that even if you look at how many teams approach their security. Right now a lot of them are looking uh we're doing a lot of point in time um engagements more like solo audits testing uh with the idea that you do it once the code is secure and you can launch it on chain. However, if we look at even in web two right even the sock 2 frameworks those things you have to do yearly right. Um even if we look at some other approaches in web 3 we have right now like bug bounties um

maybe AI reviews these are uh things that are expected to to be ongoing things that uh a team is doing constantly and if you look at black hat activity and white hat activity um it is known that they approach a codebase uh on a continuous basis and they might come back to your codebase month after month. So we need to move into the always on security approach and I want to quickly show you how a typical uh how a typical company would audit their codebase or approach security. They would do one or two collaborative audits. Then we maybe have a bug bounty and this is considered like standard good security right now in the industry.

And um there are actually statistical models you can use to determine uh how many more bugs are left in the codebase that we have inherited from web two. And if you use a statistical model on a lot of these uh audit reports and um for a lot of these teams, you will notice that according to them, there are still five 10 or so code bugs left in the codebase. And this is a big problem. So I want to give you some data. Uh in preparation for this for this presentation, I looked at the data from 400 plus audits we have done just to determine um kind of how it looks on our side. And as you can see uh about 43% of teams would warrant uh re audit based on the number of

vulnerabilities we find in their codebase. And to give you some insight into how I have come up with this information basically I have looked at anytime a team has refactored more than 25% of their code base basically a fixed review being you know like a new audit. um whether a team had more than three high vulnerabilities per thousand ants, all of those teams would be in this category. And you could see it's a scary number, right? It's a very scary number if we look at it. And um it's also very expensive for the team and that's one of the reasons why it's so painful because it would cost them on average about 65,000 and that's half of the problem.

The bigger problem is obviously the delay which the awful BDS don't like and push the teams to deploy as soon as possible and many teams are taking the at the first glance easy route but with huge consequences down the line which is disregarding the recommendations that the um you know their auditors give them and still launch even though you know the codebase is not in the perfect state or not mainet ready. So this is some scary statistics and uh this has been you know has been troubling us for the past year and we've been thinking about how to um how to solve this problem basically. So uh this is what I propose to you a different method of approaching security uh in a way to make it

continuous one to both mirror how black hats perform and to mirror some of what web more web two companies do. um we're utilizing the tools we have available with both point in time security measures and ongoing security measures. So a lot of it has to move here right into the development process. Really I think this is going to be the next trend for the next year. how we move security early into development process and I believe that we'll see a lot more security AI tools being used for that and teams already top teams are utilizing the help of security consultations from security researchers to really um implement or embed security at the development stage when they are

only conceptualizing the codebase and the ideas they have in mind um we can then finally after you know this tedious process this process would take a team like three to five months Then we would go into the audit process and there we have you know anything from formal verification to collaborative audits to audit competitions I don't have to chat about them you know what they are and only only after that only after the final reports you know don't have highs in them only have a few issues then we can go and uh you know they let the white hats do their job and hopefully uh teams opt for Sherlock Shield uh or for basically insurance and we see more of that coming to the market where uh we

get some insurance in these uh big big protocols. Uh that's my time. Thank you very much. Thank you so much Dan. That was awesome.