Journey to Becoming a Top Security Researcher

Ziga's journey from a novice to a top security researcher showcases the importance of self-assessment and continuous improvement.

### From Novice to Expert: Ziga's Journey in Security Research
* 👨 ‍💻 Ziga, currently ranked **number two** on Kan's leaderboard, shares his transformation from a beginner in cybersecurity to a **proficient security researcher** at Spearit.
* 📈 He recounts his early struggles, revealing that he initially performed poorly in competitions, such as earning **only $5 in his first contest** and ranking **over 100th**.
* 🔍 After acknowledging his shortcomings, Ziga developed a structured approach to improve his skills, focusing on **understanding the goals of protocols** and **visualizing their workflows**.
* 🛠 He highlights the significance of maintaining **good energy and focus**, advocating for proper **sleep, nutrition, and regular breaks** to enhance productivity during intense work sessions.
* 💡 Ziga emphasizes the importance of manual code reviews, encouraging participants to **explore unfamiliar code areas**, as they often contain **hidden vulnerabilities**.
* 📚 He created a knowledge base to document vulnerabilities and lessons learned from each competition, ensuring he **extracts maximum value from his experiences**.
* 🚀 By applying his new methodology, Ziga achieved **impressive rankings** in subsequent contests, including a **sixth and fifth place** in early 2024, demonstrating the **effectiveness of his approach**.
* 🌟 Ultimately, he advises aspiring security researchers to **enjoy their journey and find personal fulfillment in their work**, as **passion is crucial for long-term success** in the field.

all right, let's try that. Okay, I think we have it working now, so let's give it like a minute or two, and then we can get started. Cool, I can see some people jumping in, so maybe like 30 seconds also. All right, I reckon we're good to get started if you are, so we can go. Yeah, yeah, let's go. So thank you to everyone who's jumped in to join today. We've got another seminar for you, this time with Ziga, and basically just going through his journey to becoming a security researcher. He's currently number two on Kan's leaderboard, and I think I remember in maybe July, was it, that we did the research highlight, and yeah, you've just kind of shot up the ranks pretty much out of nowhere, so definitely interested to hear how you did it. Yeah, so that's the point of this seminar, so it's all right, definitely over to here. Okay, so welcome everyone, and thank you, Cantina, for this seminar. So today, we are going to talk

about my approach that I use to basically go from newbie to security researcher and uh lead almost almost lead the the Cantina platform uh Zach is still in front of me but so close some point I will do it I will I will rank first sometime so yeah that's it so in this seminar we are going into four parts uh the first one I will present myself and we explain you from where I'm coming uh and then we are going to see that at first I was bad really bad and then once I understood that I was bad I did something that maybe you don't know you don't do that helped me a lot to really get get good uh and uh yeah and break more and more cut bases and in the last part we will see the result of the methodology that I used uh during the last months so first I'm Z I'm currently a security researcher at Spearit. I'm also an instructor at R Skills uh giving some course about Rust and before that I was a student at

rare skills, especially in the Solidity boot camp. And so, as we said, I'm currently on the Contin leaderboard. So, before 2024, I was a cybersecurity student in Web 2, but it was not that technical. It was more about analyzing risk, so risk assessment, and it was really not that technical, not as much as what I do today. And so, during the studies, I worked as an apprentice in securing embedded systems. And during my studies, I did a really interesting project that has brought Web 3 to me. It was the post-quantum blockchain that I'm going to detail a little bit because I think it's pretty interesting. And after this project, I decided to follow the real skill Solidity boot camp. So, that was 2023. So, let's talk a little bit about the post-quantum blockchain project that I worked on. Most of you know that when you are interacting with Ethereum and you are making a transaction, you are signing it with the SIGP, K1, elliptic curve with the ECDSA.

algorithm signature, uh, but there exist other blockchains such as Solana or Near that allows to use another algorithm that is named, uh, EDSA. And this is, this is, this is still using elliptic curve, but a different, a different one, uh, so yeah. Theon Quantum blockchain is based on Near because it uses, it allows to use two types of keys, which is pretty interesting. But the issue with all these keys is that tic curve, uh, cryptography could be broken by a quantum computer. This is so basically, we take a quantum computer that is really working because today it's not the case, and we take the show algorithm, um, and with that, we are able to break all the security that is allowed by blockchains nowadays. So yeah, uh, the day a quantum computer works, uh, like it could break every secret key that is used on any blockchain, so that's a problem. And, uh, so with some friends, we decided to work on a project named the PQB post-cont blockchain, and the goal was to use a signature algorithm that is

