Introduction
When we talk about web3, one of the most important characteristics of its underlying technology (blockchain) is its immutability and traceability, where a code error can cost the life of your project. In this blog, we will cover my experience dealing with the transition from web2 to web3 from the security software engineering perspective.
When security comes first and not last
Security is usually seen as a cost center for most startups out there, where the main focus and budget go first to develop your application, and lastly, if there is time, they might worry about security. This is scary and dangerous as security needs to be a must not a “maybe”.
When we take a look at web3, we notice something interesting that has not happened in web2, and it is that we are seeing the maturity of this technology in implementing security from the beginning. When you deploy your application in the blockchain is not as easy to patch as in web2, so any error in the code base is an expensive one, if it is a security issue it might cost the life of your project.
This position security is one of the first foundations for any dApp that is being built, where developers and security engineers work together to implement the safest version possible before being released.
In web3 we can see audit contests before going to mainnet to secure your code in the best possible way, freelancer auditors, and a lot of desire from the different projects to hire the top-skilled cybersecurity professionals out there to secure your projects.
The distributed cybersecurity professionals
~6 years ago, I started working professionally with web2 with a strong focus on security, back then, security awareness and security engineers job positions were something that only big companies cared about and hiring was limited to big countries such as USA, these big firms never hired security professionals outside their borders.
This is changing. Now we can see a lot of companies hiring remote security professionals to fulfill their needs as the complexity, seniority, and skill set are growing in web3, causing the companies to break through these old rules of limiting their talent to a geo-specific location, talent is everywhere, and it is rarer to find if you do not go worldwide.
The required skill set for security in web3
In web2 it is common to find job positions that require you to do a lot of things, from pentest, secure software engineering, vulnerability management, compliance, and incident & response for a single position, this rings bells and suggests that the company does not know what they need. Very mature firms know that role-specific is the key, security is a big spectrum that requires not only specific knowledge but also passionate professionals.
In web2 we know that we might need a specific set of skills for a specific role and they do not vary too much from time to time, but in web3 this completely changes if you want to become, for example, a smart contract auditor, you will need to be able to move faster than in web2, evolving and improving every day in a faster pease than in web2. This requires you not only to know security but also to know the underlying technology (Blockchain), frameworks (foundry), Lints, and programming language (Cairo, Solidity) at a deeper level, as well as the protocols running on top of the solutions and the common vulnerabilities that affect all of this. Being such new technologies, they change much faster than what we may be used to in web2, which can cause stress, loss of emotion, insecurity, and many other things, so, in my opinion, it can become a challenge.
Finding a professional with these characteristics, expertise, and willingness to learn is a challenge in the ever-evolving web3 landscape, where there is a lot of uncertainty and mindset change in between.
The lack of standardization
When we are working with vulnerabilities in web2, we have the CVE (Common vulnerability and exposures), which are the identifiers for a particular vulnerability, and most of them are managed by NIST. As of today, there is no such counterpart for web3, making it difficult to focus on specific findings or a “general” way of calling it.
There is something similar to the CVSS (Common vulnerability score system) that is called BVSS (Blockchain vulnerability score system) which is the closest to the CVSS for web3.
There is also the OWASP Top 10 that mentions some of the common vulnerabilities in smart contracts, which is a good move!
Howevert there is na mature counterpart for SCVs (Smart Contract Vulnerabilities), there are some efforts such as swregistry.io and scsvs but they are not longer maintained.
This is a real challenge, in web2 we rely on a central authority that acts as a judge to tell us if something is vulnerable or not. Of course we can disposition our own findings and come with a solution for it, but until is not standarized it will hard to keep track of how many apps outthere are still affected by this.
The lack of a central authority
The beuty of blockchain is the decentralization, but this brings to the table some challenges that have to be overcome. One of the challenges is the lack of a Security Central Authority such as NIST in the web3 space. This means that we are entering to a new tech field that has not been taken yet! There are thousand of opportunities to standarize all the findings and suggest a proper resolution such as OWASP, or maybe an specific dApp L2 that acts as a validator for the common vulnerabilities out there within the blockchain, but we have not come to that place yet..
Conclusion
The auditing of smart contracts has gained a lot of popularity and importance in web3, with hundreds of dollars for each line audited, high awards for findings in audit competitions, and audit firms offering close support, this has never been seen before, which has its advantages, disadvantages and endless opportunities, it is a niche where perseverance and experience play an important role, but a minset change is needed to overcome the complexity of a new technology.
