Learnings from the ETHSecurity Community

The ETHSecurity community aims to encourage and support collaboration, research, and education around the topic of security in the Ethereum ecosystem. It does this by curating a repository of knowledge, facilitating communication, organizing conferences, and leading working groups for needed community projects. The community already has 170+ members and continues to gain traction with individuals and industry bodies alike.

Building secure web applications is difficult. Building secure, smart contract powered, decentralized applications requires an entirely new paradigm of programming. As the Ethereum ecosystem continues to expand and welcome many new developers there is a need to provide them with resources, processes, and tools that guide them toward building secure, decentralized applications.

Some History

ETHSecurity launched in late May when Robbie Bent, after experiencing a frustrating smart contract auditing process at Truebit and a successful community interview process with ETHPrize, invited me to help him replicate the interview process for ETHSecurity. The goal was to create a robust community with the largest players in the security field, illuminate needed tools and projects in the space, provide grant funding for those projects, and move toward common guidelines or standards for the community. Our first interview was with Christopher Brown of Modular who then joined us in the interviewing and organizing efforts.

Since then ETHSecurity has conducted a total of 29 community interviews with best in class smart contract auditing firms, opsec experts, security researchers, bounty hunters, and complex DAPP developers. From these interviews, we seeded conversation in a Telegram group of security professionals (172 members at the time of writing) and began to shape the content for the Security Unconference on September 6th in Berlin.

Along the way, hundreds of human-hours were donated by volunteers to generate momentum. Most notably, ETHSecurity teamed up with Bryant Eisenbach, Rex Hygate, and Roman Pavlovskyi of SecurETH, who had begun the groundwork for the unconference at the suggestion of Maurelian. Their work was instrumental in conducting the unconference and building enormous traction in the ETHSecurity Community.

ETHSecurity was also a recipient of an Ethereum Community Fund grant to support the interview process, the creation of this report, and community building up to now and through DevCon. Their efforts have been incredible and we are so excited to continue building together into the future.

The security unconference was oversubscribed and hit max capacity, ultimately having 90+ attendees with 8 lightning talks about the current state of security in the ecosystem, as well as 8 workshops. Workshop topics included:

• Community structure and organization
• Centralized wiki/repository for security resources
• Developer and auditor guidelines
• An assessment stamp
• Building better tooling
• Smart contract upgradability
• Open-source code assessments
• Trustlessness issues (aka. smart contract access control issues)

Each working group defined the issue, outlined potential solutions, created an action plan, and selected champions to lead the working group effort moving forward.

We are ecstatic about the success of the event, connections made and knowledge shared, and are building toward a working group gathering as part of the Status Hackathon in Prague, prior to DevCon.

ETHSecurity Findings

We will display findings in two parts. The first is through the top quotes selected for the community interviews that highlight both successes and needs of the ecosystem. The second is through trends found through the interview process and unconference. Links to the primary documentation are below.

• Community interview notes
• Synthesized findings
• Unconference working groups

Below are some of the top quotes selected from the community interviews, originally tweeted by Robbie Bent.

1. Security audits are not a statement that code is safe. The outcome of an audit is that you learn about the code you wrote and your code does what you want it to. @dguido
2. If you don’t put in a mechanism for upgrades — you’re toast. Upgradability is becoming an industry standard and minimizes the risk there will be a flaw in the system. @izqui9 / @sohkai
3. We need a Common Vulnerability Database for smart contracts to track and disclose issues https://cve.mitre.org/ — it can be done decentralized, autonomously, and on a blockchain. @__Tux
4. Remix is the most helpful tool for auditors. It’s rare that you have something that allows you to look at entire code base, can compile it and test it and debug it. @cryptodavidw
5. Tools guide you to the places that need more attention, but will never supersede manual review. @maurelian
6. A package manager would be a big milestone for crypto. Code reuse is done “copy paste” — a version is copied at some point in time and all community security updates are missed. @maraoz
7. There is a tendency to hire offensive security like pen testing and code audits. Have somebody security focused writing code in the design phase. @find_evil
8. Excited about languages that offer a subset of Solidity functionality preventing certain kinds of mistakes. Programming smart contracts is akin to C but should be closer to Rust. @PolySwarm
9. We need to make it easier for developers to code with security in mind — Threat modeling and concrete examples of vulnerabilities like OWASP are needed to better understand security. @mhswende
10. We created a bug prediction market to provide incentives to find bugs post audit. Auditors can stake their reputation for a period of time to provide accountability. @SolidifiedHQ
11. We are building a service where you can see all the smart contracts and tokens and which have been audited by a security specialist. You can check which contracts were audited, and if the bugs found were actually fixed. @jakublipinski
12. The only real metric we have for how secure a certain practice is, is how much money a contract holds and how long it has been on the mainnet. @Corpetty
13. Auditing requires craftsmanship and can’t be automated yet — start by manually testing overflows, safemath, send problems, verifying loops and follow entire implementation. @clesaege

