Part 3: MythX ❤️ Continuous Integration (DIY)

This is the third and last post in the MythX series on integrating security analysis of smart contracts into your Continuous Integration (CI) system. In the first part we built a CircleCI configuration. In the second part we built a small and beautiful Travis CI configuration.

“But I am using a completely different CI system!” – You, maybe.

Fret not. The avid reader might have noticed a common pattern in the past two posts: In setups we used the MythX CLI and a basic Python runtime. If you have not read the previous articles yet, it is recommended to do so. Do not worry, I will wait here.

Generalizing our Approach

Sending things to MythX for analysis is rather simple if you are using one of our many tools and integrations. Roughly speaking we always do the following:

1. Download and set up an official tool
2. Run the tool on one or multiple target files
3. Wait for the results be returned by the MythX API
4. If the report contains anything critical, fail the job

Available Tools

The MythX analysis engine is made available through a REST API. This means that there are analysis tools readily available for most common languages and frameworks. Are you using Truffle? Check out the MythX Truffle plugin. Do you prefer Python and use Brownie? Brownie ships with built-in MythX integration – no setup required. Or do you prefer a minimal JS client to eliminate the Python dependency? Thy sabre! Or maybe you want it as comfortable as possible and not configure your CI server at all. Then Guardrails is for you!

Or simply roll your own. The MythX documentation is a good starting point to build the tool that perfectly fits your needs. You could also dive head-first into our OpenAPI documentation if you prefer looking at data structures instead of text blocks. Whatever your choice is, the MythX team welcomes and supports all builders!

Advanced Usage

This blog series is meant to be a starting point for CI integrations. It is by no means exhaustive. As the main developer behind the MythX CLI I can’t help it however to throw some cool ideas for advanced users out there. All setups described below are possible with the current feature set of the MythX CLI. If you have implemented them in your project, please share your experiences with me. I am determined to polish the application even more, make it more reliable, and I would love to feature your use case in another blog post!

Long Analysis Jobs

So far we have only discussed “quick” mode submissions. These usually take about 120s to finish. A CI server can wait this long. But what if you have a MythX subscription that allows you to do “standard” or “deep” mode scans? These allow for up to 90 minutes of scan time.

Given these long analysis times the CI job would probably time out and fail in any case. The MythX CLI solves this problem by introducing an --async flag. If this flag is given, a list of job IDs will be printed and the CLI will not wait for the analyses to be finished.

This in turn means that scan results are not available inside the CI logs. The submitted scans can be viewed in the MythX dashboard once they are finished. Running asynchronous analyses is as simple as:

mythx analyze --async 

Storing Artifacts

Sometimes you want to persist files from your CI job. Let’s say you have a dedicated security verification pipeline where people are continuously monitoring the state of your smart contracts and fix vulnerabilities once they come up. You now want to provide this pipeline with data as soon as the MythX analysis has finished. Disregarding the specifics of your CI system, the MythX CLI allows for file outputs in various formats. E.g. we can take the analysis results, format them in pretty-printed JSON and store them in a file:

mythx --output security.json --format json-pretty analyze 

In your CI server you can now specify the output directory as an artifact file and e.g. directly push it to AWS S3 with Travis.

Filtering Results

There might be things you do not want to see in the MythX CLI output. For that reason, we have added two features: Severity filtering and SWC blacklisting. If you are tired of us reminding you that your code has a floating pragma statement, simply blacklist this SWC.

mythx analyze --swc-blacklist SWC-103 

If this is not enough, simply add more SWC IDs as a comma-separated list to the parameter. But maybe low severity issues in general are none of your concern and you are only interested in everything above Medium. That’s what the severity filter was made for:

mythx analyze --min-severity high 

Conclusion

Security checks in continuous integration systems are not too hard. When the tooling is right and a little setup time is invested, it is not impossible to always have updated security reports at your fingertips. The Ethereum ecosystem is growing rapidly with innovations in smart contract development being made on a daily basis. It fills me with joy to see such a huge amount of projects that try to make a difference, often just driven by curiosity and passion.

At the same time, it fills me with uncertainty how we secure such massive growth. In a recent analysis with our friends over at Alethio we have found out that the number of smart contract vulnerabilities is on a downward trend. Automated tools, dedicated security auditors, and passionate developers start to value security more and more. I hope that this blog series, and MythX in general can further contribute to this trend.

Stay safe out there!