different than the others. It does not use the same mass behind the thing. So, in this case, we were using the Falcon algorithm that is using lattices to do cryptography. And with that, you can sign the transaction, and these specific masses are not shown to be broken by a computer for now. So, the goal would be to really secure against a quantum computer. The issue with that project is that a signature from an elliptic curve is pretty small, like 64 bytes most of the time. But with this type of algorithm like Falcon, it was 660 bytes. So, it's more than 10 times more, so it's not usable in production. So, that's it for this part. Okay, so now let's see what was the start of my web3 security audit journey. So, my first contest was Spark in on CodeHS, and I earned like $5, which is really good for the first one. And yeah, there was a lot of

people, uh, competing in this competition. So, yeah, I ranked like more than 100. It was pretty bad. And, yeah, my second one was in November 2023 at the start of Cantina, and it was super form, uh. So, yeah, I ranked as 21st, but it was not the... I think I had this rank because there was not that much people on the platform as it was pretty closed at the beginning, uh. I can show you the bug that I found. It's like, Hey, uh, so we are in a transfer from function basically, and we are checking that the allowance is given to the current color, but we are decreasing the allowance from another address, which doesn't make any sense. So, that was that easy. This was an easy BG, and it was found by more than 10 researchers, so it was pretty easy to find. So, yeah, super form was my really first contest in which I committed at 100%, and seeing that I ranked 21st is not good. And so, I, yeah, that was the turning point.

in my journey because I said, Okay, I'm bad. This is a proof that I'm bad. I can't make it even more clear. I'm bad. So, from this point, I will just work to become good. And so, that's what we are going to talk about right now, and I think it's the valuable part. So, yeah, I asked myself some questions. Why am I bad? Most of the time, it is because I don't know what to look for, or I don't focus enough. It can also be, I'm missing vulnerabilities that I know or I've met before, but I can't use that knowledge in a new context. And this is really bad because you are just losing time and money. And yeah, the last point is that I don't have experience. So, these are the reasons why I'm bad. But yeah, now that we have identified them, we can just work to make them disappear, basically. So, yeah, we are going into the approach. Let's say that we have a new

competition coming. The thing to do is to, yeah, we can answer to the problem. I don't know what to look for first. You need to understand the goals of the protocol. Like if it's a lending protocol, I want to learn money. But then you will have to visualize how it works. I like to do drawings, but I know a lot of researchers don't do drawings. I think it's really, you should do drawings if you like them. If you don't do like them and they don't bring value to you, you are just losing time doing them. Then you can avoid it. Because if you don't like what you are doing, then it makes no sense and you will not succeed. But once, yeah, once you really understand how it works, you must identify where it could break. Like for example, if I retake the lending protocol, I know that I have a deposit function, a withdraw function, something to borrow, one to repay, and a workflow to liquidate.

so basically these five workflows are like the most important ones in the code base, and all the other things are more in the periphery of these five workflows. Like, for example, there can be admin functions that are just setting some values or view functions which may not be important. So once you identify those five workflows, you can say, Okay, I know that there exist ring issues. So ring issues can happen when I'm depositing U liquidity or withdrawing. So yeah, you must identify where it could break, and for example, external integration. Yeah, I give some examples or calculations. So I like to call this stage the threat model. So it's really coming, it's really the start of a new competition, a new code base that you have to edit, and it will, yeah, basically, it's the beginning of all your understanding of the code base. So yeah, then the other issue that I talked about was I don't focus enough. I think that having energy is really important because if you have

good energy. You can easily focus more easily, and uh yeah, if you focus more and in a better way, you will be better at the end. So for that, I like to have good sleep. Uh, I like to eat LC, especially on lunch. I'm not, I can feel sleepy if I eat a lot of carbs, uh, so I avoid them at lunch. And uh yeah, being fit, like going outside, walking, doing sports, is really important, especially when you focus for extended hours. Like try to take a break, go outside, take some fresh air, and you will come back even more focused and energized. So yeah, that's the second point. Something that is uh not easy to understand at first. You don't need to be deeply focused 100% of your time because first, your brain can't do it. Uh, like studies show it. Uh, and for my personal case, I do really deep focus uh work only four hours a day, and the rest of it uh is is not uh I'm not doing nothing. I'm just