Below are ideas and trends from the community interviews and unconf working groups

* An asterisk denotes topics that already have a working group in motion

Ethereum Security Organization *

We need an neutral industry body to organize and facilitate a clear signal regarding security-related issues and community projects. The main efforts of this body would be the creation of working groups and management of their outputs, to schedule and organize conferences, as well as to manage and moderate channels of communication and repositories of knowledge. The organization should also facilitate bounties/grants toward needed projects in the space and house community assets such as the potential developer guidelines or assessment stamp. It makes sense for ETHSecurity to act as this body to begin and for the structure to determined by the community as the project evolves.

Security Wiki and Centralized Resource Repository *

One of the largest complaints in the space was the difficulty of finding relevant resources. Many topics have already had articles written about them, but they are not easy to find or access. This hurts development and education. It would be great to have one place where anyone entering the space or contributing content could go to find or publish knowledge.

Developer and Assessment Guidelines *

A very popular idea is to have guidelines for the smart contract development life cycle that will encourage secure practices and ease the assessment process. At the same time, there is a desire for guidelines for the assessment process so that as developers hire firms they can be reasonably sure what the process will be and what they are paying for.

Developer Training and Education

Training and Education was a crux for many interviewees. It is a scaling problem for Ethereum. As more developers come into the space they need to be onboarded with tools and resources for secure development. This could be housed in the security wiki and needed content could be paid for or produced by the industry security body. Any guidelines produced could serve as a great framework for new devs to work within.

Tools *

This topic is vast. It ranges from the tools that have already been created by community member companies to a tool that helps visualize a smart contract system’s access control and ownership to tooling that would help to ensure GDPR compliance to a tool that scripts audit reports and helps to estimate the effort and complexity needed to assess a set of smart contracts. It would be great to see more research and projects around formal verification, fuzz testers, and symbolic execution. One sentiment that did emerge was that tools only help to find problems, they will never totally take the job of a formal audit.

Assessment Stamp *

An assessment stamp proved to be a controversial idea in the interviews. The idea would be to provide a signal to investors and consumers about the rigor an application has experienced in its development. The stamp would hold data about what security assessments were performed, when, by whom, and on what code. It would only be granted if the recipient of the assessment implemented the suggestions of the auditing firm. This history would also allow meta audits of the original assessments. The downside that was expressed was that projects would seek this stamp only as a marketing tool and not provide the value others thought they might.

Open Source Auditing and Auditing Fund *

There are many common tools that could be audited. The EVM, geth, the solidity optimizer, etc, could all stand to be scrutinized. Some recent work has been completed toward geth and others, but as an ecosystem we need to be looking at the tools that many developers rely on. In the same stroke, we need to think about the process by which open source projects that may only have one or a few maintainers and are not part of a major company get these audits. Perhaps we should create a fund or facilitate grants towards these efforts.

Insurance As A Protection Mechanism

Another controversial topic. In order to gain mainstream adoption users want to have some sort of guarantee that they won't lose all of the value that they put into a system. Insurance may be a good way of mitigating that risk. On the other side, insurance may just act as a band-aid and allow us to keep lower standards to our development practices.

