# A Playbook of Secure Smart Contract Development by Palina Tolmach | Devcon SEA

- Speakers: Palina Tolmach
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 10:41
- Watch: https://streameth.org/watch/yt-88hS4MsUwR4
- YouTube: https://www.youtube.com/watch?v=88hS4MsUwR4

## Description

One-off audits can provide a good security baseline but fall short in continuous security assurance, especially for upgradeable and actively developed protocols. We'll cover how to set up the smart contract development processes to ensure the top level of security guarantees, including design review and property specification stages, as well as the integration of security tooling, including testing, fuzzing, and formal verification, into the CI pipeline and development lifecycle of a protocol.

Speaker(s): Palina Tolmach
Skill level: Beginner
Track: Security
Keywords: DevEx, Security, Best Practices, ci/cd

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] hi everyone uh I'm Pina from runtime verification and today I'm going to present our comprehensive approach to security that we have R RV because I believe that it's it can significantly improve the security stance of projects and even make it more sustainable for them um I'd like to represent this project as a pyramid where lower layers uh enable or at least make easier to get the higher lay layers right and currently the standard is to implement the code and just hand it over to some external auditor or a contest for a one-off audit or code review and while it is a pretty good Baseline it also doesn't do much in terms of continuous security assurance and that is very important especially for protocols under active development um if the team has resources or feels like it uh some projects also have some documentation outlining what the code um is actually supposed to do or even use some tooling um to do unit testing or fuzzing and while the completeness of those is very much hindered by the constraints in um devel the development process um having more complete documentation and some tests actually makes helps make sure uh that the audit is actually going to go well because it adds an additional Dimension to it since the auditor can not only check for some common vulnerabilities but also uh for the adherence of the code to the business law project uh that they're supposed to implement um and having tests obviously is good too uh a more comprehensive approach however uh add some more layers and maybe counterintuitively we actually think that it makes the security model more sustainable and uh one of the steps that is often overlooked is the design review that's where some person an auditor looks through the design understands what the project is actually supposed to do and um how does the architecture looks like and sees if it actually makes sense because if the design doesn't um then none of that matters actually because the protocol can still be compromised and the good byproduct of that is that it also allows you to write Better Properties and specification outlining what the Cod is should or should not do and once formalized in the forms of tests or proofs we that actually enables uh the application of more advanced tooling we can have more complete fuzzing test SS we can do formal verification for even better security guarantees and the best part of that is that we can also run them on CI and I generally believe that having automated security processes um is good eding more automation is better because it makes it harder to just skip through certain steps it ensures that the the security protocol is actually followed consistently and also CI in that sense works as sort of an automated audit that is going to be run on every PR or every commit uh and um well that's less expensive than having a human looks through it over and over again so as an example of something um that as an example of how it is important to follow through this whole process I have this well example that mayor may not be based on a recent hack and that happened to the protocol that uh helped users convert their BDC into an equivalent amount of R BDC that we'll call Defcon BTC and it was running on BTC chains so it was supposed to work with Native tokens but it was also running on other networks which had ethereum as a native token and there was a change that actually made it possible for users to Mint uh an equivalent amount of Defcon BDC for eer and iser is like 20 times cheaper so the hacker actually just made it a lot of free money basically and the thing is there was a property that just hasn't been informed or maybe hasn't been formulated that the user should also not be able to convert non BTC tokens into U well the rupt version of BTC and this property could actually have been enforced with something as simple as a unit test or this fuzzing test that you can see on the slide um that just checks that if um the protocol is running on ethereum Main net then whenever someone tries to Mint tokens using eer um this transaction fails uh so that is a Foundry test uh has it been running on CI it maybe could have caught um the issue as soon as this code was pushed but before the deployment uh so to summarize the points I want to make here is that security is complicated I think everyone knows it there are a lot of steps in this process it's very important to get all of them right um automation is very useful because it helps Ure sure uh that the process the security process is followed um consistently and is enforced and in addition CI also provides a very efficient and a very cost effective um way to ensure that new updates don't break anything uh one last thing that has been missing so far is this base layer which I haven't really touched in detail that is uh obsc because unfortunately there have been a lot of private key compromises um in the past year and if the private key is compromised then unfortunately even have very secure smart contract code uh can also be exploited and and there are a lot of resources about how to get it right on the internet so I encourage all of you um to look through it and yeah thank you very much thanks [Applause] Pina any questions for pina I guess my one question would be around maybe fatigue in terms of continuing to be diligent about making sure that the basics are in place and I'm curious for you what has helped to maintain those habits over time thank you yeah we try to follow these processes religiously uh at RV automation helps a lot because uh you don't have to you know go over the same things uh over and over again instead you write some properties that you specify some properties and then you formalize them in the forms of tests or proofs with a lot of formal verification so that's that's what we try to set up and then as whenever code changes that actually handles it for us uh for a LGE to a large degree um I think it actually the having the process makes it easier cool next uh yeah question on like uh blockchain security the way you have Smart contract which is immutable versus let's say on web 2 where you can update your code if you discover security problem after the fact so how does that factor in Oh you mean upgradability uh not necessarily but like let's say you don't have upgradeability then how would you modify your security practices such that that doesn't uh like so that you mitigate that I guess right got it thank you um well I guess that's why you try to get it right the first time before deployment that's why we advocate for a very comprehensive security analysis that you perform before deployment uh to make sure that you go through all the stages that the team you know writes proper documentation helps us formulate the properties and invariance that should hold that they can that can later be monitored um we advocate for like formal verification to ensure that there are like the bus security guarantees I guess there are some there is a field that that deals with like some posst Haack things or recoveries um but I guess that's um that's that's a different story we just we just suggest that people should get it right and I think you know I think I think we're getting better cool is there something like the oosp Zed attack proxy equivalent in smart contracts or blockchain Frameworks that you'd recommend s can you please repeat once again the O the open web application standards project The Zed attack proxy that they have we used to use it in our CI Tooling in like web 2 sort of development to test for the top 10 oasp uh security vulnerabilities right yeah I haven't been aware of that but it's it sounds pretty useful I'm all up for using any tool in that helps and having it on CI I guess anything would help static analyzers are great uh as the first step especially um having unit tests is also extremely helpful and very efficient um fing can uncover a lot of vulnerabilities so uh yeah thanks for letting me know about that okay one more question thanks um you mentioned like a design review as a precursor to the actual code review is your like hope or expectation from an audit point of view that a team comes to you with the design before they even write the code or were you just talking about that as a separate a specific phase of the audit that is perfect but that almost never happens so the sooner we introduce security and you know some testing any of that uh into the process of development the easier it becomes for everyone uh that's something that we have found out ourselves uh but it almost never happens so we at least try to allocate some time for design review first before we dive into the code itself to make sure that we also understand what it's supposed to do um but I mean having the team providing us the design first is ideal and we can also like help us help out with the stages uh but it's pretty rare because of the resource constraints I guess great thanks okay we can take one more question if there is any oh there's one there thank you uh I would like to know if uh if there are some security best practices for smart contract based on artificial intelligence thank you based on artificial intelligence right yes right um I am aware of a few tools that do it um I think you can also Ask Jud to generate you some security practices uh and it will be pretty helpful when it comes to like common vulnerabilities I guess the current common problem with all this AA based tooling is that it it is good at pattern matching right so it can definitely help you find some common issues that are known for a long time but it probably has bigger issues with like business logic or design review Parts um so I guess it's it's pretty helpful at least when it comes to the the first part thank you okay that's everything thank you Pina let's give it up to Pina [Applause]