What your auditor REALLY thinks but is afraid to tell you...

Transcript

or we'll just grab them actually if the panelists could grab the chairs I'll introduce everyone that's how we can make an efficient use of our time sorry you have to work for this panel all right so uh everyone we're looking very much forward to sharing a lot about everything that we've worked on uh with seal as well as as individual audit firms um so my name is Michael Ellen I work as the head of solutions architecture at open Zeppelin where I do a lot of highle security work with our top clients uh joining me will be uh medy from Sigma Prime Sigma Prime is also a very well-known audit for and also maintainer of Lighthouse one of the major ethereum clients uh we have Alejandro who works at amuni one of the major bug Bounty platforms as well as an audit uh competition platform uh we have

Janis from ddab who also does Audits and has a very good uh security scanning tool and uh Joselyn who is from Trailer bits we only have okay that's right I'll Stand you guys sit hey I I got a Podium oh never mind Perfect all right justtin time chairs all right and last but not least Joselyn from Tayla bits another very well-known audit firm in the space as well as a long-standing traditional security firm working with us government telling them how uh blockchains might be taken down by nation states just in case they have to do that all right so uh we've got a load of questions have prepared but we're going to keep it pretty free flowing if we have time we'll take some uh questions from the audience um uh but just to set

it up the idea of this panel is even though we all are effectively paid to tell our clients one way or another how to write their code more securely uh at the end of the day it is a business relationship which means that we have to be careful about just how far we go sometimes in our feedback uh sometimes there are things that we are repeatingly seeing with clients or maybe multiple clients that we see as a problem we probably still provide that feedback but at the end of the day the client is free to choose how they implement the code and while we might still insist on our vision of things and the report um there are always limits potentially to that and how far we can go as well as the fact that a sensitive information it's something that you know if we do have a

problem with the the way a client implements something uh you know we we can't publish about that if it's something that is sensitive and confidential um and that's not to say that this is always like the limiting factor on that problem but it's just we know we we see growing Trends in clients we see particular issues just in the industry uh and this panel is kind of an idea uh an opportunity to sit down and talk about that um so I guess what I want to do is just kind of go down the row give everyone a chance to give their own maybe introduction but then also say like if there's one thing that you've seen out there uh that you you've seen in a lot of your audit clients that you wish would change or or something that you think has become a common Trend in

the industry in the last couple of years um what what's something you've seen and and why do you think that's something that we should be looking to address so I'll start with you josn okay hi everyone yeah so I work at 12 bits um if you don't know 12 bits we our security company where we specialize in high hand security technology uh we are working with blockchain client but also with traditional application security cryptography and so so on I think one of our kind of differentiation is that we spend a lot of time doing research and open source tool you might know a or Med user which are tool which we have been built over the past years now to to answer to your question what of you know one things uh I think people might kind of like not think about when when they when they think about security

audit or security rview is that security is not going to be solved by external provider like anyone of us is going to help your team is going to help your company get better at security but at the end of the day you own security like if you are building a protocol if you are building a project security is your responsibility if you think security external provider is going to own security for you you are not going to need to make it in the long term um yeah Medi co-founder director of Sigma Prime um blockchain security and research firm um security assessments throughout the entire stack for web three protocols and also proud found and maintainers of Lighthouse shout out to

the lighthouse team who's been doing a tremendous job over the years um powering about 33% of the ethereum network today um one thing that I see too often uh unfortunately is that's kind of echoing what you've been saying Joslyn is that people think that they should they're okay to launch straight after a review from us just because we've we've reviewed um a smart contract so there's two things here um I think the fact that a lot of protocols still rely solely on onchain security to protect their users is obviously um really dangerous right we've seen what happened um couple of weeks ago rent

Capital few months earlier with other uh centralized exchanges um in fact the vast majority of the hacks happening these days happen through Standard web2 Security um Mal practices so that's something I work hard to try to change with our clients you know getting them to realize that security goes Way Beyond onchain um and smart contracts exclusively uh we'll get in there I think we're making progress but it's a slow and long fight um and just echoing what uh Justin was saying um we're in fact completing a review right now for uh a protocol that is awaiting our

report to go live right um these engagements are all time boxed mind you the more time you give us the like the more likely we are to find bugs right um we've got a finite amount of time projects have a finite budget we can't you know keep searching for bugs um for years right we have to call it at some point if we keep finding critical vulnerabilities until the last day of the engagement chances are if you give us a bit more time we'll find more critical V abilities so what I've been noticing is projects just awaiting the final report to go live and that is terrible that is absolutely terrible just like Jus was saying it's your responsibility you're launching that

