Immunefi has launched a new “security baseline” for Web3 projects in collaboration with Trail of Bits, the Solana Foundation, Polygon Labs and more.
Every year, billions of dollars are lost in crypto-related hacks and scams. Even though blockchains are incredibly secure, scams and bad actors are so prevalent in the Web3 space that we’ve conjured up a new vocabulary around it: rekt, rugged, and so on.
Immunefi, a bug bounty platform for smart contracts, has published a new security baseline for Web3 projects aptly called the ‘Rekt Test’. It’s a comprehensive questionnaire that’s designed for Web3 projects to ensure they’re operating at a “minimum baseline of security performance”, but it can be used by anyone, including investors who want to asses a project for themselves.
“Simply put, we will all fail at onboarding the next billion users into web3 if we do not succeed in improving security standards,” the blogpost outlined.
Related: Cross-chain protocol Multichain loses $126M to mysterious attack
Immunefi explained that despite the colossal amounts of capital flowing through the web3 ecosystem, billions have been lost through private key thefts, lack of documentation, lack of security roles, ignorance about best practices, and much more.
The Rekt Test seeks to circumvent this. “The Rekt Test will return dividends over the long-run and in many cases the short-run, too,” the company stated.
Let’s unpack the test.
The Rekt Test proposes 7 key questions relating to personnel, security, private keys and more.
1. Documentation and roles: who does what?
The first part of the test starts with the basics: ‘are all actors and their roles documented?’, and ‘are external services documented?’
While a project will generally know who is who within their team, roles, expectations and privileges aren’t always clearly defined. The Rekt Test asserts the importance of keeping such matters fully documented to establish who is responsible for what. In doing so, Immunefi claims you’re likely to find “lots of low-hanging fruit in terms of misaligned assumptions.”
The second question – ‘are external services, contracts and oracles documented?’ – is another important one, because most systems rely on external dependencies in one way or other. The Rekt Test outlines that projects must know exactly what/who these dependencies are, and what could go wrong, such as an external bug.
“Many exploits have occurred because of reliance on third-party libraries or oracles”, the blog states.
2. Private key management: who has access?
Web3 is still emerging and it can be difficult adapt to new security logistics such as private keys. Robust guidelines around private keys are still quite murky, but the Rekt Test advises that a project’s key management system should require multiple people and various physical steps to ensure there are lots of opportunities to catch an error or malicious actor in advance.
A hardware wallet for multisig signers is advised, as well as custody systems that require multiple signers.
A good recent example of the dangers of not having multiple signature access is the recent Multichain breach. More than $200 million in assets were siphoned from Multichain earlier this month, marking one of the biggest breaches in crypto history. Staff were unable to access the key servers for months beforehand because the company’s CEO, who held sole access, went missing.
Read more: $126M Multichain exploit was likely an inside job, Chainalysis report claims
The Rekt Test also puts forward more well-known security suggestions, such as cold storage, hardware 2FA (YubiKey), and multisig treasury wallets.
3. Incident and crisis management: have you got a plan, and is it tested?
“You’re only ready for what you’ve drilled for,” the Rekt Test wisely observes.
For any Web3 project, it’s essential to have a written and tested incident plan, of which everyone is aware. This plan should outline clear personnel roles in the event of a crisis, as well as emergency contacts, decisions making procedures and the documentation process.
One of the most common setbacks in crises is not having reliable contact information.
4. Team: do you really know your employees?
While anonymity and pseudonymity is common in crypto – even for CEOs, such as Multichain’s Zhaojun – the Rekt Test advises that project employees should undergo positive ID with background checks.
“Would you trust the role of head of security to a person who’s been convicted several times of fraud and other misbehavior?”, it asks.
Specific points and questions include:
- Reference checks of employees. Did they actually work at a previous company they said they worked at?
- Identity checks. Are they who they say they are?
- Background checks. It may be useful to hire a company to perform background checks on prospective or current employees in crucial roles.
It’s also essential to have a team member dedicated to security, rather than passing it over to an external firm. The “lowest bar” according to the Rekt Test is to ensure that at least one person on the team has ‘security’ in the description of their role and has active security duties on a daily basis.
5. Code security: can you justify warnings?
Web3 is built on code. The Rekt Test asks whether the project’s code can compile with the latest compiler available, and whether it can justify any warnings should they arise. “A newer release often means new security patches, and you don’t want to skip on those and let your compiled code be subject to vulnerabilities due to a bug in the compilation process,” it outlined.
It also asks if a project can define key invariants for the system. An invariant is a property of a software system that should not change, and the Rekt Test advises that invariant parameters are “ironclad”.
“You should aggressively test against your invariants at each new iteration of your code,” it states.
6. Vulnerability management: is the project externally audited?
The Rekt Test assets the importance of an external auditor to check a project’s code. In addition, it recommends running a vulnerability disclosure program or bug bounty to incentivise the constant review of live code.
7. Attack mitigation: have you simulated an attack on your own code?
The Rekt Test asks whether you have documented the best ways to attack your own code – because if you don’t, “attackers will”. The test advises you to “red team” your own code, i.e. simulate an attack, to minimise chances that bad actors will find vulnerabilities before you do.
It also asks projects to consider and mitigate any potential accidental abuse of the system. “Without necessarily being malicious, users will end up interacting with every part of your system–often more than you do.”
Disclaimer: CryptoPlug does not recommend that any cryptocurrency should be bought, sold, or held by you. Do conduct your own due diligence and consult your financial advisor before making any investment decisions.
