Announcing the Web3 SDLC: Secure Development Life Cycle by Philip Gillett

my name is Philip Gillette and I am a web 3 software engineer with arbitrary execution so a little bit about us we are a company made up of security researchers who have a passion for decentralized Technologies much like everybody at ethanver does our company was founded about two years ago to fill the need for securing smart contracts through Audits and in that two years we have conducted more than 40 Audits and we've created a number of tools that monitor blockchain transactions for anomalous activity today I'm going to talk about the web 3 sdlc or secure development life cycle so the S is for secure and this is a comprehensive security plan that protocols can use to incorporate security into every phase of their projects and that goes from their initial concept all the way up to responding to potentially malicious blockchain transactions so I saw some of the talks before all the security guys are going to be talking about this but the last year has really been a rough one for web 3 protocols even if we don't talk about the collapse of the big centralized exchanges a lot of value was stolen scammed hacked or just lost and the thing is that nobody wants to appear in the next tweet from wrecked news or in the next article from web3 is going just great and yet here we are it keeps happening so as an audit company our objective is to help secure web 3 but we believe that the current approach to security needs Improvement one of the greatest features and I think this is on display at ethanver one of the greatest features of web3 is how quickly a project can go from just an idea to live for the world to use there are great resources for creating your first smart contract forking the blockchain locally testing it all out and then ultimately deploying to a mainnet but if we look at how most web3 projects approach security there's this common pattern emerging so in this timeline security is seen as one step in the process it's treated like this snapshot in time that's handled by experts who get paid a premium for their findings and they deserve that premium the problem is that your developers are not Security Experts because they're spending their time building and getting the code up and running converting your idea into an implementation so as a result security practices are rarely incorporated into the web 3 development life cycle Benjamin Franklin wrote that an ounce of prevention is worth a pound of cure and that is also reflected in the 110 100 rule proposed back in 1992 that illustrates the cost of dealing with poor data quality throughout different phases of a project and we believe that also applies to fixing security issues so if we look at that previous timeline on a curve that shows the relative cost to fix those security issues at different phases of the project you can see starting on the left you've got your idea you figure out your architecture and then you start coding everything up enforcing security here on the left side is a matter of prevention and it's at least an order of magnitude cheaper than having Auditors do it for you in the middle part of the timeline is where most projects inject security they've chosen a much more expensive way to deal with those security issues and that's through correction now this still may be 10 times cheaper than a bug Bounty or a hack but deep security expertise does command a premium so then once you've deployed your costs are driven by dealing with failure now hopefully you're lucky and I really emphasize lucky to find those bugs yourself and upgrade your contracts before attackers do and if not then there are really only two potential paths for those security issues bug bounties or hacks and neither of those is cheap to be clear your project should participate in bug Bounty programs no matter how secure you think that project is but for the bug bounties to be effective they really need to be proportional to to the potential hacks and that's because incentives are really still a thing the takeaway here should be that the longer you wait to fix security issues the more it's going to cost you the appropriate response is something called shift left security where security is considered and incorporated as early in the process as possible to that end the web3 sdlc helps you address security issues as early as possible each project is divided into four phases before I describe those phases these QR codes that are in the upper corner are links to more material that really complements what's in this talk so feel free to take pictures of it go to it later check it out in your free time so in the design phase your ideas are going to be considered in terms of their inherent systemic risk you're going to identify the intrinsic risk like you heard in some of those previous talks that intrinsic risk that you just can't avoid as well as risks that can be minimized or removed completely in the developed phase your ideas are converted into an implementation and you'll receive guidance on security secure coding best practices testing tooling and yes code audits in the deploy phase your project is going to choose a secure approach to go live to publish your project artifacts and to protect your private keys and then finally in the defend phase your project is going to monitor transactions alert you and your community to any concerning issues and then take action as needed now before I dive into these phases a little more I want to try to show you how this could have been applied in the last year and by the end of these examples hopefully nobody will be on the fence about whether or not this is a problem so talking about the design phase Beanstalk lost more than 182 million dollars due to a fundamental weakness in their governance mechanism normally proposals required a seven-day voting period before they could be executed however if a proposal received a super majority of votes which was defined as two-thirds of all potential votes that voting period could be bypassed and a proposal could be executed after only a one-day voting period so in brief an attacker created a proposal that would execute a yet to be deployed smart contract that would effectively just give him all the money then he waited one day into the voting period took out a flash loan to get that super majority of votes and then voted his own proposal through now we believe that with proper threat modeling in the design phase they could have considered how their governance emergency commit mechanism could be abused with something like a flash loan then we have blizz finance and Venus protocol both of these depended upon the chain link oracles as a dependency for Price data and everything worked as expected until it didn't work so when Luna crashed the chain link oracles hit what was called a circuit breaker and that meant that instead of continuing to report the correct and plummeting price of Luna all they did is what was all they did was report the last valid value which was right around a dime at the time unfortunately blizz and Venus both expected that those oracles were going to continue to report that plummeting price well so attackers took notice of that and then they saw the price disparity and arbitraged millions of dollars from both of these protocols the point here is if you know exactly how your dependencies behave you can design your smart contracts defensively to save you potentially millions of dollars if we move on to the develop phase we can see that Temple Dow had a staking contract exploited because they had one function that did not have proper access controls this allowed an attacker to basically fake out the contract so it would just send all of this the staked funds to that attacker now there are numerous places during development where this could have been caught that could have been in tests it could have been in code reviews and yes it could have been an audits but it wasn't caught this next one is a little more benign but it does show the importance of applying testing to both your original deployment and to your upgrades so compounds proposal 117 was created to update the price feed that compound V2 uses three audit firms checked the proposal and they gave the okay but there was actually an error in that proposal that caused transactions in the compound ether Market to fail and this couldn't be fixed until another proposal came through seven days later fortunately this one didn't come with giant dollar amounts but it further emphasizes that audits alone won't save you that might be an odd thing to hear coming from an audit company if we look at deployment Ronan was facing rapidly increasing user volume for its popular game axi Infinity which I noticed is just over here so to deal with that volume they granted access to a third party to help with the increasing validator load but then they didn't revoke that access later so even with a five of nine validation scheme an attacker was able to use social engineering to compromise five of those keys and then drain hundreds of millions of dollars and the point here is that an audit won't fix your private key security now during an update to their Solana program optify accidentally closed their program permanently the effect of that was 661 thousand dollars being completely locked up and completely inaccessible forever the optify team did have a lesson that they shared in their announcement of this they emphasized the importance of a rigorous deployment process and avoiding single points of failure now this States the issue pretty well because with many web3 projects and smart contracts if you have not considered security and embedded it throughout all the phases of your project there are actually many single points of failure now if we look at the defend phase I think everyone here has probably heard of Wormhole this was about a year ago they had made a critical secure security fix to their smart contracts in their GitHub repository but they had not made those changes on chain now it is guessed that the attacker took notice of those code changes in the commit in GitHub then took advantage of them before those changes did get pushed now we value open source code and transparency like everybody else here but this really looked a lot like laying out a treasure map for an attacker taking it one step further after that incident Wormhole then took this step they sent a message in a transaction offering what they called a white hat agreement and a bounty so basically you get 10 million dollars and we get the rest of our money back now multiple protocols have taken this approach adopting the term Bounty but it really looks a lot more like a ransom so there are actions you can take to defend your smart contracts before you get to this last-ditch effort of paying a thief millions of dollars one interesting note maybe you guys have already heard this the company that bailed out Wormhole jump crypto was actually just involved in a hackback from the attacker and it's really going to be interesting to see what precedent that sets going forward so after this uplifting crypto 2022 year in review I hope that we can all agree that audits alone are not going to save you audits are a critical part of the solution but they are not all of the solution and that is because web3 is a comprehensive problem or web 3 security is a comprehensive problem and that requires a comprehensive solution and that's what we're using the web 3 sdlc for security needs to be embedded in All Phases of your project and we want to show you what that looks like to go through the process so let's talk about Security in the design phase the vision for your project needs to be clearly laid out and that's typically in the form of a white paper that's going to talk about what your project will do what dependencies it's going to use and what unique features it's going to introduce into the ecosystem once you've recorded your ID in a white paper you can start the process of architecting the different components you're going to look at established design patterns well-audited contract libraries administrative controls and the intended user interactions for whatever dependencies you choose know that your project is going to inherit both the security and insecurity of those dependencies and if you don't fully understand a critical dependency now is a great time to learn about it or pick a simpler one next you're going to switch your minds out a little bit you need to consider how you intend your project to be used but then you also need to think like an attacker and that could include anything from stealing value to self-destructing contracts to gaming your governance mechanisms and many more things and this may result in you changing your design to remove some of the complexity that you have in it those first three steps might seem obvious if you spent any time in the web 3 space but here's one you may not have considered and that's partnering with a security company to help you through this design phase your partnership can be tailored to fit your needs your schedule and your budget and their involvement can be as much or as little as you want if you want to go the do-it-yourself route they can provide resources training materials and recommendation recommendations as you need them if working shoulder to shoulder is more your speed though your security partner can dedicate an expert to your team to help you with design discussions and help steer your decisions in Secure directions and in the most extreme case if you have Vision capital and no desire to do any design you can always Outsource that to a security partner they'll create the design to match your vision and they'll iterate on the details until you are completely satisfied in the developed phase you and your developers are going to convert your design to code the foundation of any software project depends upon source code management unfortunately there are many very mature battle tested tools and platforms that'll help you do this well you may also want to back up your work and provide clear guidance on how others can create suggestions and features in your code you are going to have to adopt coding standards and conventions that incorporate security best practices if you had to do this from scratch it would take you a long time but you can greatly reduce the effort necessary by selecting a mature development framework using plugins and extensions that enforce coding standards and following a clearly defined code review process and I emphasize follow having the process doesn't do any good if you don't follow it now as you develop your production code you should also be thoroughly testing your code that includes unit tests functional tests regression tests and following a clearly defined strategy for how and when those tests are going to be executed ideally your test Suite will be public allowing anyone to clone your code run the tests and get the same results that you got and hopefully also publish to a public dashboard that tested code will then be analyzed with static and dynamic analysis tools verification tools and finally several audit teams now your head might spin at the thought of configuring analysis tools and figuring out all of their settings but that's where our security partner can help you navigate that landscape of available tools and offer secure settings and configurations now in the deploy phase we're about to go live on a mainnet parts of this phase are going to stem from those decisions you made in the design phase such as how you deployed contracts are going to be managed governed and upgraded if those are features included in your contracts you're going to determine how your private keys are going to be secured and how you're going to tag document publish and manage your build artifacts so others can easily retrieve them and interact with your project you're also going to identify and protect Secrets other than your private Keys like API keys now one area where we think there should be more focus is deployment automation your initial and upgrade deployments should ideally involve as little manual interaction as possible a well-defined automated process lends itself to being reviewed verified tested and improved now this leads us to deployment verification you should have an automated process to check deployment details like whether your initializable contracts were initialized if your administrative roles were set correctly and these are all quick checks that you can do to ensure a complete and successful deployment now for all those steps you should be deploying to a testnet as a dress rehearsal and if things don't behave as you expect you can review and revise that process for no penalty until they do meet your expectations a trusted security partner can guide you through all of that I'm going to Short Circuit through this quickly the defend phase is is very underrated and you need to figure out how you can monitor both the normal activity and all of the threats that you identify in the design phase then you need to figure out an incident response plan so that you can actually respond if an incident occurs and then you also need to participate in bug Bounty programs and contests enlisting the aid of of white hats to help you find those bugs if they fall through the cracks I'll briefly touch on insurance technically it's called cover but it really looks like insurance now I'm two seconds over thank you for listening as I presented you with this high level summary there's far more detail in these references from these QR codes also we're back in Booth 561 which is straight back this way we'd love to talk to you and figure out how we can help you secure your projects in whatever phase you're in and thank you again for your time [Applause]