thing not us um so it's really important that you own the security aspect of your protocol get external security assessors of course but that's not um that's not it you have to really do your own due diligence and we'll talk about some of that stuff I'm sure in a bit uh hey I'm Alejandro Munos McDonald um unsafe call on Twitter and I'm from immuni uh so I'm a triager at imuni been with MiFi for um a little close to three years um so I see a lot of the um uh reports that are going through our platform to projects about these live vulnerabilities um that are being fixed before they're exploited um so on that question um kind of related to what medy

said about you know what mistakes we kind of um you know uh one of the mistakes is just inheriting ownable and using only owner for every single function for Access Control um so uh I mean jokes aside I do see a lot of projects um taking that level of centralization for granted um and while it typically isn't something that's accepted as like a bug or a mistake um in an audit competition um it's it's something that I feel like doesn't get the attention that it really should um so you know project projects obviously should be practicing that uh principle of leas privilege um and uh as as well as consider that threat modeling for uh the accounts that are given that access um so I mean projects has kind of

signaled pretty strongly at least on the audit competition side that they they don't really care too much about uh centralization risks um but um which I can somewhat agree with but we we then have to ask ourselves at at what stage do we consider that okay um I'm Janis Mar dakis I'm co-founder of ddob we security company uh we have a decompiler that you may have used uh for deployed evm contracts uh getting to the question of the panel here uh I think I have to very strongly agree with everything that has been said first of all the message that security is your responsibility when you're being audited that's the strongest message you

can have that's the most unpleasant truth about security we don't own security as Auditors you are the owners of security uh if you get a report from us if you get any bug report any any idea of a bug you're supposed to generalize from that you're supposed to ask yourselves why was this bug introduced why didn't we think about that ourselves what can we do to generalize the experience to other parts of the code and in the end everything is time boxed uh an external provider cannot can only do so much about your security and they're not the ones to suffer the most if you get hacked so ownership of security is absolutely the number one unpleasant truth the number

two unpleasant truth follows from the time boxing is not all audits have the same confidence although we want to always leave an audit with having high confidence about the code uh high confidence is still a variable uh the time boxing is much more important than the high EST confidence so the the better stage you can leave your code in your code and all the other artifacts including test cases documentation Etc the more opportunity you give your auditor to have extremely high confidence that those are kinds of the two obvious truths uh I just wanted to bring them up to begin with and we can

get into more entertaining anecdotes a little later I guess all right thank you all uh definitely 100% agree with everything that was said I hope a lot of people here who are in a similar industry uh agree as well I think just generally speaking making sure that we're not putting all the onus on the last security step uh especially when sometimes this is not every client but sometimes occasionally you have that client that is um asking for a review and you realize that you're actually the first person to reval that pull request other than the developer that wrote it uh and then you have to wonder maybe that there should be some additional steps in checks before then um so given that as well as a lot of other like things that should probably be done between the code being written and an auditor or an external Security review

happen like what are things that you've seen and this I'll just open up to anyone or we can go down if everyone has thoughts on this but uh like what's one thing you see where you're like you are not ready for an audit like you should go back and do a lot of other basic things before you pay me to look at your code and tell you all these things knowing that no matter how much time you give me at the end of it you're still not going to be ready to deploy I'm sure we all have heaps of uh yeah we'll start from that and come back uh so number one if is if there are obvious security vulnerabilities at the design level I mean you're not ready for an audit if someone can find a flaw in your business in your fundamental design

uh that shows that you haven't thought about things from a security standpoint uh even when you were designing the protocol you're not ready for a code AIT I don't care how great your coders are what can these flaws be things that suffer from obvious say replay attacks you create a protocol it's supposed to be doing something it's supposed to be sitting as an intermediary as a middleware somewhere and It suffers from obvious replay attacks you haven't even thought about that because the API the way you designed it is flawed in that way you have never thought of what you can do there that's that's an that's just an example but the most it's the most telling sign that you're not ready

yet for an audit that you haven't thought about security when you were putting together your design or even your business proposal when even you were going to investors uh sometimes you haven't thought about security and we've seen some instances of that uh so it's it's very that's a very hard message to give to a client right uh to go and tell them look this is not just broken it's fundamentally broken so before you go for an audit please try to think critically of your protocol from a design standpoint and by critically I mean try to think a little bit as an attacker so like the answer you might

