Audit reports are a badge of honor for a DeFi project. They are used to establish legitimacy for investors and users. Projects proudly displayed their audit reports but said audit couldn't prevent malicious actors. The experience and qualification of auditors are questioned after a project hack. There are limitations to a smart contract audit.

The Obligatory Disclaimer

If you have read a smart contract audit report at some point, you would have come across these lines:

We draw attention to the fact that due to inherent limitations in any software development process and product, an inherent risk exists that even major failures or malfunctions can remain undetected. Further uncertainties exist in any software product or application used during the development, which cannot be free from any errors or failures.

Let's be clear; auditors sometimes review files given to them with limited information, often inferring functionality, only confirming with clients when they can not determine it themselves. Auditors can say a lot about project preparation and test-driven development. When an independent third party reviews the code and stamps it bug-free, that's all that matters to must viewing the report. It's understandable to be outraged when a vulnerability exists and is exploited after a thorough audit.

Below I will go through a few limitations to smart contract auditing, this is by no means a definitive list, but it should shed some light for the users of the audit report.  

Is documentation complete?

Documentation is essential when third parties need to interact with the code base. Projects rarely take it seriously when it is crucial. The IT team can sometimes be a revolving door, and when documentation is completed poorly, it makes the job harder for anyone joining the project later.

Sometimes when it's written, it's a rushed afterthought. The result is gaps in information and essential steps missing. For auditors to effectively review a smart contract, they need to understand how it works. If the auditor has no idea how the contract functions after reading the documentation, that's a problem.

How deep can they go?

The auditor's responsibility is to prioritize the various levels of vulnerability to investigate. Combing over every line of code can consume significant time and resources. Many projects do not allocate enough time for this procedure, forcing auditors to sacrifice efficiency for time.

Auditors can prioritize known vulnerabilities from a comprehensive list like the SWC Registry. Automated tools could highlight these vulnerabilities, and it's up to the auditors to use their expertise to apply other tests when they believe false positives are flagged.

Too simple to audit

A simple contract that interacts with the project may be overlooked due to time, cost, or project negligence. As a result, not all relevant smart contracts may be submitted for audit. If the unimportant contract is misused, it may have flaws that drastically modify how other contracts perform.

Time constraints

Auditors, unfortunately, do not have unlimited time to review the smart contract. Projects have deadlines for when they want their projects in customers' hands. Limiting the time an auditor takes to complete their process could force the auditors to unprioritized checks that could have uncovered some issues.  

Auditing isn't a chore. Security should be included as part of the planning process, and continuous audits are ideal.

Ethics

The auditing process can protect a smart contract entirely against specific bugs or leave them wide open to them. The project team is essential; they spend more time with the protocol than auditors could ever. Auditors review and test the code. The intention of the project team isn’t something audits investigate.

Before investing in a protocol, users should spend their time doing due diligence on the team controlling the projects.

Third-party

Third-party libraries are expected to function as intended and are not subjected to the audit. These libraries pose inherent risks.

The contract's environment can change, leading to unexpected operational behavior.

Auditors skill level

Security is an integral part of web2 infrastructure. Web3 leaves a lot to be desired. There are no standards or requirements for an audit to take place. Professionals in web2 security either think web3 is a joke or are waiting for web3 to put on its big boy pants and get serious on security.

Smart contract auditors understand computer science, distributed systems, economics, and game theory. These are specialized skills that not everyone has. Luckily for you, AuditOne.io will do the hard work of rigorously testing our auditors to guarantee professionalism. Saving projects time you could be spending making unit tests because it takes a village to secure the contract.

Reporting

The final report is essential, and vulnerabilities and solutions should be clearly outlined and defined. The final user of the information should be able to read it and clearly understand its finding and guidelines.

Dependability of the auditing company

Many companies can promise a thorough and complete audit, but how many can deliver on this with a proven track record—having references that clearly outline the experiences of their auditors. In most companies, the auditors are anonymous entities within the organization.

AuditOne.io does the heavy lifting for projects. Highly sophisticated automated free-to-use auditing tool. Projects can find the best auditor for their project with a simple search. Our marketplace has many auditors that can guarantee your protocol's security.

Finally

The auditing process might become bogged down in numerous tiny aspects on which projects cannot always focus. However, it is critical to deliver a safe project to the clients. AuditOne.io stays current on DeFi developments, and we have a vast marketplace of competent auditors ready to secure your projects of any size.