28 Ways To Miss Vulnerabilities In A Smart Contract Audit

Interested in getting hands-on training to become an expert security researcher in a matter of months?
Get the guide to becoming a senior auditor in 6 months here: https://www.intogateway.com/guide

Looking for a Smart Contract Audit? Apply to work with the Guardian team on our website: https://guardianaudits.com

Join our community aimed at building and sharing a wealth of blockchain and solidity knowledge to help developers/auditors of all levels transform the web3 ecosystem:
https://lab.guardianaudits.com/

Twitter thread/article:   / 1616582468890660866  

00:00 - Intro
01:58 - #1 Not examine every external call for re-entrancy
03:11 - #2 Do the audit in isolation, don't consult others
04:37 - #3 Trust that the developer got it right
05:45 - #4 Not read comments
06:20 - #5 Don't write tests
06:48 - #6 Only think about the audit when you’re looking at the codebase
08:03 - #7 Don't check if external calls can DoS by reverting or spending a lot of gas
08:30 - #8 Assume that contracts receiving ether have a receive/fallback and withdrawal mechanism
09:41 - #9 Assume parallel data structures will always be in sync
10:18 -#10 Don't look for gas optimizations
10:52 - #11 Not make notes or in-code audit tags
11:40 - #12 Don't diagram the system for your own and other’s understanding
12:25 - #13 Assume purported invariants always hold
12:54 - #14 Not ask the developers questions
14:03 - #15 Consider each contract only in isolation, not within the context of the entire system
15:13 - #16 Not look at test coverage
15:41 - #17 Not write PoCs
16:49 - #18 Accept payment regardless of the #/severity of findings
18:16 - #19 Have a developer's mindset, rather than an attacker's
18:29 - #20 Do multiple audits at the same time
19:05 - #21 Not sleep/eat well
19:46 -#22 Not examine division symbols for precision loss or divide by zero reverts
20:26 - #23 Not examine subtractions for underflow reverts
20:50 - #24 Ignore special case ERC20 tokens like burn-on-transfer tokens
22:38 - #25 Ignore front-running/back-running attack vectors
24:08 - #26 Not consider incentives or tokenomics
24:47 - #27 Not surround yourself with others who are interested in Solidity security
26:12 - #28 Not follow me :)