get from the client is so you're saying I can't deploy next week so it's going to take another two weeks right I do I do have a slightly different perspective and I think you can go through an audit or a security overview whatever you want to call it from the moment you are ready to receive feedback you don't need wait for your code to be finalized you should actually seek for feedback early on because security provider might help you with a design they might help you you know at the early stage of your project depending on how long you're are going to develop your project if it's like three months probably you know you're going to wait at the end but if you're building something for a year it is probably worth to have check you know

over time and you know get getting feedback so I think from my perspective you should seek security overview from the moment you are willing to get feedback I if you give it for free AB everyone will follow your advice yeah I mean it can be a pain engagement like right we can do that you know at different stage but from the moment you're like okay the decision I'm going to take now are going to have an impact in the long term this is where like getting feedback is as long as the expectation is like okay you're not going to be ready to deploy immediately but but you know which stage you're at expectation is really important like you know if you're like you know half with your development maybe some function are not written maybe you don't have access to control maybe you haven't figured out

like you know how you're going to do like your year strategy whatever if you are okay to receive feedback from other compan and you have the right expectation of what you are waiting and what you are going to receive I think it's a good time to to to go through that process if I may I think the key word here is expectations yeah um just managing expectations on both ends um I get I get some of my testers um get frustrated sometimes um and also some of our clients um they they can seek early uh feedback U very early feedback and that's usually quite healthy for the protocol um but the problems arise and I think that's what you're probably referring to when um yeah the pressure comes from the business level of the

executive level we need to launch um this week or next week is a good example everyone is rushing to launch their uh latest upgrades or latest protocols before Devcon uh and there's a lot of pressure on those developers and deployers um to ship so it's all about managing expectations but um I I can certainly relate to what you were saying yanis uh it's quite painful sometimes um and to go back to your original question on um what I've seen that kind of made me smile and and and I just you know sort of shipped back sent the client back essentially um was this uh lending protocol shall remain unnamed um came to us for a security assessment um thousands and thousands of

lines of solidity code terrible code by by the way um and they barely had any tests barely had any unit tests so what we do at Sigma Prime I guess that somewhat differentiates us from the rest of the uh security provider space is uh that we Rite our own tests we don't trust our clients tests particularly when they're written in JavaScript um and uh yeah so we deployed the protocol locally and literally just tried to deposit stable coins and withdraw them and that didn't work that failed so going back to your to your question that that to me was just a massive red flag obviously you haven't done any testing let alone endtoend

testing um and it's a very tough conversation to have back to what you were saying earlier this is a commercial Arrangement right we're getting paid to spend time to review your protocol so we'd like to think that we're quite intellectually honest and you know instead of chewing through budget and wasting our CLI budget and wasting our time we just call it and we're like hey I'm just going to pause this we're not going to charge you for the remainder of the engagement fee you're going to go back do what you need to do and then you know Circle back whenever you think you're ready again but it's it's quite challenging because there's obviously you know scheduling issues that arise uh we're not a massive team so we've got you know a bit of a backlog to go

through but you know I'd rather do that than waste my client's money and my my testers time makes sense uh one more yeah yeah uh I was just going to mention yeah having those audits be part of the development process in pipeline rather than an afterthought or a final review before you go and get deployed like having that security um uh Consulting uh when you're developing the architecture of the application in the very beginning is super important especially for um also audit competitions when you're going into an audit competitions you're not typically going to have people um debating the the root of your design of the architecture of the application people are just finding bugs um right in

the in in your app in your defi app um so you could if you go audit competition or audit audit audit and you can end up with kind of a ship a thesis of code where Parts have all changed but the the design is the same and and that might be flawed yeah I think I'll I'll add one counter example that kind of sets expectations that's what I've this is actually the opposite problem this is like the code is too clean why do you want an audit where we uh have gotten people that came to us have anyone here used like opens up and contract wizard like just spits out an erc20 token comes from the library most people will just take the library on face value um we've had people come to us say like we've literally used the contract wizard the output is exactly the same we've changed

