Before, during, and after, too: MythX and what happens after deployment
We talk a lot here on the MythX team about the importance of regular, routine analysis of your smart contracts prior to deployment onto the blockchain.
The reason for this is simple: once the contract is deployed, it is immutable. Any vulnerability in your code that you deployed will be there forever.
In this way, you can think of contracts on the blockchain like embedded systems. Once the widget is sent out of the factory, it will always do whatever it was programmed to do. Forever.
(Which, incidentally, is why we should probably be slightly concerned about the Year 2038 problem. Yikes!)
Before and during
Our prescription is easily told: we recommend using MythX through every stage of the smart contract development life-cycle.
We also highly recommend a manual audit before you deploy, to find the business logic errors that an automated tool can’t detect. (We might be biased, but we can’t say enough good things about the team of auditors at ConsenSys Diligence.)
But all of that happens before deployment. What about after deployment? Can you just kick back and wash your hands of the whole security thing?
Why is this? Because new vulnerabilities are being discovered.
For example, we help to maintain the Smart Contract Weakness Registry, a list of the most common vulnerabilities in smart contracts. We believe it to be comprehensive, but it is a living document (it’s on GitHub after all), and we expect new vulnerabilities to be added to this list in time.
In short, what is deemed secure today is not guaranteed to be secure tomorrow.
That is why we recommend doing regular security scans of contracts after they are deployed too.
They also have this fun little section called the Wall of Sheep. While it’s a cute page, it’s detailing the most vulnerable contracts on the entire blockchain, so keep your distance from those sheep.
In addition to Amberdata:
- We have partnered with Alethio to integrate our security analysis on their analytics platform.
- One of the winners in the 2019 Ethereal Hackathon that we participated in was a contract vulnerability monitor. Just input your contract to the webapp, and if a vulnerability is found, you’ll receive an alert.
If one of these integrations doesn’t suit your fancy, we encourage you to build your own (there’s revenue in it for you if others use it, too).
So what happens when a new vulnerability is found and you are affected?
Because the contract itself is immutable, you’ll need to deploy a new contract, and point people to use the new one instead of the old one. There’s not much else one can do around that.
But with MythX, at least you’ll be prepared, and not be under the illusion that what is deemed secure today will be deemed secure always.
We’re constantly improving our algorithms too. The complex interplay between our microservices, Harvey, Maru, and Mythril, can lead to uncovering lots of potential vulnerabilities, and we’re exploring ways to find even more deeply hidden secrets.
MythX is a vital tool in your development toolbox, and that extends beyond the deployment stage. Your work isn’t ever really done, but luckily, neither is ours.