Before, during, and after, too: MythX and what happens after deployment

Mike Pumphrey
Jun 21 · 3 min read

We talk a lot here on the 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 . 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 .)

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?

Unfortunately, no.

Why is this? Because new vulnerabilities are being discovered.

For example, we help to maintain the , 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 after all), and we expect new vulnerabilities to be added to this list in time.

After

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.

Thankfully, we’ve got help in this realm. Our friends at are using MythX to scan every single contract on mainnet. Every. Single. One.

They also have this fun little section called the . While it’s a cute page, it’s detailing the most vulnerable contracts on the entire blockchain, so keep your distance from those sheep.

Baaaad.

In addition to Amberdata:

If one of these integrations doesn’t suit your fancy, we encourage you to build your own (, 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.

And beyond

We’re constantly improving our algorithms too. The complex interplay between , 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.

ConsenSys Diligence

ConsenSys Diligence has the mission of solving Ethereum smart contract security. Contact us for an audit at diligence@consensys.net.

Thanks to Bernhard Mueller.

Mike Pumphrey

Written by

ConsenSys Diligence

ConsenSys Diligence has the mission of solving Ethereum smart contract security. Contact us for an audit at diligence@consensys.net.