nothing but we want you to do an audit on this we're like well it's our code like and it's 100 lines of code and it's going to be kind of expensive because we usually don't do very small audits like this uh but they're like Yeah The Exchange needs an audit um which is ultimately what they sometimes certain part of the business is going forward the security value of like actually getting that feedback isn't what they're looking for they're looking for you know the stamp of someone said this is safe even though if someone spent five minutes looking at that and new basic City they'd be like oh this is just a normal token so that's the challenge on both sides um even though that's still a better example I'd rather have someone who doesn't need a not get one than the opposite but that that's usually challenge with scene one

quick plug I guess I'll say or or here's maybe the next thing I would say is um seal Frameworks has obviously been trying to do a lot to put a lot of best practices into in front of people um hopefully in front of people before they're going for an audit so a lot of the things that we might be getting paid in the last stage to tell them to fix when it is most expensive to fix they can be incorporating early on so I mean obviously we would plug seal Frameworks because most of us have been involved in that but what are other things that you wish clients were required what would be required reading for clients before they ever come to you for an audit or or just things that you would insist that they they absolutely should do before even you know other than the obvious things

like do testing do other things like maybe more specific things that you think isn't as common as it should be sorry do you want to perhaps mention or explain what Frameworks is because actually I think I think you should explain what framewor is you've been really in there okay so I invite you all to go to mata's talk at Devcon I'm sorry I forgot the actual date and time uh but just look it up on the Devcon website uh it'll be formally announced in a few days um this is a an initiative that's really really close to my heart um when it comes to security best practices in in web 3 there's a heap of different resources out there and it's quite difficult to know which ones are outdated which ones you know you should be following which ones actually apply

to you so we thought it would be a good idea to consolidate all of that and curate all of that information into one single um website at the moment um and that's called Frameworks if you go to frameworks. security alliance.org um it is live and it's basically in the form of an MD book markdown um and it's got a lot of content and you can filter the content that's applicable to you based on your role within the project that you're affiliated with um say if you are a community manager you will have sections around hardening your X account your Discord server your telegram channels um if you are a developer you can get detailed best practices in

solidity and other languages same if you're a devops person security devops deployments cicd hardening all that cool stuff which you know again we're not Reinventing the wheel uh all of that information is um pulled from reliable sources but it felt like we really needed this um I'm not sure about you guys but I have a lot of clients that ask us um hey what am I supposed to do here I'm deploying I've got ec2 instances on AWS um I'm deploying all these this infrastructure but I don't really know how to secure it now we can all point them to this one resource frameworks. security alliance.org really excited about this Mata and Frederick

have done a tremendous job in uh putting this off the ground yeah sorry I forgot your question so I guess in addition to that any other things that we should be uh getting people to do before their audit the specific things that might not be as obvious I guess the one thing I would say is um doing mainnet simulations as much as possible especially if there's going to be deployment involved especially if there's an ation or an upgrade or anything that they're already relying on existing as it should on on on an onchain context like integrating with the known protocol sometimes interfaces don't line up sometimes assumptions break sometimes it changed from a year ago when you were first writing the code um but yeah curious if anyone else has other things to throw into that um I think actor modeling is uh something that's I don't see enough

of um that I think is should really important so kind of like What actors are interacting with your protocol which ones are privileged the the level of privilege there as well um I don't think I've seen necessarily A framework for that just yet that everyone ISS using and I think that could definitely be something that would be really helpful yeah I think invariant development is probably something that we have seen a few team doing like using fing kind of writing down what is like the expected behavior of your protocol and trying to test it with different method we have seen a few team doing that and usually the team that are doing it are kind of better in term of security uh but overall like majority of the of the kind of team that are kind of

developing smart contract don't have this type of kind of technique and and and and framework within their development process and I'm hoping that you know with time we will get to a point where more people are writing in variant testing them with fuzing testing them even with manual review uh I think it will help a lot to understand what is supposed to happen with the protocol if you're infamiliar with invariant it's basically the idea is to Define what your protocol is supposed to do like for example if you have a a near C20 token you should not get to a point where someone balance off is above like the total Supply like if you have 1 million token and like a user has 2 million token probably something you know is going on so if you can Define like a list of 20 or even more inv of your

protocol and and see on how you can test them you are going to get you know better overall in term of security yeah very much strong vote of confidence for that I mean definitely do invariant testing as much as possible we have amazing tool Suites nowadays you can do a lot of very good testing Beyond basic unit testing you can set up your entire environment to be pretty much a faithful simulation and then if you do invariant testing uh you're already ahead of the curve that's that's wonderful still there there can be very mature code that has very deep bugs uh even though it has excellent test coverage just because there was a recent