preparing my next deep work slot. So, this is really important. You must have really some slots in which you have no music, nothing to distract you, like no music. If you really focus more by having some music, then do it. But yeah, you must really focus on one thing in this deep work slot. And when you are in this deep work, you must deload your brain. Like, if you are thinking about something and you want to check it, but you are also checking another thing at the same time, then you should not keep that in your brain. You should take it on notes because if you keep it in your brain, it will just stay here, and you will be less focused on what you were doing before. So, yeah, that's important. I like to take notes on Notion, for example, but you can do it on a markdown file or anything. And especially if it's something that you can check without being deeply focused, then put it on the notes, and you will check it in.

the later when you will be less focused, and you don't need that focus for this specific task. Yep, and uh, yeah, uh, so this is it. Yeah, uh, this is what I said: small things that don't require a lot of focus. You can just postpone it to check it later. And yeah, the last point to find bugs. You must dig into code areas that you don't understand and that you don't want to dig because it's too difficult. Uh, if you don't want to dig it because it's just an admin function, and uh, uh, at the end, it will end up being a low. Then I understand you, but if you are feeling that you don't understand what is done, you must really dig in that part because, yeah, for sure, if you don't understand it, there are a lot of changes that the developer did not understand it also. So yeah, you will find bugs in these code areas for sure. Uh, so yeah, this is the most important part of your contest. Uh, like

this manual review will bring maybe not all the bugs because, uh, in the sh model, you may have some small bugs that are easy to find, but for really difficult ones, the ones that allow you to go high in the rank, uh, you must be really focused on that manual review part. And yeah, I like to make this double um arrows because you can go from manual review into so manual review will bring you more knowledge about the code base, and then you can think about other attack vectors, new attack ideas, uh, that will um feed your manual review at the end. And yeah, you can go back and forth between these two parts. Then once the competition ends, there will be the results that will be announced, and here is the most important part of the process, I think, uh, it's some people call it the feedback loop. Uh, so yeah, I'm missing vulnerabilities that I already know or that I've met before. Um, for that, I what I do is to put my knowledge in a document so that I de my brain once

again and I'm sure that, uh, yeah, so this can be a waiting template or a checklist, so you can have your own checklist for it, and, uh, yeah, with that, you ensure that you will not miss it because just because your brain will forget it or will not think about it at the right time, like you did not forget it, but you did not think about it at the time it was required, so just put it on some notes, on a knowledge base, and you will check it, uh, during your audit. You will take time because it's not something that you require deep focus. You can put it into the time slot where you are not that much focused if it's just something to check. So we end up with this, uh, process in which, like, after the competition is even more important than the before because, uh, you are already preparing the next audit with that. And the last one, uh, I don't have experience is an issue, but it's not really an issue.

because every competition you are participating in increases your experience. So, you have experience, but the main problem is that you are not extracting 100% value from this experience. Um, so yeah, that for me, it was the problem at least. And so, with that problem, the point because I have experience but don't extract 100% value from it. So, the thing that I do after the result of a competition is to understand every issue that I missed. So, this is the first part because if I don't understand the issue, for sure I will not be able to reproduce it. But then you have to think about why you missed this issue. And so, this is not about the code base anymore, this is about you. So, is it a lack of knowledge or maybe you didn't think about that? So, that's what I was talking about for in the knowledge-based section. Uh, and yeah, uh, for example, you did not dig enough in a sensitive code area that you identified because you were tired, for example, or

you may not have identified some part of the code as sensitive, and so yeah, this is it. You must find the root cause why you didn't find this specific issue, and once you know why you missed this issue, you just have to modify your work, your way of working, your work process to be sure to not miss it the next time. So, as said, the knowledge base is really helpful for that, especially when you audit. You need to identify code areas that are potentially sensitive, so this was in this model parts, and you use your knowledge base to know which parts are potentially sensitive. And so yeah, it helps read your knowledge base but also your intuition. Like, it's not always about the knowledge base and the knowledge you have; it's just you have to feel where the bugs are, and this comes with multiple audits. Once you identify patterns, like today, just by understanding how the protocol works, I know approximately where, like, I don't know where the bugs are, but

