How to get the most out of your smart contract audit - Tomas Bayer | Ackee Blockchain Security

thanks so good morning everyone dobre Brothers today I will speak about the smart contract audits in general and I will also give you some tips on how to get the most out of them so my name is Thomas buyer and I'm a CEO at the key blockchain my role is not technical I'm more a commercial guy and I'm responsible for operations and the business development in a key blockchain for those who would like to keep in touch or just to chat about the security feel free to use the QR code and it will take you to my Twitter account so about the key blockchain we are smart contract Auditors we have two teams one for Solana and one dedicated to ethereum that's a bigger one actually we are 15 people in total so the team is quite small but the aim is not to be the biggest but to be the best and to work with the top tier protocols in the space a part of auditing we also develop our own tools the one for ethereum is called Vogue and we got a grant from coinbase for that it's a python-based development and testing framework for solidity it's open source so everybody can benefit from that we also onboard developers to blockchain we organize the online courses a school of Solana and school of solidity and our founder and Auditors are teaching blockchain on check Technical University in Prague so we raised already more than a thousand Developers yeah I will mention some of our clients you probably know some of them names like axlr one inch or safe and most of the names you see on the screen are actually our regular clients because the best results from all the things you get from the long-term partnership we also received the grants from Solana foundation and the ethereum foundation topics I will cover today are three I will start with the selection of auditor what should you ask for and what should you look at when deciding which auditor is the best night for your project then I will go through the best practices and what I mean by that is the best practices before the audit and during the audit and I will also walk you through the next steps after the fin after the finished audit so let's jump straight to the first part the selection of the auditor so what to consider its technical level of the team head clients and the issue discover efficiency reference and the past audit reports so technical level of the team actually you don't need to have the auditor citizens right in front of you to get somehow the impression [Music] um the good team should ask you a technical questions about your project in order to get to know you better and to actually deeply understand your project but from time to time what happened to us when some BDS reach us out to ask about our service or to um make some some cooperation they stop us during the call and say something like guys the call is getting too Technical and you speak only about the security and actually the other companies this and this is your competitor for example offered us that we will that they will Implement for free their kyc solution if you decide to to make an audit with us so what are your selling points I mean how is this connected to the smart contract security right this is a red flag so this is crazy I mean we are not selling the vacuum cleaners here and yeah you should always focus on the technical uh experience of the team so this is what I mean by The Point Security First and not marketing and you should always also check for the backgrounds of the Auditors because it's not about the references of the whole team but the auditor that is dedicated specifically to review your project should be familiar with the protocol you are building on or audited previously the project that is very similar to yours then hacked clients issue discover efficiency you should ask for some figures for some numbers and if the auditor is not picking only the low onion fruits what I mean like that I put here a table in the First Column you can see every single Auditor in the second column you see the time needed to discover an issue in average and in the right column it shows how many days it takes to discover critical or high severity issue so in the bottom line you can see that in average every day our auditor discovers one issue and every fifth day he discovers a critical or high sovereignty issue yeah in these days uh we noticed several so-called Auditors who are only running the code through the tools in order to maximize the amount of low severity issues and informational issues and that's actually not what you want you can see that for example in our case the amount of critical and high issues are almost equal to low severity issues so what I mean by that is that 90 of the job should be in the manual code review when the Auditors go through the code base line by line and locally deploying the contracts in order to try the specific hex and attacks this is how you discover critical and high severity issues references you should always ask for them so of course it's nice to have talk to your protocols between the references but you should always look at the relevant projects to yours so whether it's a protocol you are building on or really similar protocol to yours these are the things to keep in mind reputable companies should always have an available like wide range of available public reports and my suggestion would be not to look only at the executive summary but also really read through the single findings and issues stated in the report because it can really and give you an idea about the approach of the team and the auditing methodology the best case scenario for you is if there is a scope that was audited by multiple companies so you can really compare and Benchmark the reports uh which approach suits you better yeah the second part the best practices I will cover the code for code freeze I will speak about tooling and disk coverage documentation the scope Dev support security mix and I also included the pre-auded checklist so you can maybe just in mind make your check marks whether it's your project ready to be audited so codebase really needs to be almost production already at a specific comment so you shouldn't make any changes during during the audit in your code base because almost always it results in the need of the re-audit and additional additional costs for the project about tooling and test coverage your test coverage should be at least at 95 percent and it's really handy to have a extensive test suit because the tests can discover bugs and more bugs in the report drives you to overhead so you should try to actually save the auditor's time for auditing in order to get the strong auditing output for solidity fans you can use Foundry or you can buy or you can use a python-based Vogue further I will also mention that every audit starts with the static analysis and [Music] yeah actually if you perform it before the audit you can save your time for that use slitter or Vogue but Vogue usually gets less less false positives documentation well I know that you probably know but you would be surprised that in these days it's not actually that automatic and natural so I will say the code should be continuously documented during the development process what should you provide to the auditor before the audit begins its architecture graphs project flows and functional requirements you should also add the white paper and the video walkthrough through the code base in the best case scenario scope you should always clearly specify all the contracts that should be audited and the ones that we should take as a black box so also be careful with cutting the scope from time to time we hear the clients saying something like okay we forked this we forgot that and utilize only this small part so all it will be really tiny at the end of the day of course it's up to the client what he wants us to audit but keep in mind that if you rely on the code base that was changed after the last update it's pretty risky and you should be careful with that it's this is how some set stories said stories begin there should be always somebody from the dev team who supports Auditors whether there are any questions or some uncertainties but also to react undiscovered critical issues because just to explain the low severity issues medium and high severity issues we keep and we report them at the end in the audit report but uh in case of critical issues we report them right away so the dev team have more time to actually fix those issues and what also sometimes happens and in the past here this year we had also one example of that actually when there's a time pressure and the project a scheduled launch and went live on Maynard before it was properly audited yeah it happened like three three months ago we actually woke up the development team in the US that we discovered a critical issue in their launched project so you can imagine that it was quite a tough night for the for the Developers security mix it's always recommended to have more than one audit at least for your core part of the code base but I would like also to mention that the best Auditors are often uh the internal teams and the developers because they are the ones who discover most issues and catches a main amount of the bugs so to sum it up two or more third-party audits tests internal audit and it's also handy to have a bug Bounty program yeah and here is the promised pre-order checklist so you can make your check marks if your project is for example ready to be audited and it's ready to be audited if your project is ready to be frozen is compilable is accessible for the Auditors from day one contains a full nuts documentation as a comprehensive technical documentation as a walkthrough video for auditors follows in the solid style guide contains an extensive test suit and has a past audit rewards if there are any so what are the next steps and what happens after the audit in our case it's readout session then the fixed review and the reout it and then comes the marketing you see marketing comes last not first so after the update we always schedule a readout session uh where we actually auditor read through the report all the findings and issues he discovered and explains them in detail to the development team he also suggests the fixes so now the development team should perform their fixes and also add their commands because for example if the auditor discovers an issue and the development team says that it's actually not an issue but the behavior is intentional we Mark the issue in the report as acknowledged so you should always ask the auditor before you make a handshake what's covered and what's included in the budget of the of the audit so everything I mentioned in our case is included but of course if you significantly change the code base or you make a change of the contract logic then this is something where needs to be done to reordered so after that you should consider publishing the report because of course you do that for yourself in the first place but you do that also for your users and you want to be probably as transparent as possible so at the end as we are proud of our work we always help to market the report to our customers whether we agree on the medium article or we make a blog post sometimes we schedule a Twitter space where we discuss how overall how it went what this what issues have been discovered and yeah we really enjoyed it and we somehow celebrate the security assessment that happened okay as my talk is approaching the end to let me let me summarize it in a very simple thought once the user fonts are involved in your project the security should become your number one priority because uh there are real people behind the avatars and the blockchain never forgets the reputation you have is only one so act accordingly thank you very much [Applause] foreign