change that was not not really uh didn't really agree too well with the initial design the initial design made some assumptions then you make a late change like initially you were only accepting eth now you're accepting other you're accepting ERC 20 tokens and suddenly all sorts of things break everywhere and your test Suite even though it has excellent coverage it has excellent coverage of in terms of code paths but it doesn't have excellent coverage in terms of the breadth of tokens that you can accept so the things there there are always caveats there's always a certain tension there in the end it's all again up to you but the shallow things that an

auditor will look at are things like do you have good test covered uh because that that is very much a strong indication of your code quality overall and let's let's be honest auditing is not about testing primarily right AI thing is about understanding the code in depth and forming a deep mental model uh so the Auditors focus on the code primarily but when they see something their that's that's not more normal their first question would be why is this not caught by test cases why isn't there a test case for that unless it's a very exotic scenario that obviously is a corner case would

never be uh touched by a normal test case U and that's that's really a bad sign if this could have been caught by regular functional testing of most of the code I think a good takeaway could be if you're a founder and you know you want to go to deployment you should aim for 100% test coverage if you cannot reach 100% because maybe there's some condition that cannot be reached you should have explanation and documentation don't go live if you don't have 100% test coverage that's a really basic simple rules but no one follow you're here yeah if I may uh there's two more things I'd like to add to that wish list um dependency

management I don't see that enough and I know for a fact one thing that keeps us up at night security researchers are supply chain attacks yeah um so and I having this conversation last year with some seal members and supply chain attacks seemed so far-fetched like Ah that's never going to happen to us and we've seen a lot of examples um since so just being aware of what your protocol relies on in terms of external components and monitoring um the I guess security posture of those components is is really really important and echoing uh something Alejandra said around um and what you mentioned as well yanis

around known limitations today you're are again picking on lending pools not not sure why but um if your protocol does does not support non ERC compliant tokens non erc20 compliant tokens to not name names usdt um and you know all of a sudden next year you've hired new developers you've let go of existing developers and all of a sudden these new devs have introduced support for the for usdt specifically um having documented somewhere that limitation will help you down the line um so I think these two things known

limitations dependency management is something that I'd like to see more often um and something I slightly disagree with janisan is um your take on Auditors aren't necessarily testers um as I said for us we found that writing our own tests whether you know integration tests n2n tests or fuzz tests has allowed us to uncover some really intricate edge cases in critical protocols that would have gone unnoticed had we only relied on our manual review capabilities um yeah that's just how we roll I really like that you mentioned the erc20 tokens that are supported

because um you know when we're looking at reporting and and and live vulnerabilities on chain uh we can only support security researchers when a project has signaled intention to integrate that token either through governance or or through documentation or something so that's that's really important if you intending to add rc20 token it really helps in uh incentivizing security researchers to disclose those issues yeah I'll actually add to that we've we've found cases where we have effectively reported critical vulnerabilities not because the code necessarily was insecure but the way they had documented the way they would deploy the code would have led to a critical vulnerability and we've had people like debate that and say well we wouldn't have actually done it like that we would have figured it out eventually no it's in the it was in

scope the documentation was in the code base you know it's it's in the scope list so um and we've also had cases where we've had clients that we've worked with for a very long time and they have had a lot of turnover and they're asking us like questions about their code base because the developers are so new and we've actually had more experience looking at that code than they have which is always a very stressful situation to be in because you're like wow yes we do know but like if you if we're the ones stopping you from potentially doing unsafe Behavior you know even separ the security review just like knowing what you're capable of that is a little terrifying um so I guess like with that like what are some what are some cases where if you've had clients um like asking you to

do things that are just so far out of scope for like what you think a security like firm should be doing like like like just like weirdest requests I'm kind of looking for some fun stories here but also maybe some things that like signify areas where the industry needs help uh like I mean one example that we've seen is just like unfortunately incident response for like social media takeovers um which I mean granted we we have tried to help out there and like shout out to seal 911 because they're the real heroes and helping in a lot of those scenarios which is we've just gotten to the point where we refer them to seal 911 because they're going to be the the fastest and most effective at helping um but yeah what are other cases where you've had a client where like okay you clearly have

