Many services are marketed as security audits. This causes confusion on the market.

We identify the following audit types in the blockchain world:

- Smart contract audits

- Blockchain audits

- Product audits

- Penetration testing

Let's briefly discuss each type.

Smart contracts security audits are what most people think about when talking about blockchain / security audits.

This type of audit consists of reviewing a specific version of a smart contract source code. First, the auditors should identify all user roles in the system (for instance: administrators, privileged users, standard users, non-users). Second, they will list for each user role the functions available to them. Third, they will look for each user role to call some of these functions either in an unexpected order, or with unexpected parameters. With the goal of manipulating the system into executing actions that shouldn't be possible for these users. For instance, a non-user would succeed in withdrawing funds from a privileged user. Or a privileged user would access an administrator function.

Smart contracts are most often written in the Solidity programming language. Recently, we are seeing more and more smart contracts written in the Rust programming language.

Even if a smart contract has been extensively audited, a newer version can introduce new vulnerabilities.

Some auditors will specialise in only one programming language. Some others work with several languages.

New blockchains are very ambitious, multi years R&D efforts. Some of these new blockchains are forks. In which case, they base their development effort from an existing blockchain. This can greatly reduce development costs and risks. For instance, Litecoin is a fork of Bitcoin, Ethereum Classic is a fork of Ethereum, etc
Some other new blockchains are entirely new codebases.

Blockchain software can be written in any programming language. These days, the most popular ones are Rust, used by Solana and NEAR, and Go Lang, used by Go Ethereum.
Auditors for a new blockchain should be familiar with the programming language used, or another related language.

When auditing a new blockchain, it is important to understand the intended security architecture of the protocol. The main goal of the audit is to verify that the intended security architecture was correctly implemented. As well as preventing attacks such as double spending, loss of consensus, down time, and manipulation of governance mechanisms if any exist.

In most cases, a software product includes a user interface. In DeFi, Web3 or Fintech, the smart contracts often interact with a backend server. The backend server code can be open source or proprietary. The user interface will communicate with the backend server. And it will also use the local wallet such as MetaMask to sign transactions and authenticate the user. Besides, there will often be one or more (centralised) databases such as PostgreSQL or MongoDB, and a OAuth2 authentication service such as AWS Cognito, Auth0, Google Login, Twitter Login etc.

With this bigger picture, we can see that the smart contracts are just one very important piece of a much larger puzzle.
A Product Security Audit consists of verifying that:

- each component implements correctly their functionalities,

- all components interact with each other (API calls) as expected,

- no information leaks are possible,

- unauthorized accesses are prevented,

- system deployment procedures (devops) follow industry best practices.

This requires a different skillset from smart contract security audits. A strong understanding of large software projects architecture is essential, as well as familiarity in navigating codebases written in multiple programming languages. The frontend will typically be written in ReactJS, the backend services in a mix of NodeJS, Golang, Python, etc. and the smart contracts in Solidity or Rust. Finally, many tools will be involved such as blockchain nodes, database systems, Docker container management techniques, and so on.

Finally, penetration testing is a security audit focused on external API endpoints offered by Web2 backend services.

The goal of the pen testing auditor is to call some of these API using unexpected syntax to gain privileged access. Using this priviledged access, the attacker either tricks the system into performing unauthorised actions or leaking confidential information.

Penetration testing does not necessarily require extensive programming knowledge. On the other hand, a Product Security Audit should identify bugs in the backend code that let penetration testers access the system.

Penetration testers can attack the system without any credentials, or use a fake user credentials. If they are provided with a full list of backend API, they will likely be able to prepare more attacks against the system.

We hope you find this article informative and that it helped you better understand the different types of security audits. Do you have any questions? Please get in touch by email info@jitadigital.com or telegram @jitadigital !