Inference's assessment reports

To report or not to report

If you ever stumbled across audit reports from smart contract auditing firms, you might have noticed a sensible difference. Some firms end up with tens of issues, ranging from critical to very low or informative. Others, instead, publish reports containing only optimisations or informative issues. Is it possible that the former are extremely good, and they get poorly implemented codebases that host the most vicious bugs, while the latter are very bad at their job, and they only get the best clients with clean code and no serious bugs?

No, it isn’t.

The harsh truth on the role of reports

The result of the audit is a significant part in the reputation of any new project: clients will have a hard time trusting a DEX whose audit report came out containing 10+ critical issues, ranging from “Funds can be stolen” to “Loss of funds due to DoS”. Reports are not just the tangible result of the work of the auditing firm, but also a document that the client will want to publish, to show their commitment to security and, possibly, the quality of the product they are releasing. It will be clear to anybody, then, that two interests are at play here:

• The auditing firm, a business like any other, would like to showcase how good they are, how many critical bugs they found and how much value they provided to the client.
• The client, with its reputation at stake, would like to come out of the audit with a clean bill of health, showing that the project is absolutely reliable.

With no standardized approach on how to solve this dispute, we can only share our approach, and the kind of service you can expect from Inference, which also reflects our understanding of the security world and the business world at the same time.

This is our way

Inference’s main goal is to maximize the time allocated for reviewing code for security issues. The more time we spend reviewing the code, the more likely it is that bugs will be uncovered. As a result of this philosophy, the approach we decided to pursue in our audits is the following one:

1. During the audit, we share a private, interim report with the client, where we report our preliminary observations to the development team. Should there be any inquiries regarding the points we have raised, we are more than willing to provide answers or arrange an online meeting for further discussion.
2. Once all discussions have been cleared and solved up to the satisfaction of both the security team and the client, we include in the final, public, report only the observations that remain open or partially resolved.

This approach has both advantages and drawbacks, but we believe that it is the one that best matches the need of both the auditing firm and the client.

Advantages, responsibility and time

The decision to only include open, or partially resolved issues, in the final published report has two main pros:

1. We owe it to future users of the platform to make sure that they are aware of any potential pitfalls or risks still lurking in the released product. We cannot just turn our back on security and publish a “100% clean” bill of health so that the client is happy and satisfied
2. This decision spares us the need to articulate closed issues in a refined manner, making it possible for a wide audience to grasp the context and the points we are raising without losing focus on issues that are no longer present and relevant.

Disadvantages, or why we will not be famous

A drawback of this approach is that readers of our reports might infer (we love to use that word here ;) ) that we haven't uncovered anything. Furthermore, individuals aspiring to learn code reviewing are unable to derive insights from our work, as the majority of the points we've raised are not elaborated upon in our reports. Nonetheless, for educational purposes, we direct attention to our published checklist and test cases, all accessible on our code repository.

Wrapping up

Now you know the Inference way. We think this is the best approach to defend the interests of all parties involved: the firm, the client and future users of the product we review. And while this means we won’t probably be the Beatles of smart contract auditing, you can rest assured that your bugs, your reputation, and your time are all well taken care of at Inference.

If you would like to test this approach first-hand, submit a project to review and ask for a quote by sending an email to [email protected].

PS: you don’t have to take our word for any of this, just go read our clients’ reviews of our service!