 Hello everyone, I think that's actually the biggest crowd of people that I've seen being interested about security So thanks My name is Oliver. I'm the co-founder and CEO of patch tech a little bit about my background I've been working in WordPress since 2014 when I was running a web development company Which was focused on WordPress actually about web application security in general But we very much so focused on WordPress from the early days already I'm also an active community builder. So in Estonia where I live I've also co-founded a co-working space which has turned into a startup center In our town and I've also been organizing hacking events, which called capture the flag competitions where hackers are Challenging each other and competing Against each other. So we've been doing it for NATO and different kind of organizations Today I'll mostly use your time To give you a little bit of an overview of what we've seen over the past couple of years in the work for security space I will dive into a little bit into numbers But I'm also going to talk a little bit about what are the biggest challenges that we've seen that need to be Hopefully solved or improved I will then then share what are the Expectations for this year something that we've already seen this year, but what we should expect In this year and beyond and then dive into like what we as a community could do to make WordPress ecosystem even more secure than it is today So let's start with the very good news I think WordPress ecosystem is more secured than it has ever been before if we look at the data from the past years in 2020 there was 541 security vulnerabilities Disclosed in the entire WordPress ecosystem that includes plugins themes WordPress core Everything is included in 2021 this number jumped to 1382 and last year in 2022 this number skyrocketed into 4528 security vulnerabilities What's important to mention here is the fact that these vulnerabilities are not like they just popped up this year On on those years and like they've never been existing there before This is kind of like you can expect it like a backlog of security vulnerabilities that are getting fixed from all these previous years Because they've have actually existed there for many many years So now we're finally like cleaning up the backlog of security issues within the plugins and teams and in the WordPress Ecosystem in general. So that's a really good thing because now You know the bad actors the the hackers who would otherwise exploit these issues have you know much less Issues to find because the plugin developers have already fixed them and teams as well Out of those 500 security bugs that were disclosed in 2022 99.7% were actually found in plugins and teams Most of them like most of these issues as you can see are from the plugins and teams and only 26 of those in total We're actually from the WordPress core and the good thing about this is that those issues that were fixed in the WordPress core itself We never seen any of them actually be actively exploited What it means is that the WordPress as a platform itself is very mature. It has a very mature You know release cycle it has a very good attention on security and The issues that are found in the core are mostly so low severity that they are not really useful for anyone to even exploit That's not the true unfortunately with the plugins and teams If we look into 2022 in terms of the data that we saw in all the vulnerabilities that were reported within this year Actually, we saw a little bit of a shift in the vulnerabilities that were Disclosed and there is a reason for it, which is actually on the next slide But before I get to it, I will give you a little bit of insight into what those vulnerabilities look like So cross-site request forgery, which is on top of them one on top of the list is something that you actually Tricked a let's say admin user into clicking your link that they're extended into the page where they are like Tricked into let's say clicking an option or changing some option on your website Then there is cross-site scripting vulnerabilities where a you know malicious code can be injected into the website So the visitor loads it and you will basically see the website then loading something that shouldn't be there This is one of the most common vulnerabilities that is being exploited And then we have actually one that is very important to mention is the broken access control where the plugins don't Necessarily maybe use the WordPress hooks in the correct way I think many of you have heard about the ease admin function, which a lot of people are actually confusing in terms of what it does But one of the issues with the broken access control is that the you the plugins may be having unauthenticated unauthenticated access to a function that should only be available for authenticated users and in that case You know attackers can either you know turn on registration Make the make the registered users admins by default and you know all that kind of crazy stuff The reason why the cross-site request for jury, which is actually the lowest ranking fruit You can find in the WordPress ecosystem was on the top one position is actually they the issue in the software supply chain or the security of the Software supply chain how you can think about that is like websites like all our websites use some level of plugins And you know if a plug-in has a vulnerability that releases a patch for example You will go there and get it patched and you update the plug-in right now what if the plugins themselves also use plugins and you know then what it means is that the plug-in that the The plug-in that or the framework or library that was used within the plug-in is getting a security issue fixed then all the plug-ins that actually use this framework also need to go and update and Then eventually if they do then the then the end user needs to go and update You know plug-in on the website and like with each additional layer We are actually adding delay for the end users to get protected And that's a really big challenge in the space right now and the last year the number actually spiked because there was two big frameworks that were actually Used within thousands of plugins and they shared then eventually the common security vulnerabilities It's actually also very hard to secure to report security issues to plugins To give you a little bit of context behind this chart that you're seeing on the screen What we do at patch deck is running a program called patch deck alliance It's a community of ethical hackers who report security vulnerabilities in any of the plugins in the ecosystem And they are getting rewarded for that They're getting rewarded because they are using ethical processes to make sure that the plug-in developers have all the necessary information to fix a security vulnerability before it's being found by someone else with much worse Motivations let's say so 1160 security vulnerabilities unique security vulnerabilities were reported last year into the patch deck alliance program out of those one 1160 there was 748 that were accepted by us which we Validated made sure that they are correct issues that there was enough information about that So that the plug-in developer could fix it and then you know big portion of them got patched Even though it takes a lot of effort to actually reach out to the plug-in developers because very often you can't find any Information on their website you can't find information on their forms Even if they do have a form then very often you just get like a error message saying that whoops that form is not Working so you have you basically have like a black hole where you're putting your Your security reports and you never get the reply on the other hand You have those security security researchers and that the hell hackers who are waiting for you know hearing back When are those vulnerabilities getting resolved so here who is actually helping us out a lot? And I think we should give a big applause to the WordPress.org plug-in review team Because they are being done like amazing job in terms of how much they have actually dealt with those issues So really come on guys. It's yeah So the plug-in review team is helping us when we need to escalate security issues to them to make sure that End users will eventually get the information that they need to patch to update the plugins that are vulnerable and from those 748 issues 148 Cases were actually escalated to the plug-in steam and what they've done is then they try to reach out to those plug-ins again As well and if they can't do so then they are going to close the plug-in Now what is a scary part here is that over 10% of those you know cases? They actually remain closed which means that the plugins are still to this date actually closed down If you go to the wordpress.org repo you can see that the plug-in is closed for security reasons or if you know in some level of that in that kind of message Now if 10% of these vulnerabilities that are getting escalated How many plugins actually are there that are abandoned that the developer doesn't respond to and how many of How many websites there are that are running those plugins that are not maintained by anyone anymore and You know are basically vulnerable, but without having it without the website owner having any information about that so This is a big issue actually so way too many security box are not getting patched Actually last year 26% of critical security box were not receiving a timely patch at all That means that these critical security issues are the usually the ones that are unauthenticated The attackers can you know run mass exploitation campaigns to take over a website inject malware And do pretty much whatever they want right so 20 point 26 percent is a big number So even if you have like auto updates enabled You know you're not really you know protected in any way because you just don't get an update So even though those plugins get removed from WordPress or they still stay on websites and even worse So close plugins have no indicator of active security issues on the WordPress admin panel That's a big issue because if you look at the WordPress or Repository you actually see that the plugin is closed for security issues But now who is actually you know who should know about this issue the most is the site owners the ones that are Actually running the WordPress website where they see the list of plugins that they have installed But to this date WordPress core itself doesn't have an Indicator within the admin panel that would tell you that hey you're running this you know plug-in on your website But this isn't this is closed by the WordPress or rep repository and it's not you know actively maintained anymore That brings me to something that Just happened very recently. I was speaking at cloudfest last year Sorry earlier this year and I was talking about this issue as well. So we actually found an old eight-year-old ticket in the WordPress you know Basically a feature request to add an alert into the WordPress admin panel to show the user that the plug-in is removed From the WordPress, you know repository for the security reasons. So there's a keyword code link to that Entry so if anyone wants to kind of share their ideas or kind of like add additional information to that Please do so because I think this is a very big thing that we should look into and have maybe a bit more of a deeper Conversation around to make the WordPress ecosystem much more secure So let's look into what else we could do as a whole community to make WordPress more secure I think we need to accept that it's okay for projects to come to an end I think it's okay when we build plugins and we build projects in general and we eventually Come to a conclusion that maybe it's not maybe it wasn't used by anyone that much that you were expecting Or maybe it didn't go as well as you expected as well But if you built a plug-in then you need to kind of keep in mind that other people might still be using it So I think it's very important to communicate very transparently and let the users know Whenever you are planning to maybe you know drop the project or like move on to additional things What you could also do for example is you know reach out to the community talk to people on post status For example ask maybe someone wants to take this plug-in over maybe someone else wants to maintain it in the future And I think another thing that we might want to think about is Maybe it's okay to send an end-of-life date until the users receive security patches Let them know that hey, I'm planning to move to other things So here's a date until I'm actually you know getting the security patches if there's anything You know needing to get patched, but I'm not adding additional secure additional features to the plug-in So I'm not you know then the users will get some level of kind of time when they can find alternatives and figure out how to move forward and Please don't reject security reports because you're moved on on the top corner You are actually seeing an interaction by our security team with the plug-in developer I think it happened last month where we reported the security issue to them was a serious issue Which actually needed the patch quite quickly and the only response we got from there is that sorry We no longer maintain this plug-in this plug-in currently has over hundred thousand active installations So again, this is a problem And we don't know how many of these situations actually are there even more in the ecosystem And I think we need as a whole community to talk about that a little bit more to make the entire ecosystem more secure Another thing that what we and it kind of like applies to the previous talk where we to the previous slide where we reach out to Developer and saying hey, there's a security issue You know we could help you fix it is then please don't you know Avoid security research as all What we've seen over the past years is that in many cases where security reporter or security researchers report the Vulnerability to plug-in they are kind of like, you know reacted with negativity You know why you are like looking into our stuff and you know who asked you to check our plug-in and you know that kind of stuff So one thing that we should I think look into is Considering security researchers as equal contributors as our developers When you when a developer is submitting nice code into your plug-in into your open source project You're actually happy right so why shouldn't you be super happy and thankful to security researchers? Who point out in your code base to a places where you can improve and also provide a better product to your customers? So plug-ins actually thanks to the security researchers in this space plug-ins and fixed vulnerabilities before bad actors can exploit Those zero days so from the past years we see this, you know increasing number of security vulnerabilities being You know fixed and reported these are all the vulnerabilities less for the bad guys Right, so it's good. So it's good for everyone. It's good for the community. It's good for the you know open source project maintainers and Really think of researchers as the good hackers on your side I think we like if anyone gives you a view like an Option like do you want the hackers to be on your side or do you want the hackers to be on? You know on the other side which one would you pick? I think it's a pretty simple You know option to choose and I think we need to think about that in the sense of Incentivizing their security researcher and the good hackers to be on our side and not on the other side So I've talked a lot about like you know plug-ins ecosystem and teams ecosystem and the projects in general But like I imagine in this room There's also people who just maybe build websites or have their own website built. So what should you do? You know in the light of all this information I think it's more and more important to choose that you're you know stack wisely and keep plug-ins to minimum It's a very common, you know security recommendation, but it's very important and I think it's still not praised enough I think it's very much easier to choose a stack or you know a selection of tools that you like to use like Select your favorite page builder select your favorite, you know forms plug-in select your favorite You know tools that you in general build the websites with and if you're a developer building websites to a lot of different customers Try to stick to that stack because when a security vulnerability is being found Then you actually have much smaller Attack surface like if you use like hundreds or 200 different plug-ins across all your websites You would probably need to deal with security vulnerabilities every single day. That's a fact So another thing to look into is the WordPress specific firewall Something that is actually being able to detect whether there are vulnerabilities on your website and to actually provide you a very Targeted protection for those vulnerabilities something that is called nowadays as a virtual patching Which means that the vulnerability is being found on your website and it received a security rule exactly for that vulnerability I think it's very important because what you what you receive then is to actually keep in mind that Mentioned just 26% of the security or like the critical issues from 2022 were not patched So what virtual patching actually gives you is the time to stay protected until the developer releases a patch Or it gives you a little bit more time to go there and update your website So it's definitely an essential thing looking into the light of you know How much of those security vulnerabilities are out there? and you know how big is the chance that you might end up with one as well and Really choose a good hosting service that lets you know about vulnerabilities as well because there's a lot of hosting companies who actually do that So we have you know managed hosting providers who have like a panel where you see all you know plugins that you have installed and everything a Lot of the hosting providers nowadays actually also include the information whether any of those plug-ins Reclude the you know security vulnerability So ask this from your hosting company or choose a hosting company that already does Security out of the box and helps you to at least be aware of those security issues So what to expect from 2023 so a lot more ethical hackers will get interested in WordPress That's for a fact because WordPress has a huge impact and there's so many different plugins and themes and you know So many different projects to look for security issues So nowadays we have also like you know bug bounty programs and different programs Which incentivize the ethical hackers to report security vulnerabilities more ethically and you know Obviously if we have more ethical hackers, you know get interested in WordPress We will see a lot more vulnerabilities to be reported and patched as well not only because of you know if we have more ethical hackers on board and we get more vulnerabilities reported and patched but also Plugging developers themselves and you know team developers and project owners. They actually put much more effort into security as well last year We saw a optic actually of Projects getting security audits setting up security programs for their plugins and and so forth I won't even start mentioning AI here because everyone is doing that So but you know you can kind of also think about that line of things because we do have a lot of tools available That would help you know ethical hackers to also find vulnerabilities more easily in the plugins and All that taking into consideration what we need to again keep in mind is that if 10% from the last year There was 10% of the plugins that remain closed after its security reports being reported to them We're probably going to see that number increase as well as a final note here. I actually want to also mention something that is Upcoming over the upcoming years is that governments start to regulate open source security and supply chain security as well So if public sector and enterprises need to stay compliant, they need to understand what kind of open source, you know Tools they rely on you know what kind of open source projects They actually even use what kind of you know plugins they are running on their you know infrastructure What is the security status of those then developers and agencies who provide services to them Need to also to kind of you know provide that kind of overview insight and security services So this is something that you know the developers and agencies in the space already need to think about is that a lot of those You know larger enterprises and public sector customers will start asking Hey, why did you you why did you choose touch stack when you know starting to build our application? And what does that you know what kind of risk might come with that if we rely on that kind of open source software? And this also brings higher security expectations toward programming developers because if Developers and agencies need to start choosing to stack more wisely and making sure that they have like a good overview of like how How well it's maintained? What are the previous security issues? How well they are how fast are they are actually fixing security issues if they're reported? How well is it communicated and so forth then what we are going to see is that you know Plugging developers will have higher expectations as well and to be honest I think plug-in developers have the most to win from here I think what they can do is set up you know security programs Maybe even incentivize the ethical hackers to report vulnerabilities to them to make sure that they are more actively looking for Vulnerabilities in their software set up a bounty program I think this is all in benefit for the plug-in developers right now because the developers who will use your product They will trust you more So I think the key takeaways here really is that right now the WordPress ecosystem is more secure than ever I'm looking forward to say the exact same thing next year and then year again and then year again I think plug-in developers have a lot to win here and as a community I think plug-in developers have also the most to do in terms of making the WordPress space more secure and Yeah, if you want to see the data from which I actually used on the talk from the last year and a little bit even more data Then the QR code actually sends you there And thank you all for making the work for space so much secure and thank you And thank you Oliver for sharing While we so just you know we have the standing mics there if you have questions we have time for questions While we are waiting people to queue there I have a question for like what we as the plug-in developers, you know can actually do to make those We're talking about the security like how to make but what we can actually do to make those plugins while developing it more secure Yes, definitely one of the things that can be done well is to kind of follow the code of conduct for example or like the you know The documentation of how to use the maybe hooks in a correct way Definitely sanitized inputs, you know, wherever you can to do so And I think one of the things that can be done Well that will improve not only the security of the plug-in, but also how the you know the users of your plug-in will see Kind of your professionalities to have like some third-party security audits done once in a while Maybe once a year or so or maybe after like every like a larger release There is service providers in the space different ones that are actually providing code reviews code review services So this is a something that you know should probably be done more often Especially if you have a lot of active installations and the other thing is like if you don't have you know If you're open source project is not generating revenue then obviously, you know You can't have like a large sum of money to pay for those security research services Then what you can still do is set up a security program like a managed vulnerability disclosure program Where you just tell the ethical hackers that hey if you have security issues to report report them here and make sure, you know That this these issues are then going to be, you know Handled in ethical way basically so these are like one or like two very good ways of how to do that So I think in general if we kind of like put them into context and it's all about communication, right? So communicate well to your users how the security of your plug-in is covered What you are doing as a plug-in developer to make that code much more secure? And also like if something is found in something is patched How well you are communicating is much more important than the fact that there was something found in the first place Well, thank you. We have a question from the audience. Yeah Hey Oliver. Great talk. Thank you. Thanks. So has there been any discussion with the plug-in review team about maybe not Immediately closing plug-ins when they have a significant active installed base But maybe taking it on and patching it and treating it more like a core security issue and perhaps force pushing an update and then closing it Yeah, I think it always happens based on a situation So it's not always the way how like it's not always that they are closing it down right away I think what they are also doing is trying to reach out to the plug-in developer Receiving some level of answer, you know whether and when they are going to do that So it's not the case that you know, they were just like close it down immediately in most of the cases But obviously like if there's no reaction whatsoever then you know closing the plug-in probably will get the reaction Which will eventually get to you know fixing the plug-in or fixing the fixing the issue that is affecting users But I think there's still a lot of work to do right because we are still you know We're this growth that we are seeing in terms of the vulnerabilities being fixed from the past two or three years I mean, we are still in a very much of a baby shoes like we are still I think there's so much more security issues to still iron out And I think as we are moving forward in this process and if the volume grows I think we also need to have even more, you know Worked-out processes in terms of dealing with those security issues So that yeah, there's definitely work to be done there Nice and then the second question Hi, I recently started experimenting with WordPress blocks and downloaded a lot of blocks plugins And they tend to lean into the JavaScript ecosystem a lot of more And what I noticed is that some of these plugins have like a note modules directory with 30 to 50 dependencies Aren't we opening up ourselves to even more dependencies by adopting these JavaScript types of working? Absolutely the answer is correct. Yeah, I mean it is happening because and that's why I mentioned the supply chain thing Right, it's going to piggyback on top of the other things So and the layer and the rabbit hole goes deeper with you know, each level of each layer So like even if we see already plugins using also a lot of JavaScript libraries like even WordPress Core itself used like jQuery, right? And there was an issue in jQuery So like these things actually go deeper and deeper and and I think yeah JavaScript as we introduce more and more JavaScript Into the WordPress core. I think the problem also, you know, is going to get deeper and I mean there's just more work to be done Nice, we'll take the question from that side Hi, yeah, you talked about the way the metrics are climbing So we went from 541 in 2020 1382 year before last 4528 99% of those are from plugins, but there's 60,000 or more plugins in the plugin repository Like that still seems like there's a very small Number compared to the amount of code out there and then there's obviously plugins beyond the plugin repository Yeah, am I right to still be alarmed that there's a lot of Surface area in the plugins to still be examined or are you seeing a slowdown in Historical vulnerabilities and now it's newly introduced vulnerabilities. Can you reassure me or should I remain alert? I think you should definitely stay alert because what we are still see like we don't see any slowdown We're definitely seeing increase even right now in this year And I think there's your you know, absolutely right There's 60,000 plugins in the ecosystem and you know right now the vulnerabilities that are getting reported to us and to the other vendors in the Ecosystem these are done by you know, ethical hackers who actually look for those issues But they you know select in most cases plugins with higher, you know installation numbers Or they are looking for you know easier kind of security vulnerabilities that you can scan the entire Repo for and look for like for example cross-site request forgery and stuff like that So I think there's a lot more of those, you know Serious security issues still hidden in those lower install count plugins And I think that's why I was also saying that we are still in a baby shoes Like all these numbers are still like the tip of the iceberg in a way, right? And another thing to mention here is that we have almost no visibility into the premium plugins The ones that are not hosted in the wordpress.org and these are most often much less Checked for security issues in general. So this is another kind of you know, think that we need to look into in the future as well Thank you Nice. Thank you. Your question, please Okay, great is from the other side of Gulf of Finland. Go Estonia boy. Yeah, boy boy Are you aware of a Solution or even initiative to set up a kind of a harness That's like a dev sec ops harness for plug-in developers that would contain like basic sanity things like Vulnerability scanning static analysis Things that are pretty standard on most of the other run times or if not standards At least there's a toolkit that you can just take into use for supply chain management NPM or didn't things like that. So are you aware of something that would help plug-in developers? And if not, should there be something like that? I mean Thanks, you're asking our own product does kind of something like that. But yeah, this was a paid advertisement Thanks for the question. I mean, yes, we actually do something like that as well So we do vulnerability management and virtual patching So we identify those vulnerabilities in your application and provide you like, you know an understanding When should you patch something, you know, what needs to be patched first before something else? What are the criticality levels, you know, how fast should you react? But also provide you that kind of like a protection before, you know You go there and maybe update or maybe there's no update available. So it covers your kind of back until you can do So and I'm sure there's other services as well, but I'm obviously not gonna mention that. Okay, actually just kidding Thank you Leslie Thank you for your presentation and for the ethical hacking you all are doing I find that example of the plug-in developer who has a hundred thousand installs and receive this notice from your team quite distressing Because I also suspect they have other plugins out there in the environment So I wonder what other things can we be doing to put more pressure on that kind of plug-in developer, including naming and shaming Putting pressure on their other plugins. Like what what are the ethical things that you can do in your role? But that we as a community can do as well. I think instead of naming and shaming We should just kind of focus on highlighting those who are doing better, right? So if we are talking about like for example, we we have something called like a VDP directory So we have a directory of all the plugins in the WordPress ecosystem who have kind of like opened up Like a security program where they kind of very well say like hey, here's how you should report security vulnerabilities to us Here's how fast we are dealing with those issues It's all about communication and in terms of this specific example as well I think what is needed is to have like some some level of like a common understanding of how these issues should be coming communicated I don't I never kind of believe in like naming and shaming because I feel that this is Making people eventually hide from a lot of facts not to get named and shamed, right? And I think naming and shaming is also kind of like the problem here Why they are even like in many cases reacting negatively if they are receiving a security report because they don't want That attention on their you know project that oh my god, we had the security vulnerability, right? So I think what we can do is kind of just collectively talk about security issues more in a positive matter We should talk more about like that's great. Like we got another security issue fixed in the ecosystem There's you know again like hundreds of thousands more websites more secure thanks to that and we should praise the thick Praise the plug-in developers for fixing issues transparently and openly I think that's kind of the only way to go One more question this side. Hello. Thank you. Great talk. So I have a question lately I've seen this a lot in some especially premium plugins that the under the pressure of the marketing teams these Outdoors they just hide or even bury These vulnerabilities that are reported in the changeloks they have so it's pretty difficult to find what actually happened and to learn from this So how do you you find these practices and also is this only like a WordPress thing or you find this also in on another Ecosystems I find it more prevalent in the WordPress ecosystem Not that much in the other ones where maybe the development practices are a little bit more mature and you know We're a little bit more enterprise the customers are using the frameworks But the good point that actually you brought out is that a lot of developers in or like not many But in still like we see a lot of cases where yeah The information is like hidden from changelok or it's like hidden under like something like minor fix or something super vague right There's no point of doing that to be honest because what hackers do and what other security companies also do is that they monitor the SVN We also monitor the SVN on a daily basis. So we see actually the code change diffs We see if you have escaped something we see if you sanitize something new on the plugin We see if you've added nonsense. We actually see this information and so do hackers. So even if you find even if you hide it from the users Actually, the only ones who are going to benefit are the bad hackers So there's really no point of doing that. That's why I'm not gonna said like the communication is the key And instead of kind of like trying to hide it from it or like try to kind of like, you know Stay away from the maybe bad publicity of you know, there was a security phone issue found I would say that the plugins that actually fix security issues in my mind are much more secure than the dose that haven't fixed any Oh at all because I have no idea if someone has even checked, you know, these plugins at all So so yeah chain hiding information in the changelok should not be done really And I think yeah, the only people you are going to eventually hide information from Are those who need it the most? Thank you. Thanks. Nice. Nice. Just stating the obvious this side is killing it guys No, just you know, they're killing it. So if you have more questions, there's a mic there. Thank you your question Hi, great talk. So basically I was just wondering although it's Like against the community or something like that But still there if there can be a possibility that someone Like WordPress can have a place where like before uploading a plug-in we they can actually access that like there Is there a certain level of security, you know being maintained over there like that can be a good option that Will actually check like what? like it should not be you know very That kind of plug-in which is easily hacked or something like that. So can it be a good thing? like if a community come together or either WordPress itself come together and Dwell up something like that actually WordPress the Lord plug-in review team does that they do it on the first Submission of the plug-in if you upload a new plug-in to the to the system Then they are to the repo then they are actually checking the plug-in for those security issues They use I'm not actually a hundred percent sure now But they use one of those like a sas or like a static code analyzing tools to actually check for unknown issues So the check if there's like, you know, maybe potential sequel injection vulnerabilities and stuff like that But the thing is that after that like after plug-in start to receive or like release updates These checks are not done anymore. So, you know A lot of plugins that are actually applied into the repository are not at all anything similar to what they are today, right? so I Think there is yeah, I think we need more tools that help plug-in developers in general And I think we need different kinds of ones We need the ones that are for you know helping to come in out with the communication But we also need to have like sas tools for example that they can run their plug-in code through before they push a next update For example, so you're completely right. Yeah, we definitely need that kind of tools more Thank you. Thanks. Nice and this side is waking up. So we have the question there had the slide with the main vulnerabilities like CSRF XSS SQL injections and like most of it is handled with Sanitizing escaping and using nonsense. Is there like any other major category of vulnerability that we should look out for is I feel like it's too easy or Is there anything more to hacking because I don't know how those sites are attacked? I think a lot of That like just like more complex ones that need more attention are definitely the ones with Involved broken authentication or like misuse of like WordPress existing hooks Obviously we have a solution that you could just you know read the codex right and you know use the use the hooks in the right way, but Unfortunately, not everyone does so Another thing to look out for is when code is actually reused because what we've also seen is that you know Some developers just build you know in WordPress We build plugins in PHP and you know you can find a lot of PHP in you know stack overflow, right? But that doesn't necessarily mean that the code on stack overflow is also secure So we can see a lot of vulnerabilities being introduced in these kind of ways as well into the plugins But I think the more complex ones that I think need more attention are the logic issues are surrounding authentication and like how the Kind of like WordPress core and the APIs are being kind of interacted with I think these are the ones to kind of like look more closely Yeah, well and this concludes probably the longest Q&A Session that I ever attended just you know so many questions. That's cool. Good. That's good. Do we have any more questions? I have one just you know, just like the prepared. So you mentioned cloud fast So cloud fast or work in Europe, which audience do you prefer and big round of applause?