Introduction

Your bug report has just been paid. The funds are in your wallet, your rank on the Immunefi Leaderboard has increased, and you feel fantastic.

But it’s not over yet.

While it’s nice to receive funds for your hard work, it’s also nice to receive public recognition for your bug find, especially if it’s a technically complex one, and especially if you’ve made a lot of money.

In this article, we’ll help you answer three of the most important questions:

1. What is a bugfix review, and why should I write one?

2. When am I allowed to write a bugfix review/go public with my bug report? [important new rules here!]

3. How do I write an excellent bugfix review of my find?

The most important of these questions is the when. Today, we’re introducing the concept of Responsible Publication, which completely changes the publication game and is mandatory reading for whitehats on Immunefi.

What’s a Bugfix Review?

A bugfix review is Immunefi’s terminology for a writeup of a bug that’s been fixed and paid (or meets certain other very specific cases). We decided to call it a bugfix review to separate it from the other commonly used term ‘postmortem,’ because postmortem literally translates to ‘after death.’

But in this case, the whole point of the bug report is that the whitehat is saving the project from damage or death. So we decided to call it a bugfix review, and that term has caught on around the community.

Why should I write a Bugfix Review?

A bugfix review is worth writing for several reasons.

1. It boosts your reputation.

Bugfix reviews are a fantastic way to give an in-depth technical analysis of the bug you found and to provide details about your win, such as bug severity, payout amount, project, fix, etc. It’s a great way to turn bug hunting into a reputation-boosting activity. After all, when real funds are at risk, web3 bug bounty hunters are heroes, and regular users of crypto love to check out the Immunefi Leaderboard to see a list of the best of the best in the industry–and indeed the whole world.

2. It helps upskill the community. Giving back is always good.

Not a single person has learned bug bounty hunting without reading helpful resources created by others before them. If you’ve been helped by those resources, it’s always a good idea to pay it forward. It’s one thing to read hypothetical examples of bugs. It’s another thing entirely–and so much more useful–to see examples of real bugs in the wild.

3. It shows the project’s community that the project takes security seriously.

Virtually every public project that has ever existed has had bugs. We know it, whitehats know it, blackhats know it, projects know it, and project users especially know it.

Project users love seeing whitehats rewarded for their hard work in saving their funds. It makes them more (not less) confident in the project because they already know every project has bugs. The difference between projects, then, is which projects are actively taking steps to fix those bugs and succeeding in doing so.

Having a bug bounty program that actually results in fixed bugs is a great success, as the alternative almost certainly would have been exploitation.

When can I write a bugfix review?

The most important news we have to share is that the rules for publishing bugfix reviews and sharing information are changing. We have begun rolling out an enhanced system to new projects on Immunefi called the Responsible Publication Policy.

Since every project is different, we are allowing projects to choose their own publication category that suits their needs. Publication categories determine what and when whitehats can publish bugfix reviews or info about their reports on social media, ranging from ‘transparent’ to ‘notice required’ to ‘approval required’. This information will be clearly displayed on each bug bounty program page in the Program Overview section.

To get a better understanding of each publication category, you can read more about the policy here, which has a helpful table at the bottom to cover all cases of when bug reports can be published and what kind of information can be published.

Which projects have Responsible Publication Categories?

New projects onboarding to Immunefi must choose a Responsible Publication category for their bug bounty program.

However, we intend to roll out the Responsible Publication Policy to all projects on Immunefi by the end of 2023. For projects that do not have any mention of restrictions or Publication Categories, the Legacy Publication rules apply, and those rules can be accessed here. In general, under Legacy Publication rules, when your bug report is fixed and paid, you may go public with the report at your convenience. However, you are encouraged to coordinate with Immunefi and/or the project on your publication.

How does Responsible Publication work in practice?

The Responsible Publication Policy is comprised of two parts: Global Standards and Publication Categories.

Global Standards are standards that apply to any and all Publication Categories, so it’s important to read the Global Standards closely.

As for Publication Categories, we have the following:

Publication Category 1 (Transparent): Whitehats may publish information about their fixed and paid bug reports once they are fixed and paid. It is recommended that whitehats send any publication they want to make to projects for review in the bug report submissions thread, but it is not mandatory.

Publication Category 2 (Notice required): Whitehats may publish information about their fixed and paid bug reports, provided that they give projects 21 days to review and provide input about the publication in the bug report submission thread before they publish.

Publication Category 3 (Approval required): No bugfix reviews may be written without the project’s explicit consent given in the bug report submission thread.

If the information in this post ever differs from the Responsible Publication page itself, the Responspible Publication page is the source of truth.

What about Social Media?

Posting on social media is different from writing a bugfix review, so slightly different rules apply.

Publication Category 1 (Transparent): Whitehats may publish information about their fixed and paid bug reports on social media when the bug is fixed and paid, including payout amount, severity, project name, etc.

Publication Category 2 (Notice required): Whitehats may publish information about their fixed and paid bug reports on social media 21 days after the project has had a chance to review the post. However, you don’t have to wait if you just want to mention that you were paid, the amount paid, and also the severity of the report.

Publication Category 3 (Approval required): Whitehats need explicit approval from the project to post any information anywhere about fixed and paid reports. However, screenshots of the report may be immediately posted to social media, but they can only contain the severity of the paid report, not the payout amount or project name.

How can I write a Bugfix Review?

The best way to learn how to write a bugfix review is to look at examples.

Here are a selection of some of our favorites. You’ll notice tthey do an excellent job of presenting the basics of the bug report, namely the severity of the bug, the project’s name, the payout, the impact, how they found the bug, and then give a detailed explanation of the technical side of the report.

• https://medium.com/immunefi/balancer-logic-error-bugfix-review-74f5edca8b1a
• https://medium.com/immunefi/silo-finance-logic-error-bugfix-review-35de29bd934a
• https://medium.com/immunefi/dfx-finance-rounding-error-bugfix-review-17ba5ffb4114
• https://medium.com/immunefi/aurora-improper-input-sanitization-bugfix-review-a9376dac046f

Once you’ve read through them, you’ll start to see at least some commonalities. Here’s a common structure that we follow when writing our bugfix reviews. Ideally, it’ll also include a step-by-step guide on how the bug could have been exploited:

• Summary
• Introduction to the technology
• Vulnerability analysis
• Step-by-step guide to exploit
• Vulnerability fix
• Proof of Concept (optional)
• Acknowledgements

Conclusion

Bugfix reviews are probably the most impactful kind of work you can do as a bug bounty hunter aside from the main activity of bug bounty hunting, of course!.

With this guide, you’ll know what a bugfix review is, why you should write one, when you’re allowed to write one, and how you can write one.

That said, sometimes writing a bugfix review can be daunting. If you’re ever experiencing trouble, feel free to reach out to the whitehats out there who have written bugfix reviews, or ask in our Discord server for assistance.