Blockchain space is becoming increasingly complex, adding more and more open-source software that handles millions and billions of dollars in value.
As a consequence security audits are employed with the purpose to let external and professional eyes look at the code before it gets released. Usually it’s an expensive and laborious task.
Developers rely on the existing libraries, applications and services to build the software, but there is a problem, there is no way to actually ensure the quality of the library or service you are relying upon.
There is also an issue with quality of security review and accountability. Even though most professional firms always stand by their work, it’s easy to save money and go with someone who might not provide full visibility into their previous work and clients. And even more complex, if you want to use an application that was reviewed by a firm that you yourself don’t have direct experience. You don’t have any data on their previous work, quality and professionalism. It’s hard to make a judgment based on lack of data.
The idea of the Audit Registry is to add accountability and visibility of which applications were reviewed and by whom.
It’s described by a simple contract, where audit and security agencies can register their firm and issue “audit findings” in the form <hash of code, hash of the audit report, list of compliant standards, their signature> per library, application.
This allows to handle various cases that are pretty common in the space:
- Dependency code review. For example, think about a random crypto library in Rust: is used by many projects, that also reviewed it at different times, but has no records.
- Code review for a contract that is being used as a fundamental building block. Something like Uniswap - it would be great to know that the exact code that is depositing millions of dollars, has been reviewed by 2-3 various firms.
- A security breach of the contract, either maliciously executed or whitehat reported. This forces the firms that participated in the review to provide detailed retro on the issue and how they will be mitigating such oversight going forward. Which means increases quality of the future reviews.
- Sometimes developers don’t provide the report to the public which highlights some flaws. If a breach ends up happening with this flaw, there is defensibility on the side of the security review firm that they reported it and it was up to the developer to not expose such a report and its users to not require it.
- Audit findings including list of standards that a contract or a service comply with. This allows to add extra checks when relying in the other tools and software on that vs just on function names / ABI matching.
- Report security advisory for all the subscribed to the registry, without first revealing the full content of it. Committing to the hash of the advisory first will inform interested parties (like wallets) about possible issues with given software. Later after the issue was mitigated, the advisory can be revealed as part of the disclosure policy.
Audit registry can also become a valuable service for tools in the ecosystem. For example if we are looking at the wallet applications or recent issues with Uniswap frontend and ImBTC we’ll notice that frontends need to have a way to check, at least some authority, on security and standard compliance (e.g. ImBTC was ERC777 instead of expected by Uniswap ERC20).
In NEAR this will be important from the start, as smart contracts are used for delegation. Which means before any UI whitelists a validator that uses a custom contract - they need to check that it actually satisfies staking pool standard.
As a result the first version of the audit registry is open to debate.
The implementation of the code is found here.
For the demo video click here.
Description:
- Main page splits screen into the list of security review firms and list of projects.
- Frontend allows projects to request an audit for their code
- Frontend allows auditors to sign under the audit
- The status of the security review is visible, it can be pending or completed.
- By clicking on project’s code_hash, will link to the specific commit on GitHub
- Metadata is saved in IPFS, the contract keeps just the hashes
- Multiple versions of the same project are grouped by URL
Audit Registry v2 might include :
- Allow a project submitter to upload a binary file. The file will be stored on IPFS, and will also be available for download from AuditRegistry webpage.
- Integrate the VirusTotal API to add a higher level of trust by scanning the binary file.
- Implement a community rating system where users can vote on a binary, thumbs up/down. One vote per account ID.
- UX improvements:
- Show reviewed projects on auditor’s page.
- Be able to expand a project and show its subversions directly in the home page.
- Allow auditors to upload pdf files when submitting audit findings or advisory report.
- Show the number of audits done by an auditor in the home page.
- Be able to add logo so that professional firms can choose their own.
Let us know what you think and tell us how to improve.