Thriving in the Multifaceted World of Web3 Security, Bogomil Tsvetkov, Certora | ETHSofia 2025

Transcript

[Music] Thank you. It's a great pleasure to be here today with all of you. My name is Bogo and as you already found out, I'm a security researcher. To put it more, do you hear me? Well, okay. To put it more simply, I'm the guy who analyzes smart contracts and make sure that uh to find the vulnerabilities in them. Uh those are bugs that can lead to loss of funds, denial of service attacks or anything that can cause the integrity of the

protocol. My task is to find them and fix them and make sure they cannot be exploited. I've been part of the blockchain industry for the past five years. Uh I started as a web developer uh doing decentralized applications and about three years ago I pivoted into the security aspects of this. I started with uh bug bounties with competitions I'm sorry and uh eventually I started winning them and placing in the top spots. Then I did bug bounties and eventually I focused entirely on working with uh protocol teams directly and

helping them make their contracts uh more secure. And more recently I uh joined as a full uh full-time lead security researcher at Certora where I have the privilege and this is not an overstatement to work with the biggest protocols this industry has to offer. We're talking billions of dollars of uh value that get to be secured every day. Uh and uh throughout this whole journey that I just described uh I work with more than 100 protocol teams which allowed me to observe an issue which is that sometimes protocol teams don't have a proper understanding

of the security landscape. What are the different type of security services they can use to secure their protocols? How each service works? Uh what is the proper time uh in their security uh life cycle? Uh how to use it and how to combine those services to produce more secure uh code and more efficient use of their uh of their uh security budget. We all of this is the inspiration for the topic for today's talk which is which I called the trifecta of blockchain security. Uh what you see here in the right are the three pillars of modernday web3 security. You have

private audits, security competitions and bug bounties. All those combined uh are what uh are the three pillars of the uh security life cycle of a protocol. In the next few of this issa so uh in the next few slides I'm gonna talk about each of those elements explain how they work what they do what type of security challenges they're meant to solve and then how to combine them to produce the best security outcome for your code and the most efficient use of your budget.

So we start off with private audits. This is the most widely used and common service. Here a team hires another team of security researchers to audit their codebase. Normally it's between two to four people. The task of the security team is to find as much issues in the codebase as possible and uh at the end of the audit to uh submit a security report. This report contains uh all the uncovered vulnerabilities along with recommendations on how to fix them and then uh recommendations on how to make the code better, more uh efficient and better uh structured. Uh once that is done uh the protocol team

uh has to fix all of those issues and in the end there is a final follow-up review that make sure the uh code fixes and not code recommendations were implemented properly and the team can deploy uh safely. Uh the other type of service uh uh are competitions. The difference from private audits here is that it's a public format. So a protocol announces publicly that they want to host a public competition and they also determine a price pool uh inviting everyone with security expertise to join and compete against other competitors to uh find bucks and

get get paid for it. When a competition ends, uh, judges validate all the issues and produce a security report. And based on that security report, you have the final leaderboard and, uh, the guys that are at the top places in that leaderboard get a lot of recognition on top of the money, which builds their image and name in this community. Uh the the final type of security service that we have are bug bounties.

They're very unique because they're the only format that focuses on life code uh where uh contracts are deployed on mainet. They're accessible to users and they basically manage money. And how this works is a protocol announces their bug bounty platform. They specifically point what type of vulnerabilities and what type of severity levels they're ready to pay for. And after that, uh, as with competitions, anyone that has a required skill and willingness goes to audit their contracts and submit vulnerabilities and yeah, get paid for that. They're they're the most elite form of recognition if you manage to

uncover a critical vulnerability. And uh after you have a relatively better understanding of how each service works uh the next thing I would like to talk about is the so-called security life cycle of a protocol. Uh uh which is meant to explain how each of those services fits into the stages of that cycle. Uh so here we have two uh stages. First is the pre-eployment stage. This is when the uh development team has fully prepared their contracts and they're uh looking to uh to deploy to mainet. So right here as you can see in that stage we have private audits and

competitions. Uh I want to make a note on the gap uh here between private audits and competitions. This is here to uh show that you always start with private audits. you hire that team of experts to go through your codebase, find all the issues in there, give uh help you optimize it, make it more uh efficient and only when that's done, you go to Uh if you do it that way, you will save significantly on your security budget and produce in the end more secure code.

After that, after the security competition is completed, uh you have a final round of private audits that are aimed to uh do a final review of all the code changes made based on the competition and make sure that you're ready to deploy and which lead us to the uh second stage which is the post deployment stage where you can see we have private audits and bug bounties uh here and uh both the bars The green and the red one go up until the end of the timeline until infinity which is here to show that uh those two services you would need them for as long as your