a security need but we're not we can't help you you have to build this yourself or you have to go to someone else that is more suited for this um yeah I'm not sure I like a specific example in mind and one of the one of the thing here is that because we are to walk with traditional client like people working in web web two uh I do think we see more or less the same problem that we see in web two in web three U so like some of the things that our client are asking on the blockchain side are also some of the things we see you know in traditional application Security in cryptography or all type of things so I'm not sure there's really like one thing which is completely out of scope of what we can do usually um I

don't know if you have you never had a client ask can you just write the code for me yeah a very prominent L2 back in the days this was two or sorry three three and a half years ago we've done A Very Long Engagement this is a massive L2 with a lot of tvl today that engagement ran over the course of a couple of months we found countless numbers of criticals and high severity bugs to the extent where they had to throw away the code base and start from scratch I had a call with the co-founder and CTO and he straight up asked me whether my team could just build the thing obviously that's not what we do uh for reasons primarily Independence reasons um but I kind of echo what you're saying

we we're comfortable diving deep into the stack when it comes to security and we've had clients come to us for like you know web app security um it's not the most costeffective way of securing your front end to because the sigma Prime to do that but if if you want we can take a look at that stuff um same with securing your clout deployments there's plenty of of great uh TR security firms out there that can do a great job at that but I understand that some Founders want to leverage existing working relationships for that sort of stuff uh and we're some we're quite happy to oblige um whenever needed um but yeah what gets me is the hey can you just build it what why don't you just build it you broke it the first time so okay that's a good point like we do

have like no partnership for things like you know web application kind of type of we can do it up to some point but we are probably not the most cost effective to to do it uh but yeah even engineering like for example we have we have cryptographer that can build kind of an engineering protocol in term of cryptography for smart contract it's true we might you know we we have a couple of relationship with specific you know company that so yeah like usually if we going to do something we know someone that can do it you know in a good way all right yeah uh another question I had was going to be what are what are some interesting things you've seen like that clients think is secure but actually doesn't make a big difference or or maybe yeah what are like common

friends you've seen like where like okay clients seem to be implementing this feature it's adding a lot of overhead or it's doing a lot of things but it's not actually addressing the core security issue like so what what are some things that people think are secure but actually don't either make a big difference or really just aren't worth the effort it anything either there like what are overhype security like features implementations and it's not necessarily you say they're a waste of time but like there are other things you wish the client had implemented first for example uh multi with very low thr thresholds um that's something that you know projects automatically think oh I'm using a multisig I'm protected um but you know if you have a one of X multisig you're just increasing your attack surface there so you know understanding how to properly

Implement um a multi strategy understanding you know again threat modeling those actors that you're giving those keys to like who's who's uh who has access to those private keys where are they stored you know if you have an even if you have an eight8 of 11 multi s and seven of those keys are held by one person or like on the same aw AWS instance like you're just as insecure as we've seen that by the way this has happened this exact example has happened last year that's actually a core problem like there is no way to actually verify that keys are held independently um like it's almost like you'd have to do a signing ceremon where everyone's like in person and like in a hoodie if they want to be anonymous or something and still you you can see okay everyone keep their

hands away from the keyboard and then this guy sign and then this guy sign um I've seen people try to do signing ceremonies to protect for that EXA sort of thing and I've also seen what was the other thing I had with multi6 that came up um oh having a large multisig where the mass majority are not technical because in effect the majority of those non-technical people will just follow whatever the most technical person says which means that your threshold really doesn't actually hold in practice so let me be devil's advocate for a whole bunch of things that we've said here if it was up to an auditor or a security to say is this code secure sign here or should this code go live you know we would always say no right so it's not our business and for us our

business is safety not progress so we are not going to make money off of the protocol being launched so we want to be extremely conservative so everything we've said so far is extremely conservative and clearly there are best practices from the security standpoint that are not best practices from a business standpoint you cannot audit 17 different times until deployment because you it's it exceeds your budget uh same thing like Devil's Advocate objection to multisig a a one of n multisig yeah it doesn't make make you more secure it makes you less secure but it's better than no multisig because in five months I mean it's convenient for now and now what I want is convenience and in five

months I'm changing my policy and now it's five of seven and the five are completely distributed all over the globe to Independent Partners so it's not just one recipe and it's over you need to take ownership of security if you violate best practices you know why you're doing it you're doing it for convenience for now and you keep in mind that my policy will be that later I will upgrade so for anything that we say that it's good or bad there's there's always a Counterpoint that there are good reasons why people do these things in practice I think that's a good point are you consciously making a tradeoff or or are you yeah are or are you taking a risk without realizing there were better

