Mahi Sall, Advisor, Fintech-Bank Partnerships, Payments and Financial Inclusivity
January 25th, 2023
Mahi Sall is the CEO & Founder of FinXpair, a Berlin-based strategic advisory boutique firm focu[...]
Expert Roundup: DeFi Smart Contract Audits
DeFiprime | Nick Sawinyh | Sep 19, 2019
When it comes to “being your own bank,” having the ability to evaluate the security of the tools at your disposal becomes a necessity.
A software audit is a process where an individual or team examines the code that lies behind a piece of software with the goal of uncovering any bugs, security breaches, or violations of programming conventions before the code gets deployed. Smart contract audits play a critical role in evaluating the technical risks associated with a dApp but as a relatively new form of code, the standards for software audits of smart contracts remain in their infancy.
Companies like ChainSecurity, Trail of Bits, and Certik provide smart contract audits and have adopted their own standards for how a proper audit should be conducted. Until the industry adopts its own standard, however, customers have to rely on the reputation of these companies and the team members conducting the audit to evaluate the quality of a potential audit. To help you understand the current state of smart contract security, we’ve gathered insights from a number of industry experts.
See: Robocop vs. Terminator in Fintech; Comparing DeFi originations to Digital Lenders in the early years
Q1: What is the smart contract audit exactly
There is a lot of misconceptions in the space, like many of DeFi users thinking that smart contract audit is a sort of silver bullet and sign of security (or lack of) of the dApp.
Hubert Ritzdorf, ChainSecurity:
A smart contract audit is an independent review that assesses the security and correctness of the code. This provides the following advantages. First, users obtain an independent opinion on how the smart contract behaves, which can alert them about potential threats. Project managers receive valuable feedback about their projects and can take the necessary steps to mitigate security risks. Finally, developers receive important security advice and concrete security bug reports. However, not all audits are the same. The value provided by an audit depends on the technology used to conduct it and the expertise of the audit team.
Dan Guido, Trail of Bits:
Think of security assessments like getting your car inspected: If you do it early enough, the mechanic can recommend parts to replace and preventative maintenance that can avert leaving you stranded at the side of the road later. If you wait until 300,000 miles to get your first service, the damage might be irreparable.
The amount of time you allot for inspection also makes a big difference: Give the mechanic 30 minutes, and they might only have time to use an automated scanner to determine that your spark plugs are bad. Give the mechanic a day, and they might have time to diagnose the underlying cause of why the spark plugs became bad (failed sensors? wiring? engine running rich?).
Scope also matters: Request that the mechanic only diagnose problems with the alternator, and the car may drive away with a repaired alternator as well as a latent, undiagnosed issue with the transmission.
It is the mechanic’s job to provide advice, but it is ultimately up to the owner to decide if, when, and how to implement the recommendations.
See: Fintech, decentralization pose risks: Report
Daryl Hok, CertiK:
In the simplest sense, a smart contract audit is a third-party review of the source code of a smart contract. Although a completed audit means that the code was reviewed, the rigorousness of the audit may vary substantially - and this rigor is really what matters for security, not merely the presence of an audit. For instance, a dApp may flaunt that no errors were found during the audit process, but it’s difficult to determine whether this means that the code quality was extremely high or whether the auditor was really bad.
At CertiK, we specialize in using Formal Verification to prove or disprove the correctness of source code; we apply mathematical proofs to compute source code outcomes and prove the absence of bugs, meaning that, if there are no bugs found, it is not possible for the specified vulnerabilities to exist.
Q2: Are there degrees of “approval”?
Are there some contracts where you’re more confident they are solid vs. others where you can’t find a problem, but you are less confident?
Hubert Ritzdorf, ChainSecurity:
A limited audit scope affects confidence levels. Before the audit begins, we determine the scope together with the customer. It can be decided not to review certain dependencies or components due to time or budget constraints. To clarify this, our audit reports always precisely state the scope of the audit.
Dan Guido, Trail of Bits:
We try to make it easy to understand what happened on a security review. If you’re investigating the health of a project, then pay attention to these sections in our reports:
- Executive Summary. This section includes a brief review of what we did, what we found, and what we recommend as next steps. It should make clear how much work is ahead of the project to remediate the risks we identified.
- Project Dashboard. This easy-to-read table summarizes the level of effort applied to review the codebase and what was found. Did we identify systemic issues? Was every bug identified high severity? Get a visual indicator by glancing at this table.
- Engagement Goals. This section describes our scope, or, what we set out to do on the project. Did we seek to identify risks that you care about? You’ll find out by reviewing our own goals for the project.
- Coverage. This section discusses our ability to achieve our engagement goals within the constraints of the project. You’ll find information on specific contracts and techniques we used to review them here, as well as pointers for future review.
It’s no accident that these are the top four sections in all our reports.
See: The future of finance: Insights into tomorrow’s financial system
Daryl Hok, CertiK:
In the case of Formal Verification, the results are binary - when the mathematical model runs, it either identifies an example of the vulnerability in the code, or it does find anything, which means that it’s secure. As a result, our confidence is tied to the output of these results in these instances. When it is not feasible for Formal Verification to be applied, we utilize various tools to test the security, while also performing thorough manual examination.
Our confidence level is a collective consideration of the usage of commonly accepted best practices, patterns, libraries, as well as the quality of documentation and test cases. Rare, complex patterns typically reduce our confidence or require more customized review of whether the output is consistent with the intention. Overall, we work with projects to correct all critical vulnerabilities and antipatterns before publishing any passing audit scores.
Q3: What are the five most common things people miss in smart contracts that make them vulnerable?
Hubert Ritzdorf, ChainSecurity:
- Improper access control: granting access to unauthorized parties or denying access to authorized ones
- Front-running or back-running: No enforcement of execution order
- Improper input sanitization: insufficient filtering of untrusted user inputs
- Logical errors: logical flaws in the code due to faults in the code
- Numerical errors: rounding errors and incorrect arithmetic calculations
Dan Guido, Trail of Bits:
It has everything to do with development process rather than awareness, or not, of individual security issues.
- Developers are simply not using security tools. Ask any developer about unit tests, and they’ll say they won’t ship without 100% test coverage. Yet, many of those same people will have never used, or even tried to use, security testing or verification tools. Don’t leave it for the security consultants – nearly all the best tools are free.
- Developers still look at security as the last step before production. I’m writing this interview about a month ahead of DevCon, and my schedule has never been so busy. Developers should seek guidance earlier, including developer training, architectural review, and brief checkins over the lifetime of the project.
- Developers are writing too much code without a clear idea of its purpose or whether it is needed at all. Developers should start with a specification and then write the minimum amount of code to meet it. Our best-performing clients have documented security requirements in their spec. Complexity breeds insecurity; keep it simple.
- Developers rush to use bleeding-edge third-party dependencies that increase complexity and reduce the safety of their project. Examples include low-level optimizations, delegatecall proxy upgrades, ABIEncoderV2, and even the latest version of the Solidity compiler. Be judicious about inherited risks.
I don’t think there is a step five. You’ll be ahead of nearly every other project if you can do these four.
See: Bakkt’s Bitcoin Futures Already Open to Retail Investors, COO Says
Daryl Hok, CertiK:
- Integer overflow/underflow
- Not updating the balance first before further operations. (reentrancy vulnerability)
- Writing loops without considering the gas cost. (DoS vulnerability)
- Lack of balance checking for value transfer operations.
- Lack of permission settings and permission check for public/external functions.
- Use of
block.timestampandblock.numberwithout considering their drawbacks (block.timestampcan be modified by miners; time between two consecutive block numbers is dynamic soblock.numberis not ideal for a stable time delta estimation).
Continue to the full article --> here
The National Crowdfunding & Fintech Association (NCFA Canada) is a financial innovation ecosystem that provides education, market intelligence, industry stewardship, networking and funding opportunities and services to thousands of community members and works closely with industry, government, partners and affiliates to create a vibrant and innovative fintech and funding industry in Canada. Decentralized and distributed, NCFA is engaged with global stakeholders and helps incubate projects and investment in fintech, alternative finance, crowdfunding, peer-to-peer finance, payments, digital assets and tokens, blockchain, cryptocurrency, regtech, and insurtech sectors. Join Canada's Fintech & Funding Community today FREE! Or become a contributing member and get perks. For more information, please visit: www.ncfacanada.org
 |  |  |
Support NCFA by Following us on Twitter!Follow @NCFACanada  |
Related Posts
The Complete Guide to Unity Game Development Agencies and How They are Disrupting Game Design & Development
CCI tells feds emergency wage subsidy must be expanded to support Canadian tech
OpEd: Draft U.S. Bill on Stablecoins Highlight Differences with CBDCs
Meta Agrees to $725 Million Class Action Settlement in Cambridge Analytical Scandal
OSC Notice 11-768 – Statement of Priorities for Fiscal Year End March 2014 – Request for Comment
Competition Bureau invites feedback on draft FinTech report
Leave a Reply