From red team to blue team: the hard life of DeFi protocols — engn33r | Twyne

Welcome, welcome to the talk. And here we are. Here we are from red team to blue team. The hard life of D5 protocols. Okay, let's see if uh okay so it's uh I will just say the slides are changing here but not here but that's okay.

I can just work with this one here. Uh so quickly today's agenda we have three main points to get through. Uh first I want to introduce the difference between auditor mindset and builder mindset. Uh secondly, we'll go into why audits don't make protocols fully secure. I should say fully secure.

They do help, but they're not a full remedy. And lastly, takeaways from transitioning. And uh I'll discuss my transition as we go. But first, world's fastest intro. I'm engineer do security and code, currently a dev at Twine, formerly auditor at Electtoisec.

I'd also like to thank Electtoise, formerly Y Audit, formerly Y Academy, because every year I present here, they have a new logo and new brand. So, this slide is filling up fast. It looks like I worked everywhere. Um, which is great. I don't have to even do anything.

First, um, auditor mindset versus builder mindset. Um, to describe briefly, I used to be a security auditor for Solidity smart contract code and then roughly a year ago switched to the developer side. And I'm here to talk about how that transition has gone. Um, in brief, you could say the difference between the auditor mindset and builder mindset is this. We have the virgin dev who can't fix all the bugs and then this Chad auditor who eats bugs for breakfast.

That's the summary basically. Um but let's let's dive deeper. So the auditors, they focus on finding problems. They find joy in identifying imperfections. They love the complexity, flex on crypto Twitter, give criticism, and then they always find bugs to become a hero.

And this is completely the opposite of builders who focus on solving problems. They're stressed by finding imperfections. They hate complexity. They are usually silent on crypto Twitter because you you know they're coding. They're actually doing work.

Um unlike the auditors, just kidding. Used to be one. Um they're receiving criticism and they're unfortunately sometimes leaving bugs in code and then they become the devil. So, it's like the the reverse side of the auditor mindset is the builder mindset. And even though these are reversed uh roles, they really shouldn't be enemies.

They should be friends as much as possible. Um some sometimes the incentives don't align. But um I wanted to try switching to the other side because I actually got uh a bit too big of an ego. I was giving criticism in everyone's code and I thought I can do better. I can write good code.

But well um anyway uh yeah. So when you start with auditing and then do coding, it's it's a great idea, guys. It's a great idea. You should definitely try it. Um, a little bit crazy because most people go the other way.

But the reason that I did it is something like this because when you're an auditor, when you look at DeFi, all you see is bugs, bugs, bugs, bugs. All this code has bugs. Why would I ever use this stuff? But when you're with a builder mindset, you're thinking about the next feature. you're thinking this stuff is cool.

We're building the future. We can do this together. And so for me, the shift was more of like a perspective shift to become more positive about the space. When I was just looking at bugs, bugs, bugs, bugs, I thought this whole space was just down only, but now it's up only, or at least that's how I hope to think of things. Um, and it really just comes down to a difference in perspective, at least for me, because when you look at these numbers on DeFi Lama, are these big numbers?

Are these small numbers? It's all perspective. You can say this is a lot bigger than 5 years ago. Or you can compare this to traditional finance and say it doesn't even matter. It's a rounding error.

Uh, so it's it's perspective. Um, and it seems apparently I'm not unique because there's two other at least two other former auditors turned uh developers. I guess it's like I don't know flavor of the season. So, uh, a bit of a shift. Um, and maybe that's because the audit market is in a bit bit of a a bare market right now from what I hear of former connections.

Um, I don't know if that's true. Again, I'm a developer looking on the bright side now. Um, but uh little did I know I was going from just the simple task of find bugs to building something that works and doesn't have problems and everything's efficient and it's a company and blah blah blah. So, I thought I had a hard job before, but no, I was the elephant going to the swimming pool. And yeah, well, now let's discuss where I am now, which is at Twine.

Uh, I'm not gonna show for long, but because everyone thinks I'm still in security, I have to explain I'm not. This protocol, I like to think of it as a a unique DeFi primitive. People use A, they use Oiler, and there's two types of users. There's users that deposit assets to get yield. And then there are people that deposit as collateral and borrow.

Now, at Twine, what we're trying to do is say these people who are depositors only. They could be borrowing, but they are not. And because this borrowing power is unused, it's capital inefficient. Other people can borrow with this borrow power. So we're making a layer 2 lending market where we are lending borrowing power.

