RISC Zero takes The Rekt Test

RISC Zero has always approached our mission to enable privacy-preserving computation with a security-first mindset. We focus on continuous security improvement and a core value of measuring our security practices against the best frameworks available.

While the status quo often appears to be limited to, "Has this been audited?," we were excited to see several security veterans at the Gathering Minds conference in the development of a better litmus test that we could incorporate into our security journey.

For a deeper dive on the context of the Rekt Test, Trail of Bits has a great blog post that provides additional detail on the justification for each test question.
‍

So how did we do?

‍

What's next?

As with any security program, there is always room for improvement. While we fare well in this point-in-time assessment against the Rekt test criteria, we also understand that we play a key role in the future of zk computation. Therefore we will continue to mature in the areas detailed by the Rekt test and beyond.

Do you have all actors, roles, and privileges documented?

RISC Zero reviews software designs through asset-centric architectural risk analysis. A logical component model of the system is documented and the core assets of the system are identified. We enumerate the trust boundaries of the system and place actors at each trust boundary that represent distinct threat perspectives.

‍

We then enumerate how each asset could be attacked by each actor in the context of controls and known attack methods. When new controls are needed to protect assets that result in secondary assets that we try to protect, we repeat the process until we have a complete picture of the system. While this process is rigorous, it's also difficult to keep pace with design iterations in a rapidly evolving code base, so we are working on new ways of maintaining our knowledge base relevant to these efforts to maintain our threat models, and as such the currency of our threat models is a readiness check for our security readiness during major release gates.

‍

We also do our best to look at ways adopters of our system are likely to architect and design systems that depend on our RISC Zero products and account for likely downstream abuse cases; however, it's not always easy to predict how our products will be used, so we encourage RISC Zero adopters to adopt a similar approach in evaluating their security.

Do you keep documentation of all the external services, contracts, and oracles you rely on?

Our software dependencies are currently enumerable through the relevant build systems (e.g. cargo, bazel) and we leverage software composition analysis to provide some automated defect discovery in this area in addition to our manual review. At the time of writing, we do not have any external contract or oracle dependencies in place for our web3 products.

Do you have a written and tested incident response plan?

We have a corporate incident response policy, as well as requirements for tailored product security incident response plans. Although we have executed dry runs of applying this process in low-severity events for practice, we are currently planning a more expansive table-top exercise for 2024 Q2 that will expand the scope of our testing to other key areas of our business such as legal and communications areas.

Do you document the best ways to attack your system?

There are two major ways we tackle curating the most applicable attacks to our systems:

1. We review external attack libraries including CAPEC, MITRE CWE, and MITRE ATT&CK for relevance and applicability to our system and bring the most relevant attacks into our threat model.
2. We also analyze identified defects in our system to determine the most likely ways that an attacker could exploit a defect in our system. We then use this information to amend our attack library with the generalized attack patterns where other risks could be present, in addition to fixing the specific instance of the issue identified.

Do you perform identity verification and background checks on all employees?

During our hiring process employees in the U.S. and abroad undergo criminal background checks. Consultants with privilege access are also subject to this policy.

Do you have a team member with security defined in their role?

RISC Zero has a dedicated security leader that drives the security of our products and services. We also have a security champion program that is designed to help us scale security knowledge across the organization. Beyond this, a vast number of our engineers and principals are renowned security experts in the fields of cryptography, formal methods, and software quality.

Do you require hardware security keys for production systems?

We require hardware keys both for production systems and all corporate IT infrastructure.

Does your key management system require multiple humans and physical steps?

At this time, we do not have any key material relevant to our products that require manual intervention or physical steps.

Systems and application secrets are stored in cryptographic vaults. Individual credentials are placed in managed password solutions that require hardware key authentication.

Do you define key invariants for your system and test them on every commit?

Our open-source repository has several examples of key invariant testing that we operate in our CI/CD pipeline. We champion this test definition as part of our development process and are open to contributions that help us improve our key invariant testing coverage.

Do you use the best automated tools to discover security issues in your code?

We currently use a combination of static analysis and automated code tools against our code base including cargo clippy, semgrep, in addition to tools that we have developed in-house. We are looking to advance our use of automated tools in our CI pipeline in two key areas in 2024:

• Expanding our use of tailored rules to identify more points of interest (e.g. changes to sensitive code areas) and informed by our defect escape analysis efforts.
• Establishing an ongoing cadence of dynamic analysis tools (primarily fuzzing) at various key areas of our code base.
  

Do you undergo external audits and maintain a vulnerability disclosure or bug bounty program?

Our external audit of our zkVM was completed by Hexens and is available for public review. We are currently scoping a second round of zkVM auditing from a second vendor so that we ensure diversity in our audit coverage.

We have also recently launched our public bug bounty program on HackenProof, and we are currently ranked second for highest potential payouts. We are very excited to engage independent zk and securirty researchers in this way and are looking forward to seeing your submissions!

Have you considered and mitigated avenues for abusing users of your system?

This is a primary goal of the architecture risk analysis process described above, and we think contextualizing attacks in the context of our design is the best way to maintain currency with our threat models.

Special thanks to Trail of Bits, Solana Foundation, Fireblocks, Immunefi and others for their contributions to the Rekt Test. We are excited to share our results with the community and look forward to your feedback.