Key Management

Key management came up again and again as the biggest attack vector. The improper handling of keys in the browser, losing your seed phrase in your house, and being threatened with rubber hose cryptography (bodily harm) all came up as things that keep people awake at night. There didn’t seem to be many answers to the problem, but it’s a biggie.

Data Privacy

This seems like a more traditional tech topic, but it applies just as much to blockchain companies, and GDPR is still very much a concern. There weren’t any answers to this problem either, but it also keeps people up at night.

Common Vulnerability Database

This idea is to create a MITRE-like tracking system for smart contract bugs. Pretty straightforward. Achievable. Could live on the security wiki.

Vyper

Vyper, the smart contract language that was designed to do less in order to keep the ecosystem more secure. It was mentioned many times as a needed resource in the ecosystem. We should encourage its development and adoption.

NPM (Node Package Manager) Security

Since the data layer of the blockchain is incredibly hard to attack it is now the user’s keys that become the target, and it is the plumbing of the rest of the traditional app that makes this vulnerable. It would be awesome to have a list of formally audited npm packages that the community could rely on.

Bug Prediction Markets

It was said multiple times that there is a misalignment of incentives between auditors and clients, mostly having to do with an auditor’s role being finished after a code assessment. Bug Prediction Markets Help to address this misalignment.

White Hat Hacking League

A hacking league to track the education and training of individual developers as well as to build reputation among seasoned veterans. Would likely consist of a program like EtherNaught or CaptureTheEther and a bug bounty platform with a leaderboard.

A Common Benchmark Suite for Tools

How do we measure the effectiveness of the tools we build? If we are relying on these tools to point toward vulnerabilities we certainly want to raise their level of accuracy. There are already some efforts toward this in the community which would be good to support.

Identity

Identity is a huge rabbit hole of its own and a very big problem. There aren’t any great solutions as of yet, but identity was brought up multiple times as an issue related to security. We should think about funding efforts in this direction.

Access Control Best Practices *

“onlyOwner” is the only common access control that is implemented on smart contracts. It is also the weakest point of many contracts since it is a single point of failure. If you lose this key, you lose security of the system. Again, this comes back to key management, but it would be cool to see a standard emerge around complex access control in smart contracts.

Next steps

If you are at all interested in building toward any of these topics, please, dig into the synthesized findings, raw interview notes, and outcomes of the Berlin workshops. There are many more ideas expressed there in much more detail.

Join us in the working groups! We will release the dates and times for working groups soon and would love for people to join us. Most of the group work is happening via Telegram. Hit me up @captnseagraves and I can connect you to the right group.

Let’s continue the conversation on the Ethereum Magicians forum! If you have any resources to add to the wiki, please submit a PR on our Github.

Our next ETHSecurity Community call will be Friday, October 5th at 11am MT. We would love to have you!

I also want to thank everyone who has donated time through interviews, telegram, community calls, the unconference, and working groups. It’s been a blast so far and I’m stoked to see where it goes. I will try and tag as many people as I can think of. Rob Bent, Bryant Eisenbach, Rex Hygate, Roman Pavlovskyi, C. Brown, Clément Lesaege, Lukas Cremer, Gerard, Jorge Izquierdo, Brett Sun, Yo Kwon, Dan Guido, Adria Massanet, John Pacific, David Wong, Martin Swende, Kacper Bak, Jared Harrill, Olga V. Mack, Jonathan Haas, Nick Munoz-McDonald, Liz Steininger, Manuel Araoz, Jackie Stokes, Avesta Hojjati, David Goldberg, Mehdi Zerouali, Paul Hauner, Adrian Manning, Isaac Patka, Brandon Arvanaghi, Adam Kolar, John Mardlin, Dick Olsson, Corey Petty, Edward Thomson, Jakub Lipiński, Cassandra Shi, Chris Lema, Hugh Lang, James Duncan, Kenneth Ng, Maria Paula Fernandez, and so many more!

Thanks for reading! We’ll see you at DevCon!