So if you have assets that you are not borrowing against, you can let other people borrow your borrowing power and pay you more yield. So you already use a you get yield. Ah, now you can get more yield at twine. You use oiler, you just deposit. Ah, get some bonus yield.

you can lend out your borrowing power now. So, we see this capital inefficiency and we're trying to solve it is the protocol in a nutshell. We're also trying to launch this week. So, uh busy week. Okay.

Uh why audits don't make fully secure protocols. Um when I was an auditor, I thought auditors are amazing. We make everything secure. We are necessary in the industry. Blah blah blah.

Um that was a bit big ego of me and now I have a bit of a broader perspective because uh the picture is bigger than just that. Yeah, breaking breaking is definitely easier than building because I mean look at these guys. They're just having fun auditing over here in the corner and then like the builder does he look happy? No, he's doing real work. He's like building something important.

Maybe the house you live in, not with that wood, not in this region. Anyway, um so yeah, uh basically for security people, if you find a bug, you have success. And for builders, it's the opposite. If you h leave a bug, it's failure. And a single bug is easier to find than to avoid.

Um and this is a comment which I won't get into. You can read it later. But uh basically an explanation someone saying that bug bounties are actually easier than contests and private audits because to succeed in bug bounty, you just need one bug. And to not fail in audits or contests, you need to find all the bugs. So it's like a one versus all approach, let's say.

Yeah, I apparently am unintentionally auditing the uh presentation process here and uh found a bug in my own presentation. Maybe two, maybe two. I'll write a report and hand it to myself. Yeah. What's the bounty for this bug?

I don't know. Maybe maybe start a presentation auditing company.

Yes. Uh that's a good idea. Right after this is actually a pitch for my new startup

and there's

make sure your presentation goes smoothly.

There's a conference happening every two weeks. So exactly there's space.

It's summer season in Europe. Tons of conferences. You want your presentation to go smoothly, just talk to me. Yeah.

Why slides?

Why out it now? Why slides? New rebrand

working. Thank you. Okay, so um secure smart contract code is simply the minimum viable product for a protocol. So this is what auditors aim for like no bugs in your contracts. We'll make it secure.

That's great, but that's the cost to entry of any protocol and chain. This is like the minimum. This isn't like the holy grail. So this was one perspective change for me is like the audit is just like a mandatory checkbox. And uh yeah, it is important.

I'm not saying it's not important, but it's like if you don't do it, you can't go to chain. After you do it, now we can discuss more things. So really, this is a minimum viable product. And uh even if this succeeds, other things can definitely make the protocol fail. Um this is just an example of other attack vectors not related to smart contract flaws that can break a protocol, which now I've been having to think about a lot more because any of these things could break Twine and we have to consider all of them.

Uh this is just another example of things that can uh break protocols. As you probably know, Bybit got hacked for 1.5 billion a few months ago with multi-IG uh related issue or safe. Um Radiant previously basically the same bug and uh it could be you next. So if you're not following up on multi-IG best practices, uh beware.

Uh this is just another view. And yes, a lot of the top 10 incidents are smart contract bugs. I'm not trying to take anything away from that. Very important. But there's other vectors that I think will become increasingly important.

And the reason I say this is whenever there is a new technology, whether that be smart contracts, whether that be using a new material like carbon fiber, like aluminum, for the first few years, it's difficult to use the new technology properly. It's a new technology. People don't understand it. And it takes time for knowledge and processes to develop around the new technology. Now, in my opinion, web 3 is heavily based on web two.

And once the newness of the novelty in web 3, the smart contracts wears off, we will revert to what we've been doing with technology for years. It's another programming language. It's another type of architecture. And sure we will need to develop best processes and everything around this but at some point the newness wears off and we will just uh consider it uh standard technology like maybe cloud. Cloud might be standard now 10 years ago cloud was completely novel.

So uh yeah uh we revert back to the standard web 2 security threats in my opinion in the long run and these are still very very important that we must think about as a protocol. Uh audits omit onchain context. Audits are on the smart contract code before it's deployed. Now uh these are some of the things that are important uh when you're actually putting the code on chain. And uh when I say context is important, I'd like to remind every everyone last year there was this handsome smart guy presenting saying context is everything.

And uh you should have come to his talk last year because it was the same message. And uh I'd like to thank myself for the brilliant message. still relevant. Um, and I'd also like to say that the front end is is an attack vector that at this point almost no web 3 D5 protocols are paying attention to. If if you're a user, you go to the website to use a DAP, usually to use DeFi.