options in the first place um so I think we're at a good point to maybe take a few questions uh from the audience see if there's anything that uh people want to ask panel uh anything that you want to know going up to maybe your first audit any questions really we that scary oh I see someone hi is an NDA a sufficient sort of um start point for engaging one of you external Auditors is that like a typical thing

that uh clients do is that sufficient is there more like you know as a Founder we're always kind of uh um OCD about like giving out our code to strangers yeah in IND like you know as long as you interact with entity that you know you have some trust with like should be sufficient I think um like as long as like you know like the jurisdiction of the company you are interacting with follow whatever you know you are trying to do uh that should be sufficient I think unless I'm missing something yeah I we're not lawyers uh so clearly your lawyer will advise you as

to whether the NDA is sufficient to protect you but it's a very common step if someone wants to keep their code private and I think what we do is something that most auditing firms do we have a pre-signed mutual NDA uh pre-signed on our end so you just sign on your end and immediately there's NDA on both sides typically the auditor is fairly trusted if you combine this with an NDA which gives you some legal guarantees the auditor is not going to go in competition with you they're not going to launch a financial protocol to compete with you if you have a a new idea so you're not the auditor is not who you should fear in terms of competition in terms of confidentiality

especially if you also have an MDA I I think my opinion would be it's perfectly sufficient if you're worried about confidenti out of your code Andrew oh are we have one more question hello hey oh over there okay uh so we were setting up the narrative that um alter is not liable for any loss or uh you know the project is solely owner of their security but do you think that if they have your recommendations and opt for all the security layers that you suggest um would you be able to take the responsibility that this project is secure enough to go live on production

and uh we can we can you know take it up from here that it's it's good enough to go live and you can take the responsibility of being you know being an auditor I understand that with security it's it's your reputation when you pass an audit it's gets staged but like is there a time uh when you can take the responsibility by saying that yes we have you know uh fully audited it and it can go live on production and second thing um uh you mentioned that uh you mentioned um you know U case where um they came and they don't have the test cases right and you send them back the lending protocol that you were talking about right um and also you

mentioned that um you have to you know um have a relation with the clients to uh um you know make them more clear that web3 security is not just on the onchain it's all on on the web two side so how would you you know you know do you take any Community initiatives to you know instead of you know shipping the client back do you take any initiative to uh tell them that these are the things that we are going to take care of for you like for securing the project um yeah uh the first one first question you had which was the like question of like will we like say like this is safe to the exact wording is going to kind of be

important I would say if a client took every security suggest that we gave them and implemented it to our satisfaction we would say this client has implemented every security recommendation we could give them and so in our opinion they have done as much as possible to be prepared for deployment in our opinion would we say it is safe and it is ready for deployment maybe kind of imply it but I I think I don't know I'm be curious to know what other people saying I AG answer that not my code not my call yeah it's up to you your code your protocol you go live you don't go live it's entirely up to you not my call to make second question um yeah I mean we we can't do that for them right we can point them we can explain to them the reasons why we're

sending them back the stuff that is missing the stuff that we should expect to see that is not there we can now Point them to the framework's website and be like hey you haven't followed these sections please go back to the drawing board and Implement these recommendations but for Independence reasons we're really big on Independence at Sigma Prime we will never ever come in and actually change your code base what we can do every now and then is raise pool requests in your repository to add tests and that is it we will never fix your code we will never add features we will never do anything that uh I think you're suggesting so it's your code your call as to whether you want to go live or not it's your code

your call as to whether you want to increase your security posture before you come back to us but that's just how we roll again maybe other people have different text we we've done testing advisory we've even implemented some tests for them as examples but at the end of the day they have to know how to like build them and run them and maintain them uh and own them if they're just like oh they ran because those guys gave us the test and they're running successfully so it must be safe well then that's not we we haven't done our job because then yeah there's a lack of ownership and then we're not going to always be there to make sure those tests are running properly and like security is not binary it's not it's secure it's not secure it's like kind of a a spectrum where you can you know get as

secure as as you know as you can and yeah I agree like your card or your responsibility it's it's the way it is all right I think we're at time um so thank you to all the panelists for coming up thank you for all the work you're doing both uh as uh commercial businesses but also as contributors to initiatives like seal coming to these conferences and sharing your thoughts um and yeah uh look forward to the uh next panels that we'll have talking more about what SEALs up to thank you everyone