How to play as a JSR at Spearbit

Not a guide but my experience so far

After starting my first audit at Spearbit, I found myself lost for a moment; there was a lot of documentation on some subjects like how to write issues, which knowledge Junior Security Researchers (JSRs) need to have, etc.

However, some points needed to be clarified before finishing the first audit. Some weeks later, some other auditors asked me the same questions. So I decided to bring a little light to this. Let’s dive into this.

First of all, some of you might be asking who I am.

I go by the nickname of Deivitto. I’m a Software Engineer & Blockchain Security Researcher. Bug hunter and challenges enthusiast. Some other details can be found on my Github or Twitter.

Let’s jump into the article!

Why am I writing this?

When I joined my first audit with Spearbit as Junior Security Researcher (JSR), my first thought was:

“Ok, let’s jump into the work!”,

The next one was:

“What is everything I’m supposed to do in my role? Where should I start lmao”.

While I could find a lot of information on how to write issues for Spearbit, which responsibilities, and which knowledge I must have, I couldn’t find the exact range of tasks I was supposed to perform.

Later, some other auditors asked me similar doubts.

Luckily, after a few questions, the Spearbit team and Lead Security Researchers (LSRs) provided me with the needed knowledge (better questions, better answers).

How not to panic at Spearbit audits as a new member.

First, auditing for Spearbit wasn’t different from my previous audits at platforms like C4 or Sherlock.

It’s just another audit, so let’s be straightforward: read the code, look for issues, read the documentation, understand each invariant and check if they hold, and find concepts that are broken or have a minor issue. You are an auditor; you are supposed to act as such.

And well, you can also run some static analysis or other tools to look for common issues or improvements. Each approach is different, I prefer doing this to catch first typical stuff and get a basic understanding of what the code is supposed to do.

This is not a competition; this is a collaboration.

If you, like me, come from C4 / Sherlock contests and not from some audit firm, you know competitive audits very well. However, you’re now part of a team, not part of a competition.

Luckily, I had audited alongside a team before.

One thing I noticed auditing with Bronicle at C4, it’s how good it is to audit with other people that not only understand what you say but fulfill some missing expertise with their own.

So what are you supposed to do in a team audit?

First of all, audit. Yes, as I mentioned, this is just another audit. Look for issues and discrepancies. Show up your skills and knowledge.
Second, communicate, say everything clearly, and let everybody know if something looks suspicious, issues you find, attack vectors you imagine, or let your questions arise in chat. I prefer to look silly once, not knowing something valuable for ego reasons. Ego may cost users millions.

If you find anything someone should take a look into or probably has a better understanding, (tag them: @user, cc: @user)

Read all your team’s new comments. Also, some audited teams may answer your comments; keep the communication. This is something I recommend doing daily before looking for new issues.
Validate or break the comments, don’t ignore them; you may understand something that could be a finding for a new issue, maybe even a critical 👀.
Everything you find might be addressed or discussed on the Discord channel related to the audit or commented on in the PRs of the file.
Write issues. Not only yours if you have time and, like me, you are a JSR, but others. This will save time for more experienced auditors, and also it will teach you. You will learn something new from LSR, knowing more of what they think is valuable for your following audits; you are in a direct channel with some all-stars of the field.

You may find more guidance in the Spearbook audit process.

Other valuable things that give some value and save time for other members.

Do some call graphs and other valuable schemas and share them.
Check unit testing is done correctly and test coverage covers everything; you may find something if you need help.
Fuzz / symbolic execution. If you’re good at it, do it.
Research some concepts and validate some ideas. Confirm libraries are doing what they should, check compiler version changes, etc.
Check changes between the last versions of the code and the actual version.
Correct typos in the issues. Unify style (usually discussed at Discord).

After all, a close-up meeting will happen. Prepare to comment on your Critical, High, and Medium issues and some Low issues.

What’s next?

Two weeks of following up fixes. First, if you already didn’t, put alerts on for the fixing repository.
Now, just check the changes so they are done correctly.
If someone else has checked those changes before you, and you agree, add a thumbs up / comment to let them know you agree (or not).

Some extra hints

Activate notifications at the Github repo.
Even if some issue was fixed after the start of the audit, it is good practice to address it for the sake of the knowledge of all users (you can mention it was fixed at PR#XX).

Finally, thanks for reading, and I would like to thank Spearbit Team for all the effort they put into giving a fantastic audit experience to clients and auditors.

Also, I’m grateful for all the knowledge and leadership provided so far until now by amazing LSRs such as @TheSecureum, @GerardPersoon, @cmichel, and @saw-mon-and-natalie.

View original.