One of the primary obstacles facing blockchain developers is the objective evaluation of their security posture and tracking its evolution. To tackle this challenge, a group of Web3 security specialists, spearheaded by Trail of Bits CEO Dan Guido, convened earlier this year to design a straightforward assessment aimed at profiling the security of blockchain teams. We have dubbed it the Rekt Test.
The Rekt Test draws inspiration from The Joel Test. Introduced 25 years ago by software developer Joel Spolsky, The Joel Test streamlined a convoluted process for evaluating a software team’s maturity and quality through 12 simple yes-or-no inquiries. The blockchain sector requires a similar solution as the current complex guidelines tend to create more frustration than clarity.
The Rekt Test emphasizes the most straightforward and universally applicable security measures to aid teams in evaluating their security posture and tracking progress. The more affirmatively an organization can respond to these questions, the greater their confidence in the quality of their operations. While not a conclusive checklist for blockchain security teams, it serves as a catalyst for informed discussions surrounding essential security controls.
During the Gathering of Minds conference earlier this year, industry leaders participated in discussions to address the absence of cybersecurity standards within the blockchain ecosystem. One discussion was led by Dan Guido, CEO of Trail of Bits. Additional participants included Nathan McCauley (Anchorage Digital), Lee Mount (Euler Labs), Shahar Madar (Fireblocks), Mitchell Amador (Immunefi), Nick Shalek (Ribbit Capital), among others. Their discussions culminated in the creation of the Rekt Test:
The Rekt Test
- Is there documentation for all actors, roles, and privileges?
- Do you maintain records of all external services, contracts, and oracles that you depend on?
- Is there a written and tested incident response plan in place?
- Do you document the best strategies for attacking your system?
- Are identity verification and background checks conducted for all employees?
- Is there a designated team member responsible for security?
- Are hardware security keys mandated for production systems?
- Does your key management process require multiple individuals and physical steps?
- Are key invariants defined for your system and tested with every commit?
- Do you utilize top-tier automated tools for identifying security issues in your code?
- Are external audits conducted, and is there a vulnerability disclosure or bug bounty program in place?
- Have you identified and mitigated potential avenues for abusing users of your system?
The blockchain technology landscape is varied, sweeping beyond blockchains to encompass decentralized protocols, wallets, custody systems, and more, each with its own security intricacies. The explanations accompanying the Rekt Test questions represent the collective agreement on best practices among this group, but they are not meant to be exhaustive or absolute. The aim of the Rekt Test is not to impose strict benchmarks but to foster meaningful dialogues about security within the blockchain community. Therefore, view this interpretation as a stepping stone in this vital discussion.
1. Is there documentation for all actors, roles, and privileges?
Having comprehensive documentation of all actors, roles, and privileges that influence the blockchain product is vital, as it clarifies who has access to system resources and the actions they are permitted to perform. Actors refer to entities interacting with the system; roles are predetermined sets of permissions assigned to actors or groups; and privileges detail specific rights and permissions.
Documenting these components thoroughly aids in detailed testing, enabling developers (and external auditors) to uncover security vulnerabilities, improper access control, the level of decentralization, and potential risks in case of compromise. Addressing these points raises the overall security and integrity of the system. This documentation also serves as a reference for auditors to compare actual access rights with documented rights, identify discrepancies, and evaluate potential security threats.
2. Do you maintain records of all external services, contracts, and oracles that you depend on?
Interfacing with external smart contracts, oracles, and bridges is foundational for many critical functionalities within blockchain applications. A new blockchain application or service may depend on the presumed security posture of a financial token developed externally, raising its complexity and potential for attack. Consequently, organizations that embed the best security practices into their software development processes may still find themselves victims of grave security incidents.
It is essential to document all external services (such as cloud hosting platforms and wallet providers), contracts (like DeFi protocols), and oracles (such as pricing feeds) utilized by the blockchain system to pinpoint risk exposure and mitigate incident repercussions. Doing so will help you address several crucial questions:
- How will we be alerted when an external dependency experiences a security incident?
- What precise conditions will trigger a declaration of a security event?
- What actions will be taken upon detection of such an event?
By answering these inquiries, you can prepare for the inevitable future security incident involving an external dependency. You should be able to recognize any changes, whether trivial or significant, in a dependency’s output, interface, or assumed operational state; evaluate its security implications; and take appropriate next steps. This preparedness will minimize the security impact on your system and help ensure consistent operations.
3. Is there a written and tested incident response plan in place?
While security in the blockchain realm differs from conventional product security (where more centralized or closed infrastructures can be easier to control), both environments require a robust incident response plan to maintain resilience during a security event. The plan should detail steps for identifying, containing, and remediating the incident using both automated and manual procedures. An organization must provide training to ensure all team members are familiar with the plan, and it must include steps for communicating incidents through both internal and external channels. This plan should be regularly tested to ensure it stays current and effective, especially given the rapid evolution of blockchain security. You can create your own incident response (IR) plan, utilizing this Trail of Bits guide as a resource.
For blockchain systems, it is particularly crucial to mitigate key person risk through incident response plans, ensuring that the organization does not become overly dependent on any single individual. The plan should consider scenarios where key personnel might be unreachable or coerced and outline processes to ensure continuity of operations. Developers should consider decentralizing access controls, employing quorum-based approvals, and documenting procedures so that multiple team members are poised to respond effectively.
Furthermore, incident response for blockchain systems should prioritize proactive measures alongside reactive tactics. Contracts should be designed with the IR plan in mind, utilizing strategies such as guarded launches to deploy new code incrementally. Developers should also decide whether or not to include pausable features within their contracts and determine which portions of the protocol should remain upgradeable or decentralized, as this decision will impact the team’s response capabilities during an incident.
4. Do you document the best strategies for attacking your system?
Creating a threat model that outlines all possible avenues of attack against the system allows you to gauge whether existing security measures are adequate. The threat model should comprehensively depict a product’s ecosystem, encompassing areas beyond software development, like applications, systems, networks, distributed systems, hardware, and business operations. It should highlight all of the system’s vulnerabilities and clearly convey how exploitative actors might exploit them, integrating lessons from pertinent real-world attacks to minimize the risk of repeating similar failures.
This information will help you determine if your mitigation efforts are concentrated in the right areas—namely, whether your current strategies align with how and where attacks are most likely to occur. It will also provide clarity on what a successful attack on your system might look like and whether you are sufficiently positioned to detect, respond to, and contain it. A well-articulated threat model ought to eliminate surprise and empower your team to plan mitigations purposefully.
5. Are identity verification and background checks conducted for all employees?
Pseudonymous development is prevalent in the blockchain arena, yet it obstructs accountability, contractual enforcement, and the fostering of trust among stakeholders involved in a blockchain product. Malicious actors can exploit gaps in identity verification and background checks to disrupt product development, misappropriate funds, or inflict other serious damage, with limited means for institutions to hold them accountable. In recent events, North Korean hackers have applied for actual positions using fake LinkedIn profiles and impersonated companies to provide fraudulent offers. Such tactics have led to significant hacks, including Axie Infinity’s loss of $540 million.
Hence, organizations must verify the identities of and conduct background checks on all employees, including those using public pseudonyms. Companies must further mature their access controls and monitoring; for instance, they should make judicious operational security choices based on an employee’s role, background, and geographical location (considering local laws and jurisdictions).
6. Is there a designated team member responsible for security?
A designated individual within the team must be held accountable for the security and safety of the blockchain system. Threats to blockchain technology are continuously evolving, and even a single security incident can be catastrophic. Only a dedicated security engineer has the requisite time, knowledge, and skills needed to identify potential threats, triage incidents, and fix vulnerabilities, thereby fostering trust in your developing product.
Ideally, this individual will build and manage a dedicated team with security as a core aspect of their job roles, ultimately leading initiatives that help the organization affirmatively answer other questions on this list. They will oversee cross-departmental collaboration, interfacing with developers, administrators, project leads, executives, and other personnel to ensure that security practices are woven into every facet of the organization.
7. Are hardware security keys mandated for production systems?
Credential stuffing, SIM swap attacks, and spear phishing have largely diminished the protective efficacy of passwords and SMS/push two-factor authentication. For high-risk organizations with considerable stakes, phishing-resistant hardware keys represent the only prudent solution. These specialized hardware keys should be used to access the organization’s resources, including email, chat, servers, and software development platforms. Extreme caution must be applied to safeguard any production operation that is particularly difficult or impossible to reverse.
Implementing these keys within your organization indicates a strong commitment to effective management of off-chain infrastructure. Do not be discouraged if this appears to be a heavy load for your IT team. In 2016, Google published a study revealing that deploying these keys was straightforward, well-received by its 50,000 employees, and resistant to malicious attacks. U2F hardware tokens, such as YubiKey and Google Titan, are excellent choices for hardware keys.
8. Does your key management process require multiple individuals and physical steps?
If a single person possesses the keys controlling your system, they can independently execute changes that bear a significant impact, absent a consensus from relevant stakeholders. If an attacker compromises their credentials, they could gain total control over critical assets.
Conversely, key management should be structured to necessitate consensus or a quorum of multiple individuals and physical access for significant decisions. Multi-person integrity is a proactive security measure employed in high-risk sectors like defense and traditional finance; it shields against compromises from outside attackers, insider threats (such as rogue employees), and coercion simultaneously. When determining the trusted group of individuals for a quorum-based approach, it’s essential to select individuals who are both reliable and properly incentivized, as including poorly suited or misaligned individuals can undermine the system’s resistance to coercion. Additionally, by mandating physical key management (e.g., storing keys in a physical safe or on an air-gapped device), you will substantially decrease the risks of fraud, theft, misuse, or errors by any member or if any individual’s key or key fragment is breached.
Blockchain organizations should implement multi-signature or multi-party computation (MPC) controls and cold storage solutions, at least for the main wallets that house the majority of their assets, or choose to use a qualified custodian, depending on their unique regulations and requirements. Keys enabling access to a multi-signature wallet should be securely stored on trustworthy hardware, such as a hardware security module (HSM), secure enclave, or tamper-resistant hardware wallet.
It is critical that the deployment and configuration of trusted hardware are meticulously executed to limit its attack surface. As a rule of thumb, secrets should never be extractable and network connections should be avoided. Organizations should also establish a rigorous protocol for moving funds, based on criteria such as thresholds, affected wallets, recipient addresses, and identifying key personnel initiating transactions.
9. Are key invariants defined for your system and tested with every commit?
Invariant conditions must remain valid throughout a program’s execution. Invariants may encompass the entire system (for example, ensuring no user possesses more tokens than the total supply) or target specific functions (like ensuring a compute_price function cannot result in obtaining free assets). Defining and understanding invariants encourages developers to be clear about the system’s expected behaviors, helping security engineers assess whether those behaviors meet established expectations. This provides a framework for security testing and diminishes the risk of unforeseen outcomes and failures.
Defining invariants begins with documenting the assumptions surrounding the system in straightforward language. These invariants should encompass a wide array of functional and cryptographic properties, outlining their valid states, state transitions, and overarching behaviors. Well-specified systems may define hundreds of properties; thus, priority should be given to the most significant ones first, while continuously working to enhance depth of coverage. To ensure that the code adheres to the invariants, they must be tested utilizing an automated tool (like a fuzzer or formal methods-based tool) consistently throughout the development lifecycle.
10. Do you utilize top-tier automated tools for identifying security issues in your code?
Automated security tools form a foundational component of a successful security strategy. Fully automated instruments, such as static analyzers, quickly identify common errors and require minimal upkeep, whereas semi-automated tools, like fuzzers, provide developers with an opportunity to probe deeper for logical flaws. Numerous tools are available, but it is advisable to utilize those favored by top security professionals with a proven track record of discovering vulnerabilities.
Trail of Bits’ smart contract security tools leverage state-of-the-art technology, enabling integration into your CI systems and the edit/test/debug phases. These tools include Echidna, a smart contract fuzzer designed for Solidity contracts, and Slither, a static analyzer for Solidity smart contracts. Automating the use of these tools during development and testing allows developers to detect critical security bugs prior to deployment.
11. Do you undergo external audits and maintain a vulnerability disclosure or bug bounty program?
Relying solely on internal security teams is insufficient for identifying vulnerabilities within blockchain code. Instead, organizations must collaborate with external auditors possessing extensive knowledge of modern blockchain technologies, including low-level implementations, financial products, and the libraries, services, bridges, and infrastructure that empower contemporary applications. (Websites that catalog blockchain security incidents are filled with entities that neglected to seek external guidance for often complex changes.)
Security auditors aid in identifying vulnerabilities while offering recommendations for restructuring development and testing workflows to mitigate these vulnerabilities. When seeking an audit, it’s crucial to specify which components will be reviewed, which will be omitted, and the level of effort expected, including through tooling. By understanding the advantages and constraints of an audit, an organization can prioritize additional areas needing enhancements after the audit’s conclusion.
Moreover, a vulnerability disclosure or bug bounty program can further refine your security posture by creating a publicly accessible means for users or researchers to reach out if they uncover a defect. By establishing such programs, organizations demonstrate a proactive stance in engaging with independent bug hunters—in contrast, without these initiatives, bugs may be publicly disclosed on social media, or exploited for personal gain. While these programs offer numerous advantages, it is vital to weigh their limitations and potential pitfalls. For instance, bug bounty hunters may not provide suggestions for enhancing the security maturity of the system or for decreasing the likelihood of long-term bugs. Additionally, your team will shoulder the responsibility of triaging bug submissions, a task that can demand constant resource allocation.
12. Have you identified and mitigated potential avenues for abusing users of your system?
Numerous attacks against blockchain, such as phishing, Twitter/Discord scams, and “pig butchering,” aim to mislead users into making irreversible decisions while utilizing your products. Even an organization possessing the most sophisticated security system to protect itself may find its users remain vulnerable. For instance, blockchain applications frequently depend on cryptographic signatures, increasing the possibility of phishing attempts. Developers should strive to make signatures easily distinguishable (for example, adhering to EIP-712) and should develop and promote guidelines for users to reduce the risk of exploitation.
To avert such attacks, an organization’s security strategy should encompass abusability testing, whereby your team contemplates how malicious actors could cause social, psychological, and physical harm. Recognizing the risks associated with significant financial or societal damages will aid your team in evaluating necessary processes and mitigations. For example, if users of your protocol include crucial stakeholders, such as retirement funds, establishing an assurance fund derived from protocol fees could help restore users in the event of compromise.
Don’t Get Rekt
These 12 controls are not the only actions that can shape your security posture, but we are confident that adhering to them will strengthen every developer’s software and operational security as blockchain technology continues to rapidly advance. This test should not be regarded as a one-time exercise; these questions possess enduring value and should provide organizations with a roadmap as they expand and introduce new products. Affirmatively answering “yes” to these inquiries does not guarantee immunity from a security incident, but it can empower you and your team to steer clear of the most undesirable label in the industry: getting rekt.