I know where they will be most probably, and this is it. At the end, your experience is the most important thing because it really impacts everything in your audit. But having some knowledge base will help you a lot. So, yeah, if you have to really get something from this seminar, just try to get 100% value from all your experiences, and you will level up for sure. So, yeah, to summarize it, you must create your own methodology, the one that you like, because the one that I use today is not the one that I used six months from now, and it may change in the upcoming months. And so, this is just for myself, but for sure, I'm not auditing in the same way as every other audit. Visualizing the code base is really important because when you understand how it works, then you can identify where it could potentially break. So, this is completing the think about potential issues section. And yeah, focus deeply because you need it for sure where this is a job in which you really need to focus hard.

to find Buds and uh yeah I will not let you down with that extract as much value as possible from all your experiences. This is the most important thing from this seminar. And so, by applying all this approach that I detailed before, uh I went from Super form in November 2023, in which uh yeah it was pretty bad result. So, I took the whole December months to prepare and then in January I came back with a Cod arena in Cana contest. So, Opus and Olas and uh in the first one I was ranked six and in the second I was ranked fifth. So, it was the second one was on Solana and the first one was on Koo. So, it was my first time auditing both the yeah the February month was really good because uh I ranked really good in in blast. So, yeah I ranked six because uh in the leaderboard on Cantina as there was a team before me. So, they are taking two ranks instead of one because they were team. So, yeah but yeah by applying this this process that Loops

uh, and you will get more and more efficient, uh, and better in each iteration of your process. So, you will get better at every competition you do until you rank first, and then you can't improve anymore. But, uh, I'm not sure that you can rank first in every contest. It's pretty hard to do, uh. And so, I continued my, uh, my increase in results by ranking two times second in the first in the same months in March 2024, uh, and with pretty good earnings in this case. And that's it. That was awesome. Thank you. I have a couple of questions from my side, and I've seen a couple in the, um, in the post as well, but just a, just a reminder that if anyone wants to ask any questions, pop them in the reers, and I can ask them. I'll start with mine first, uh. So, the first one is, um, I know that you're now an Sr with Spearit. Do you approach reviews any differently to competitions, or do you buy the same, um, methodology that you outlined there? This is really interesting as a

question. So, yeah, I did my first spe review a month ago, and so, yeah, I just met the lead security researcher, and we were talking about this difference, and I don't use the same approach because in competition I have to find the bugs, while in noit I can use the team that is responding, and I can use the shotgun approach. It's like, Okay, I'm reading this code, I'm not sure what it does, so I put a comment, and the sponsor, like the client, is going to respond to it and will explain things if I don't understand them, while in the competition it's more, I have to find the bug, so I have to understand everything on my own. I can ask some questions, but I will lose time, and yeah, in this case, it's different. In all the rest, it's pretty much the same. Like, I want to visualize the code base, how it's working. I like to do drawings with function calls, and so, yeah, that helps me a lot.

during the manual review because I'm using some extension from VS Code to integrate with Doio, and then I can split my screen in two, having my drawings on the right and my code on the left. And then by double-clicking on blocks in Draw, I can just um, so I will, the code appears on the VS Code. So this is the I can share the extension if someone wants uh, but this is on the VS Code Marketplace, and this is really useful to navigate. So with your drawing, you visualize your code base, and with this extension, you can just navigate it easily. Yeah, that's pretty cool. That's pretty cool. And then a follow-up to that question, more of a fun question um, do you prefer reviews or competitions? Do you know yet which you prefer? Uh, that's a tricky question. I yeah, I think competitions are really cool because if you are good, you rank well, while it's not that transparent in a review, in a private review. Yeah, the competition like taps into human

psychology of wanting to win, which is how we got here. And then one more question from my side, and I'll have a little look at the replies. But you spoke a lot about focus earlier on in the presentation. I guess this might be a tricky question too, but would you say that anyone with enough focus can get good at code review, or do you think like some people are just wired that way? What do you reckon? Yeah, asking for a friend. Yeah, I think that, for sure, having some programming experience is useful. But yeah, at the end, we are just like, I don't, when I talk to people, I don't like to, to people that are not in the space. I like to say that I'm just understanding a logic and trying to break it, but this logic is just code. So if you can translate this code to the logic, and I guess everyone can understand a logic and break it, so this is just, this is just the fact that it is code and it afraids people. But um, yeah.

