Why is enterprise blockchain technology so hot right now? It comes down to two main reasons: the existing barriers to multi-party data sharing and processing are too high, and everyone wants to force everyone else to use their own system and data format. So what are the blockchain risks that need to be understood before adopting blockchain?

1. The old software

While enterprise blockchain software is rarely "old," for software, anything older than a year or two is essentially a Stone Age tool in terms of rate of change and improvement.

R3's open source Corda blockchain platform is a good example. From its initial release in May 2016 to May 2021 (version 4.8), there were 182 releases of Corda, about one every 10 days. Many of them are not minor versions either; Major new features and refactoring or removing code are common. In most enterprise projects, there is a real tendency to pick a software version and then never upgrade because the upgrade has the potential to break something.

The lesson here is: Make sure your software is up to date and can be continually updated, but if not, why not?

2. Lack of security vulnerability coverage

Enterprise blockchain software has little coverage in security vulnerability databases. This means that most users, unless they explicitly track the vendor's release instructions, will not be aware of security updates.

This lack of coverage, especially with the Public Vulnerabilities and Exposures (CVE) database and the US National Vulnerability Database (NVD), is a huge problem because if vulnerabilities are not officially recognised, then for many large organisations they do not exist.

Not sure why blockchains have such poor CVE and NVD coverage, but one possible culprit is the lack of official documentation of specific blockchain-specific vulnerabilities.

3. Lack of knowledge about security vulnerabilities

Traditional software has well-understood vulnerability types, many of which are documented in the online Common Weaknesses List (CWE) dictionary. For example, the difference between buffer overflow and integer overflow is a popular vulnerability exploited by hackers. CWE is an important resource. Many code scanning tools use this as the basis for the types of vulnerabilities they are trying to detect.

However, as of May 2021, CWE has no documented vulnerability types that contain blockchain or smart contracts. The good news is that there are two works to document these issues, the SWC registry (which has over 30 entries about Solidity smart contracts language used by Ethereum and other companies) and the Cloud Security Alliance's Blockchain DLT Attack and Vulnerability enumeration database with over 200 entries, Covers various smart contract languages, blockchain technologies, and general concepts.

4. Lack of code scanning and security testing

Current blockchain and smart contract code scanning tools are not very mature, simply because the field is so new. To make matters worse, many smart contracts are deployed without security audits. But this is starting to change, and there have been a number of security incidents that have brought home the importance of auditing code and generating new keys before deployment.

For example, Paid Network, a provider of blockchain decentralized applications (dApps) for financial transactions, was compromised when it deployed a smart contract it Paid developers to create, but it never removed the developers' secret keys. When the developer's key was later publicly exposed during a Git commit, a process that saves program code to a repository, an attack depleted the paid network contract.

The contract has passed a security audit. Auditors cannot audit the production secret key because that would expose it, so they would assume that the Paid Network would replace it with a securely generated key, but it did not.

5. Operation risks

Assume a secure blockchain and well-formed smart contracts without any security flaws. Still have to run blockchain and smart contract code on something, preferably well-connected and reliable. If you choose cloud or third-party hosting, you will need to ensure that they are also secure.

6. Encrypt the key and HSM

At the core of every blockchain service and client is an encryption key. Even with dedicated systems, it is no longer sufficient to keep important encryption keys on the computer.

Instead, a Hardware Security module (HSM) is used. HSM basically provides two things that regular computers do not. First, you can set the key so that it cannot be exported or copied from the HSM. Second, HSM allows you to document key usage more reliably.

This is critical because if the network is compromised, it will be possible to determine what the attacker is using the key for, rather than speculate that they might have done something bad.

Conclusion

There's good news and bad news. The bad news is that blockchain and smart contract software are more complex and difficult to secure than almost anything else. The good news is that the problem they're trying to solve is really hard. Want to build information processing systems knowing that attackers are malicious but not allowing them to compromise the system. Solving this problem will open up all sorts of new markets and opportunities.