contracts are live and running and operational. Uh you would need for example here private audits uh to um to review all the code changes that you make before pushing them to production. And then bug bounties, they are meant to be the second layer of protection meant to catch any issues that manage to slip into production. Uh, another reason that you would need private audits here is to have that team to consult you on the bug bounty submissions and make sure they're valid and also help you with again with the code changes that you would make to fix those issues, especially the critical and high vulnerability ones.

uh after everything this that I said we can conclude that the private audits are the absolute basic uh fundamental part of the security schedule of any uh protocol and this is something you cannot get away with. For example, with the other two formats, uh, competitions and bounties, they can be optional for protocols that are smaller and highly recommended for bigger, more complex, and mainly projects that hold a lot of value. But in the end, they would always go hand inhand with private audits. And this is why they're so important.

Uh next I would like to do a breakdown of each of the three services and explain what are their exact advantages and where they excel. Uh we start off with private audits. Uh the main advantage here is that you have a dedicated here the keyword is dedicated team of experts which have the main goal of producing the best security service for your protocol. Uh meaning they're interested in making sure those contracts cannot be exploited. It's because they bear the weight of responsibility and put their name behind that audit. which is not the same with competitions and bug bounties where

participants are incentivized by money and not that much about the protocol uh itself. Another perk of private audits is that you have control over who is doing those audits because you are the one hiring the team and you know perfectly where your money goes. Also uh another uh great advantage of having a security team is that you get a lot of um recommendations on how your code base is structured, how to reduce it in size, how to make it more gas efficient and overall how to make it more manageable, which are those small things which once you combine them together, you produce

more secure code. something that you don't get with competitions or bug bounties where the main focus is only books that are impactful. Uh and the last thing is that with private audits, you have the mitigation review baked into that format. Meaning that every time you get a report and you uh do those code changes, you get a follow-up review uh by that uh by those experts that make sure that your changes were made properly and uh nothing no bugs would slip into production and get exploited with competitions and bug bounties. you get the security report but after that it's your responsibility

to hire a security team which should verify uh that those changes were properly made and that's a common mistake when not done often teams uh make mistakes and they deploy faulty code and things get ugly with competitions uh the biggest advantage there is that you get a very broad coverage of your code Uh that's because anyone can join. These are participants with various uh uh security expertise, seniority levels, background experience which uh ensures that uh because they have such different perspectives, they can look at your code from different

angle and uncover different vulnerabilities which gives the breadth and depth of of the security review which makes it especially good for uh for code that is complex or very uh large. And finally, the bug bounties. As we already mentioned, they focus exclusively on deployed contracts, which makes them the only format that is meant to catch vulnerabilities in real time and also fix them in real time before the attackers uh find them and exploit them. And here uh bug uh the protocols can control what type of bugs they will pay for and for what type of severity

levels which gives them great control over their security budget and they can they know what to expect. And for uh final words, I would like to point out some mistakes that I would say are expensive because if not done properly, they uh will not only cost a lot from your security budget, but they would also lead to not uh to code that is not secure enough and that can get Uh one u example here is that sometimes uh teams deploy uh deploy code u use deploy code and then use security

service security service competitions without doing private audits which is a big no no because you get all of these submissions and all of these issues and uh they after they fix it they don't do a follow-up preview and it sometimes It turns out they did not fix the issues properly which leads to bad call that can get exploited. Another issue is running competitions first and then doing private audits. This is a waste on the security budget because what you want from private audits is to help you uh clear all immediate issues and structure the codebase better and only after that move to competitions where

your goal is to incentivize people to uh go deep into it. Spend uh a few days or a week grinding only on one single spot and find those deeply nested hard to find bugs. Uh another mistake that for example relates to bug bounties is that sometimes uh teams use them as a marketing move and they end up shooting themselves in the foot. I give an example u some smaller protocols and that's something I've seen like a few months ago. They uh they uh launch a bug bounty. They're very confident that their code doesn't have a lot of doesn't

have any issues in them because it was covered by two or three private audits. And because when you launch uh when you declare that you're doing a bug bounty, it has a lot of social engagement. This is how you uh earn the trust of your users because you show that you care about security and you're ready to continue paying to make sure your code is secure. And then uh bounty hunters they submit a critical which surprises the protocol. They don't have the money to cover the bug bounty and they ghost the uh bounty hunter which has a very bad effect because the hunting community is very small and words word gets out immediately that that protocol is not

reliable and doesn't keep up to its promises. So uh in the end you have to be genuine and really well prepared before launching bug bounties and make sure you can cover for the costs that would be related to it especially if critical vulnerabilities are uncovered. And this wraps up this talk and maybe in the next minutes if you have any questions I will be uh glad to answer. [Applause] Heat. Heat.