just the form that the logic comes in. Yeah, yeah, cool, cool, cool. All right, I'm seeing a couple of questions in the replies. So the first one, how did you get so good at Photoshop, and where can I learn? Asked someone about your photoshopping skills. I'm not using Photoshop because I'm on lit, so I'm using it's that's which is yeah awful. That is the alpha. Don't use don't use Photoshop. And then the other question was you mentioned between I think it was super form and what was the next one Opus and Alis or maybe it was between it was during the period in December. Yeah, December. What did you do during that preparation phase between November super form and January Opus and allas like what did you do to prepare over that time. Okay, so yeah, it was preparing this W approach because it does not it did not exist or yeah I wanted to create my own thing. I know that a lot of researcher are posting their process how they work but I don't think that it is something.

you can copy and paste from people to people, and it just works like this. I had to build it, so it took months because I had to build my knowledge base, my feedback template, because I have a template for every contest that I do. Like, I have a feedback thing, I have a template for the audit, so yeah. And I built everything in December, and then it moved a lot thanks to the feedback loop. Yeah, because it... yeah, for... don't try to make it perfect in the first round. It will become perfect to you because it's for sure what you are doing will not fit to me. And yeah, you will get better and have better tools, and yeah, that's it. Yeah, I like that. So, you spent that time basically learning the best way to set it up for yourself, and then creating the templates and outlines that suit you best. Awesome, yeah. And sometimes I receive some messages about, Can you share me your process? or things like that. And yeah, I can do it if you want.

but you will not apply because, uh, it's not yours. You are not proud of it, or, and, yeah, it doesn't give you any happiness, or, or what. And so, building your own process will make you better, and you will really enjoy your journey because you are getting better, but it's not because of anyone else. It's just because of yourself, and you have built everything to become good. So, yeah, I love that. Cool. I think that was all the questions and the replies. Um, yeah, thank you. Thank you so much again for this. I see some right now on the, oh, maybe on your post. That's a good point. Yeah, on the space directly, like, there is, how did you prepare to do competition? Did you already got experience in s? Um, so, I did not get any experience from Sana, but I have experience in Rust, which really helps. Um, but, yeah, Solana, the thing is, you may know Rust, but Solana has a really strange, compared to Ethereum, way of handling the data. Uh, in Ethereum, when you have a contract, your code and your data about this code is really

attached while in Sana it is two different things, and you can use different data with the same code. Uh, so yeah, there are a lot of issues with that. Uh, but reading the docs and understanding how it works takes time. Uh, I was pretty happy to rank this good in INAS, but yeah, now that I have done multiple audits in S, I feel more confident for sure. But yeah, S is pretty different than E. Can you see any more questions on your side? I'm just having a look through now. Yeah, there is someone asking how did you learn about new vulnerabilities or way to look at them. Uh, and he also asked if I read solo report. Uh, I don't read solo report. I may have read once, one or two, maybe, maybe two, but uh, that's not something that makes me feel. Yeah, I, I don't like it, so I don't do it. Uh, but yeah, the thing is when you are reading a solid report, you don't have the, you don't understand the protocol behind it. Uh, and you don't understand

how it works. This is the part I was explaining in the threat model. Uh, and if you don't have that knowledge, how can you understand the issue? Uh, and be able to ident ify. Would you have missed it in these conditions? Yeah, basically, it's just taking something out of context and trying to understand it. And you can't apply it to yourself because you were not there to work on this audit. So, yeah, just my advice would be to stop doing solo reports reading. Just take one contest that you like or inspire you at the time. Do it. Try to understand everything. Try to fun. Try to find bugs. You may be surprised because you find something that you didn't expect. Or, and once the results are out, you can just take those results, analyze all of them, and this time you have the context because you audited this code base. And then you can apply what I told before. Uh, analyzing what did you miss it and increase in that. And you are also asking how to find ways to look at them. You will see that by analyzing bugs.