You basically trust the website. I mean, the process is basically like uh visit a front end, confirm you have the right URL, and then after you confirm the URL, you basically check crypto Twitter and say, is there a hack on this URL? No. Okay, let's put some money into it. Like you trust the URL 100%.

Uh DNS hijacking basically breaks this assumption. And there's many other attack vectors too with uh CI/CD injection of bad JavaScript. I can go on, but we revert again to web 2 security bugs that can fit in anywhere in the tech stack. So quick takeaways from transitioning. I know I don't have much time.

Um basically change is good. change gives you perspective on this space. Uh I have a very different perspective now than when I was an auditor. Um yeah, I'll just keep going because I'm short on time. And new perspectives help with learning.

So devs focus on functionality. Security comes later. I mean all these learnings I had from the developer perspective I didn't have when I was an auditor. And if I return to auditing, it will really help me understand what is a dev perspective like. So even if this journey ends up being I don't know uh let's say not a permanent change in the long run I'm still gaining perspective on how the industry works.

So change is good for learning. Uh writing code is very different from auditing. I learned this when we actually went to our audit and it it felt really uh different when I received the criticism on the code and wasn't giving it. It was like oh this is how it feels. I'm sorry.

I'm sorry to all the devs out there um that I did this to. And uh yeah, finally, there's just lots of opportunities in the space. Don't feel limited by what you're doing now. Um because it's a big and very quickly changing and growing space. So feel free to explore other options.

Um and of course, as many of you probably know, you see the same people later at other events. Um so yeah, just make sure that whatever you're doing, you consider uh doing it well. Keep your reputation. Uh don't scam people. Okay, in summary, um this is what I just said.

Basically, auditor mindset is different from the builder mindset. Um protocol security is very multifaceted. It is not just a smart contract audit. If you're building a protocol, you need to consider all the attack vectors, not just the smart contracts. Um and then having a new role gives you new perspective basically.

Um if you want to learn more about securing uh a protocol, I will be giving another talk web 3 security. Um but that is all for now because it started as auditing and now it's like all the attack vectors. So that's how I look now. Questions? [Applause] Okay.

Actually we have time for questions even with with all the difficulties. So uh let's start from there. So you talked about your struggles with uh with the actual technical aspects but what about the people? Ah cuz now you have to deal with those people full-time not just for like the three hours of presentation right?

Yeah my co-workers will probably watch this talk just so you know.

Okay.

Are we still recording? Just kidding. Um so when you're auditing you're just dealing with uh let's say developers for an hour or two and then you just deal with these technical security people and of course uh when you're in that environment you get used to only thinking about the technical side um now actually discussing with people about UIUX what do users want um how will users feel it's a very different perspective I think this again is just a new perspective I've learned about and uh it gives me a new uh a new view on how certain designs are not always optimizing for the technical side. You have to optimize for a multivariable equation. Yeah.

Uh you mentioned radiant and bybit and uh also how we will fall back once the technology matures enough we all end up writing sec more secure code and everything. uh we will fall back to the same issues that we have in web two and we will focus on mostly the same set of uh uh concerns. Uh what would you think what would you say is the primitive that uh DAP developers uh when it comes to front-end security radiant and byid uh should pay more attention to.

So we really I've I've asked around for what the front-end security best practices are in this space now. Uh I think uh web 3 is novel in this regard because if Google gets hacked and you see bad search results, you might visit the wrong website, but what will you see like more ads? You can't get more ads than Google. They're an ads company. So um the the impact from these things is much higher in web 3.

Uh I think that file integrity monitoring or some way of verifying that the front end that the user sees is identical to what's in the GitHub repo that that you build locally. For example, if you build the front end locally and you compare the diff with what's public for users and you confirm equality, in my opinion, we need an automated system for that just to like add a GitHub action and verify it. Um, we're actually planning to do this internally soon. Uh, other than that, I think uh, of course doing penetration testing on a front end is something that could be considered in the future. Um, but yeah, it's it npm is dependency hell.

I don't know what to say. That's uh that's from the pentesting side. So file integrity monitoring is my short answer.

Thank you.

Okay. Uh we have time for one more question from Elen.

Uh so which role do you like more? That's the first thing. And the second thing, do you think it's better to be auditor than become developer or the other side? Like what's easier and what's your perspective? Next question.

Uh they're different. Uh it depends on your personality. I do at this point miss security a bit. Um now that I see that developer role is much more difficult. Um but at the same time with uh with a more difficult challenge comes let's say some additional positive feeling when you feel there's some success.

Yes.

Okay. Let's give engineer a big applause.