Our Guidelines and the Future of Ethereum Security
Who we are
SecurEth is an initiative to drive Aerospace-grade security into Smart Contract Development through the adoption of guidelines like DO-178 from industries with established histories of delivering secure and robust software. We are also now supporting the general Ethereum Security community through ETHSecurity (more on that at the end!).
Our team met originally through ETH Denver, where we won a prize for our work developing our initial guidelines framework, as well as a static analysis tool for assessing risk in Solidity contracts. There was a lot of positive feedback for our work, so we applied for and won an Ethereum Foundation grant awarded in the May cohort.
Since winning the grant, we have been focused on delivering our guidelines to the Ethereum community. We pushed a first draft of this, using GitBook, back in mid June during a retreat in Minneapolis. Here’s a picture of us there!
What we did
Our Development Guidelines are designed to help all developers follow a secure development process in their projects. We have worked hard to include the wisdom our editors have gained from both their prior experience in other industries as well as their experience in the Ethereum space. If you want to dive into understanding what the full process looks like, check out our landing page here:
Alternatively, if you are preparing for an audit soon, please check out the following introduction to understanding that process:
Why it is necessary
The most obvious answer to why we created our guidelines is the prevalence of hacks. Millions of dollars have been lost over the past several year due to hacks of smart contracts. The reasons why these hacks are so prevalent is obvious: smart contracts are immutable, and people make mistakes coding them. Smart Contracts on Ethereum are a relatively young field, and we are all still learning about secure patterns and processes in this new space. That, combined with the extremely hostile environment we place these small software programs in — where everyone has access to the network and anyone can exploit them according to the rules of your contract — means that these hacks won’t be reduced through pure force of will alone.
Our guidelines discuss how to reduce risk, which is essential to mitigate issues before they happen. Risk reduction is a mindset, and best exemplified as a multi-step process. It involves running multiple tools, reviewing with multiple people, and having a deep understanding of exactly what the code you wrote is doing, in the context of the framework that it runs on. It involves planning ahead: how will you respond to issues when they occur, under what conditions can you recover from those issues, and how can you prevent small miscalculations from becoming catastrophic losses to your users.
“Security Audits” (a commonly-used misnomer for a security review or assessment by a 3rd party firm) are the current de-facto mechanism in the crypto-sphere to ensure security. While they are a very important part of a secure process, they can’t be relied upon to catch everything. Reviewers have limited time to review, and there are many projects out there waiting for their expertise and time. Demand is high, prices are high, and security falls by the wayside as projects eager to push through leave this step to the last possible second, if they do it at all. The readability of the code-bases they are provided with are low, and any documentation provided to actually explain what it does is often non-existent. An auditor’s job is very hard this way!
The truth is that no one understands the project better than the person who wrote it. It is your job to thoroughly test the application as best as you can, as well as to convey to the reviewers what the intent of the application is and how to assess it. No one can do this job better than you can, and without this documentation reviewers cannot do their job effectively: provide you expert feedback on your application and any exploitable holes it may have. If you don’t provide them this, they will have to waste your money trying to figure it out for themselves, which means your review isn’t as through as it could be and there is an increased risk of a catastrophic event.
Following our guidelines will make your code more readable, understandable, and ultimately cheaper!
However, that is not the biggest reason why we wrote our guidelines. The biggest reason is increasing developer understanding. There are many new developers entering this space with wide eyes and wild imaginations of what is possible. Many of them do not have the benefit of a career in software security, or the wealth of experience that more senior developers in this space have. It is our job to help them by distilling our experience into something easy to follow, aggregating our collective experience for them to draw on as they have questions.
A big part of that is live discussion: classes, mentorship, and joining the wider Ethereum community. Not all of us have access to these benefits easily, so we need a place to point others to so they can understand what is best, as well as a handy reminder for ourselves in times of need. Who knows, us experienced professionals may have a thing or two to learn in the process! This space is very much about questioning your assumptions and building better systems.
That is why we wrote our guidelines.
How to use it
Hopefully you are now fully convinced why it’s important, so here is a call to action: use our guidelines!
If you are new to the space and looking for a guide, read over what we have to say, and raise a new issue if you want something clarified or explained better.
If you have prior experience with smart contract development, consider contributing to them: propose new content, edit existing content, or provide general feedback through a new issue.
Either way, feel free to join our Discourse. We use this communication channel to discuss issues with our guidelines, as well as more general problems with security in Ethereum applications.
If you don’t understand something, that is not your fault, it is ours! We won’t know about it unless you tell us! That is the only way it gets better :)
See you at ETH Berlin!
SecurEth is joining the larger ETHSecurity effort at the Security Unconf in Berlin on September 6th. It is an all day event intended to bring the security community closer together. Our attendance list is full, but we will be posting videos of the event’s talks and workshops. Please look out for those! We will probably be participating in DevCon as well.
In the future, we will be looking to integrate our efforts with ETHSecurity through a guidelines working group that is forming, as well as more general assistance of the ETHSecurity effort as it continues to grow and form. Our hope is to eventually support the community actively in its future growth, ensuring a strong mindset for security in Ethereum!