that you missed. You will for sure identify new attack vectors, but you will have some intuition, some attacker mindset that helps a lot in finding bugs. So, this is the thing I was talking about when I say that now, just by having the way the protocol works, I can identify where it can break, where it has the most probability of breaking. So, yeah, this is coming from this intuition that you build. You can't read some article and get it; you have to work it, and it comes with time and effort, learn by doing. And there is the last one: do you do multiple contest audits in parallel? I guess because, yeah, I do, because I think that most of the bugs I found are in the deep focus time that I talked about, and the rest of the time that I have, it's not that focused, and so I can prepare my next audit during auditing another one. So, it's just, yeah, I have some, I can do multiple at once, but as long as the DAT

Focus sections are like properly deep focus. Yeah, yeah, I gotta cool. All right, one last call for questions. You've got 30 seconds to ask them if anyone's got anymore. I think we might be good. Yeah, I think there is some delay. Yeah, now this has been awesome. And um, I will be uploading it to the Cana YouTube channel as well for people who weren't able to join live. Any um, any parting words of wisdom from yourself s. Oh, can you repeat please? Did you uh, did you have any like last final points um, anyone listening um, yeah um, I think that the most important thing is that you must enjoy your journey. If you are, I saw some tweet today about someone saying that he didn't don't like what he do but discipline helps him. I I think that having some discipline is important because you can't enjoy 100% of what you are doing but for sure if you don't like what you are doing for example you are just here for the money.

or you will not enjoy it, and it will not work at the end for sure. Uh, so just find the way that you enjoy the things, and I think security research can be, um, yeah, like people wants to Ed it because it has a lot of money, but I guess some people don't even like it, uh, and may prefer developing or anything else. So yeah, that that's that's my point. Just try to have fun in what you do, you do, and because at the end this is what matters. Beautiful. I agree wholeheartedly. Thank you again so much, and I will talk to everyone later.

The Security Researcher Journey with Zigtur | Cantina

Cantina

Ziga's Journey to Becoming a Security Researcher

Ziga, currently a security researcher at Spearit and an instructor at R Skills, shares his rapid rise to the number two spot on Kan's leaderboard.

His journey began with a non-technical cybersecurity education and an apprenticeship in securing embedded systems.

A pivotal project on post-quantum blockchain led him to the Solidity boot camp, where he gained the technical skills needed to excel in security research.

The Falcon algorithm, using lattices for cryptography, aims to secure transactions against quantum computers, but its larger signature size makes it impractical for production use.

The speaker's web3 security audit journey began with a $5 win in a competition, leading to a turning point after ranking 21st in a later contest.

Identifying reasons for their initial struggles, the speaker emphasizes the importance of understanding protocol goals, visualizing workflows, and identifying potential vulnerabilities for future success.

Key Workflows and Focus Strategies in Codebase Management

Identifying the five most important workflows in a codebase is crucial, as they often determine potential issues.

Maintaining good energy through sleep, diet, and physical activity enhances focus and productivity.

Deep work slots, note-taking, and tackling difficult code areas are essential strategies for finding bugs and improving understanding of the codebase.

The Importance of Manual Review in Bug Hunting

Manual review is crucial for identifying difficult bugs that can impact rankings, and it provides valuable knowledge about the code base.

The process involves a feedback loop, where documenting missed vulnerabilities and using a checklist can help reinforce learning and improve future audits.

Gaining experience from competitions is important, but understanding the root cause of missed issues and modifying work processes is key to extracting maximum value from that experience.

Gaining experience is crucial for auditing success, and developing a personal methodology is key.

Visualizing the code base helps identify potential issues, while deep focus is essential for finding bugs.

The approach to reviews differs from competitions, as collaboration with the team can provide clarification and support.

Integrating Drawing and Coding with VS Code

The speaker uses a VS Code extension to split the screen, allowing them to view drawings and code simultaneously.

They find competitions more appealing than reviews due to the transparent ranking system.

The speaker believes that while programming experience is helpful, anyone can learn to understand and break down code logic with enough focus and practice.

Creating your own process is key to personal growth and happiness, rather than relying on external factors.

Experience in Rust can be helpful, but Solana's unique data handling can be challenging.

Instead of reading solo reports, focusing on a contest and analyzing the results can provide valuable context and help identify missed issues.

The Importance of Intuition in Bug Hunting

Developing an attacker mindset and intuition is crucial for identifying potential vulnerabilities in protocols.

Performing multiple audits in parallel can be effective, as deep focus time is essential for finding bugs.

Enjoying the journey and finding passion in the work is important for long-term success in security research.