By Mitchell Telatnik
As I have watched the state of smart contract security mature, I can’t help but notice the parallels between securing smart contract code and traditional IT applications. While the strides that have been made in securing contracts is beneficial, I feel it is important that we transfer the lessons learned from the traditional IT world to the world of blockchain.
In the traditional IT security industry, penetration testing and vulnerability scanning are related but separate activities. Many cybersecurity compliance requirements will specifically require an organization to perform routine penetration tests (such as quarterly or annually) as well as maintain a vulnerability management program.
While a penetration test will often utilize a vulnerability scanner as part of the engagement, the tester will utilize the results of the scan to help guide their manual efforts. The tester will actually attempt to exploit the vulnerability and demonstrate its effectiveness and damage to the confidentiality, integrity, or availability of information.
While the manual analysis of a penetration test is important, very few organizations have the resources for continuous penetration testing, often termed “red-teaming”. However, even if an organization performs quarterly penetration tests, they are simply snapshots in time. Instead, organizations incorporate automated vulnerability discovery tools to fill the gaps between penetration tests.
In the case of smart contracts, a similar approach should be taken. Often, the developer of a smart contract will submit their contract to an auditor, who will review the code for security vulnerabilities, and, after remediation, provide an attestation. While automated scanning should not replace this manual audit process, it will be important to also utilize automated tools.
As the landscape of vulnerability management for traditional IT matured, the industry moved from point-in-time assessments to continuous scanning and vulnerability remediation. Because the environment changes, organizations faced the issue of running a vulnerability scanner, remediating the results, and then finding out new vulnerabilities emerged between scans. Shortening the time between scans and concurrently running vulnerability discovery and remediation efforts ensures organizations stayed on top of what vulnerabilities were present.
Smart contracts on the other hand are immutable, meaning once deployed to a blockchain cannot be changed. However, this will continue to change as blockchain developers continue to leverage technologies that allow contracts to be updated. Smart contracts that act as proxies and point to a secondary contract that contains the logic are becoming more and more popular due to the ability to issue “updates” to smart contracts while maintaining the same (proxy) address.
I predict that just as we saw the move from large periodic software updates (or none at all) to a continuous integration and continuous deployment (CI/CD) model, we will see the same shift in smart contract development. As this shift happens, the need for continuous vulnerability assessment will become more critical.
As vulnerability assessment for custom applications become more mature, organizations found themselves struggling with the process. Often, the security assessment of code written by developers didn’t occur until late in the development process. This caused a headache when vulnerabilities were found and the code had to be sent back to the development team to fix, sometimes requiring major logic changes.
This struggle birthed the idea of “Shift-Left”, which is moving the vulnerability assessment process earlier in the development process. As smart contracts become more complicated, it will be important to shift the smart contract vulnerability assessment process earlier in the development cycle as well.
Currently, it is common for smart contract developers to create their smart contract and then submit it to an auditor to review. The auditor will then come back with a list of identified vulnerabilities and remediation recommendations. After the vulnerabilities have been fixed by the developer and the auditor confirms they have not found any new vulnerabilities introduced, they will provide an attestation.
This process may not be a huge lift for simple contracts, however, as they become larger the remediation effort may require a large effort to rewrite the logic without vulnerabilities. Shifting the vulnerability assessment process earlier in the development process will allow developers to catch vulnerabilities sooner, and reduce effort when they eventually submit the contract for an auditor to review.
Smart contract development is still in its infancy, with developers exploring the capabilities and use cases for building on a blockchain. The smart contract vulnerability assessment industry is also in its infancy, but has many parallels with vulnerability assessment of traditional IT environments, something we have a much longer history with.