 Welcome. For the last session of this Tuesday, we're going to talk about security or a bit in a harder term, that there is actually a mini Drupal Gadan every week and how do we survive it? Who of you knows who does not know what Drupal Gadan or Drupal Gadan stands for? Everybody, okay. Who of you on that day was actively updating his sites and hoping? Yes. Okay. Good. So this is what today is about. Drupal Gadan was, at least for me, myself a wake-up call that Drupal security and security in general in the web is not something we can just take as easy. It is something that happens every week and we will hear later on from Manuel more about what it is and how it works. But it's definitely something that all of us have to realize. We recently heard that if you don't update your Drupal site, you might be going to change the world. Like we had with this huge leak of data in a lot of different places, which maybe are related to an un-updated Drupal site. It's not exactly clear, but yes. So who are we? I'm Michael and sorry for the screen. Here it's perfect, but it's just a little bit and we're going to tell you anyway. So I'm the CEO of the Macy Group. Macy Group is a group of three different type of companies. I'm EZIO, I'm EZ Labs, and I'm EZ Metrics. We do all different things among hosting, building websites and SEO and conversion. As we build a lot of Drupal sites and as we host as well, we're very interested in security and that we have very secure Drupal sites. The other person with me is Manuel. Yeah, my name is Manuel. I'm founder and CEO of the Drupal Shop Right Solutions, and we develop DropGuard, which is a service to help Drupal shops prevent struggling with the next Drupal get-on-to-automate Drupal updates. Who of you knows how the release cycle of a Drupal security patch in Drupal Org happens? Okay, only you. So Drupal has an international dedicated Drupal security team that crawls the code and reviews patches and checks if there are security issues. So that's a very good thing, and that is one thing that only a few open-source projects have. And we can be proud that Drupal has it. But on the other side, you are responsible to apply the patches or apply the updates in time. So whenever there is a security patch available, it will be submitted to the Drupal security team. And then there is a big alert, oh, a new Drupal security patch. And the security team reviews this patch and then announced the patch publicly. That usually happens on Wednesday. So if you monitor Drupal security updates, you should keep an eye on the list on Wednesdays. That means after the security patch is publicly announced, hackers also know about it. That means hackers can dig into the code. They can check which security vulnerabilities are available. And they can write automatic scripts. They can write bots that attack websites automatically. And that's the big problem, because usually they are faster. They are smarter with automation than we as a Drupal shop are. Yeah. So whenever there is a new security update, it depends on the criticality. There is a factor from 1 up to 20. It depends on the level with a 20 or no, it's 25 even. It's the highest one. Drupal get on had the security rating 25. And that means run and patch all your sites, leave your projects behind you, and care about your site security, because hackers usually are faster and they will run for your site as well. Yeah. So these are the scores. You see them on the patch. If there is a 0 to 4, that means the patch or the update is not critical. You have time to update the site. Nevertheless, you should apply the update within, let's say, one month. If you miss too many updates, and there is a highly critical update, and you want to apply the update, then you ship a lot of new code, which means you need to test your site even deeper, because there might be some bugs that you can only prevent when you test very carefully. If you do the updates continuously, whenever there is a new update, no matter which criticality it has, then the risk is much smaller that your site breaks with an update. So then we have from 5 to 9 the less critical updates. So they are security related, but they are not critical. The same for moderately critical and critical. We treat them in the same way. And the highly criticals, those other Drupal get on ones where you really need to apply the update in Drupal get on, it was around seven hours. After seven hours, the bots already started with attacking sites automatically. And that is called the zero day release. Zero day release means there is an update, and you don't have any time to update your site. You should do this immediately. Otherwise, you need to assume that your site has been hacked. And that answers also the question why it is very, very, very important to update the site. It is important for you and your clients, but also for the Drupal ecosystem. Because what happens when a site gets hacked, everybody tells, oh, my site is hacked. Drupal is not secure. I will move to another open source project, or I will move to a propriety project. But it's not related to Drupal. It's related to how people handle updates and how the awareness of security is in the Drupal ecosystem. In Drupal 8, it becomes even worse, because we will see a slide that Drupal is in the version 8, not only built from backend modules, but also in the front end. There are many libraries that are combined together to provide a good user experience. But these libraries also need to be updated. Yeah, it looks like this. In Drupal 4 and Drupal 5, we had Drupal Core. We had some Drupal modules, and that's it. In Drupal 7, there was the library module introduced. That means Drupal projects are built on top of other libraries, external libraries, that are hosted not inside the Drupal ecosystem and maintained, but outside the Drupal ecosystem. And we also need to take care about their security releases. And in Drupal 8, it becomes even worse when the Drupal project is based on Symfony. And Symfony has many libraries that also have a release cycle with security updates. And there are other like NPM or Node.js libraries, front end libraries, and libraries over libraries. And you need to take care and don't lose the time when you need to update or when an update is released for any of these libraries. And I think web applications in the future will be developed only using libraries or microservices more and more. There is not one big software, you update continuously, but there are many, many small libraries and modules that you need to take care and update continuously to keep the security of your site. How can you stay informed where to get the information regarding security updates, at least for Drupal modules? Of course, Drupal.org. Then there is a newsletter and the mailing list from the Drupal security team. There is an RSS feed that informs you about new security releases. And of course, social media, Twitter, LinkedIn, and all the social media channels. But that's only for Drupal, not for the other libraries. If you want to take care of security updates, for example, in Symfony or in front end libraries, you need to subscribe to separate lists and monitor all these lists or social media channels. And the manual process. So the first and most easiest process is to ignore security updates. Because they are time-consuming and you need to take your stuff from projects to apply updates. And does somebody of you handle updates like this? Okay, I would not, yes? Oh, you are honest. No, no, no. No, no. I'm not willing to. It happens, it happens, yeah. Because you are always too deep in projects, your developers don't have time. And to be honest, they hate doing updates. Every developer hates doing updates. Yeah, so if you do the TrashUpDB, that's the easiest thing. You apply the update just on your local machine. Then you do reapply patches if there are some patches. If you don't know there are patches applied, you will lose them all and your site might break. You will see that in the manual quality assurance. Then you have somehow maybe a ticket system like JIRA or RedMind, where you create a task for an update, document everything, maybe assign the task to your customer, let him do the quality assurance, communicate everything to your stakeholders, then deploy the site and so on and so forth. Every Wednesday whenever there is a new update for each and every site. And that's very time consuming and costs lots of money. And that feels like this, okay? Because you sit around and wait until TrashUpDB is done until you get the feedback from your client. Yeah, and that's how the process should look like. So either you have a dedicated support team member or dedicated support team, or you have support chumpers that are triple developers that usually work in projects, but they switch from time to time to the support team to have a rotating system. Otherwise it's too boring to only apply updates every day. Especially if you are a good triple developer and experience and want to share your knowledge in your projects. So if there's a new update, you create a new ticket in your ticket system, you reapply the patches if you remember them, then you commit everything to your repository and deploy it to a test instance. There you can run automated tests or manual quality assurance by yourself or by your customer. The communication takes some time of course and after that you want to deploy the site to the live server and communication and testing again. Now remember you maintain 100 sites and you need to patch every site in seven hours. How will you do that? And that's something we can learn from hackers because they are usually smarter and faster when it comes to hacking sites with security vulnerabilities. And Michelle will show you now how you can automate this process to be secure continuously. Okay, thank you. Yes, so we want to automate every single piece of it. Basically what we want to do, we want to do nothing. We want to just continuously working and whenever there is an update it should happen fully automatically. So let's first figure out what do we really need? So first of all we need a monitoring tool. We need a tool that checks which modules are installed because not every Drupal site that you have, let's say we have 100 sites, not every will have the same versions. It would be cool that all of them have the exact same news version but sometimes maybe QA didn't happen yet, testing the deployment didn't happen yet. So you need a tool that first and foremost knows about all your Drupal sites. Then you need to know which modules are even available. We just heard there is like Drupal.org, there's newsletters but to match these, you need to know which module do I have installed and for which of the modules, which security level now is the critical one. So you also need a matching tool that tells you that. And then we need a tool that does patching and there's so many different ways on how to apply a patch in Drupal or in code in general. You can have regular patching but you maybe have an existing patch on your Drupal core or any country module so you need to make sure that the security patch with that function patch works together. You may be using already composer to download modules with composer or you use Git sub-modules so the system that does the patching needs to apply sub-modules as well. Then maybe patches fail so we need a ticketing system to inform if a failure happens because then a human needs to look at it and an automated tool is not being able to really fix merge conflicts or patch apply failure so you need a way that if something fails to inform the team. And then as we all use in Git you wanna push that into Git but you might wanna have different branches for different security levels. So we need a system that is capable of handling Git and understanding and Git committing and pushing and merging. And then we wanna test so we might have a continuous integration system that automatically tests every commit. So we need to make sure that that first runs through and then deploys, then we need fully automated deploys. So again, we don't wanna do anything so we just wanna wait and it happens. And then at the end of all that process we wanna have a reporting tool that basically tells us is it done, which sites are not done, which modules have been updated, maybe integration into client information or all these things. So it's not an easy task to handle all of that. Luckily there's us both and we fixed that already. So what we're gonna show you today is what we did, how the tools that the two companies developed help supporting that and how you can set it up. So this is how it looks like. And the session is over now. Okay, so that's the solution but we're gonna go in step by step and we explain you exactly why did we do each step, how the tools work together. So first of all, what we have is the DropGuard monitoring. So what you do on your production site over here, you install the DropGuard module and you connect that DropGuard module to the DropGuard site. And with that, DropGuard, which is connected to all your production sites, knows first of all which modules are installed and second in which versions they are installed. And then DropGuard will query Drupal.org and figure out if there is an update for one year of existing modules and which security level there is. So the whole monitoring tool happens all at one site. You can log in there and you see all your connected sites. And you see which status there are, is there a critical update for one and we'll also see later on even more information. So and it does that for it doesn't matter if you have even like death versions or patched versions or all that. So they are all figuring that out and understanding the different ways of how to installing a module. So let's continue here and let's talk about first about the really highly critical one. So a one like Drupal get on where we say, okay, we wanna just push that as fast as possible to the production branch and to the production site. I rather have a maybe functionality broken production site than a security hole in my production site because fixing a hacked site, especially in Drupal can take days because you basically have to go through each database table and figure out, is there, should that node be there? Should that user be there? Because you don't know exactly what the hacker is gonna do. So cleaning up an existing site is much harder than fixing a functionality that is maybe broken by a highly critical security patch. So what Drupal, Drupal Dropguard does, if there is a new module version available, it checks them against the security levels. And within Dropguard, you can define what should happen based on which level. So the levels we foresaw, you will find again in the tool and you can define different ways of how it should go. Then Dropguard will automatically apply the security patch on your core or country modules. So it doesn't matter if it's core or country, they both have the same security release cycle. And it commits them. This is how it is configured. So we configured it in a way that if the security level is above 20, please commit that directly into the Git. So Dropguard also has access to our Git. It knows how to connect it, it has access to push into it, it understands Git, it understands branches. And it can do that for plain code, Git sub-modules, or Composer. So however, which tool you use right now, even if you're gonna continue upgrading in the future to say everything to Composer, Dropguard will support it, it will realize, oh, that is a Git sub-module that has a plain code and it will also realize existing patches. So it will do all the handling for you. And the last thing, it also reports into Chira in our case now, or they're also connectors to other ticketing systems to inform either about the success or about an error. Because it could be that applying here of the patching and the committing does not work. Maybe you forgot to give access to the Git branch so Dropguard can commit. Or anything else is wrong. So you have an information in Chira. So that is the whole Dropguard side. And on the other side of amazing IO, what we have, we have full automatic deployment on new pushes into branches. So what happens is Dropguard pushes into the Git branch. On the other side, the hosting system also monitors that Git branch realizes there is a completely new commit. I will deploy that and it will also run automatic deployment tasks. Like maybe your patch requires a database change. So that means you need to run DrushUpDB. Or you need to clear caches or anything else that maybe your site needs. At the major IO, every time you deploy, these tasks are executed fully automatically. You don't have to do anything. And with that system, we are basically safe from anything above 20. So whenever the evil Drupal security team decides to release another Drupal get-on, well, it's not them. But if there is a new patch and it comes in, it will fully automatically deploy everything to the production side. And yes, there is no testing step in that. But again, as I mentioned, it's only for the really highly critical security ones. You can still test later on and you should. But the ones that are above 20 are usually the really bad ones. Like there is an SQL injection directory and you don't wanna have your site vulnerable to SQL injections because we saw, just search for Drupal get-on, how many people spent hours and days in trying to fix their sites. And sometimes just reapplying a backup from a week ago and losing everything that happened in the last week because they only do backups every week, for example. Okay, let's continue, though. Not every security release is a crazy one, like we are talking about right now. Most of them are either moderately critical, critical. So they're still security and you should still apply them, but they're not that super urgent that you really have to run and do it immediately. So what we do there, we see here, we can do a switch among inside drop guard and we can say, okay, based on the security levels, we wanna have a different process. You can go as crazy as you want. You can have one for non-critical, one for the less critical, one for the moderately critical. In that case, we just do an easy one. Everything below 20, we just do another process. So what we do, we say, non-highly critical patches, everything below 20, we apply to another branch. And in that case, we apply it to the testing branch. How you call that, depending on your hosting environment, how they're called, they're maybe different. At the METIO, you can call them as whatever you want. If you call them testing, if you call them drop guard or whatever, it doesn't matter. And so what happens is if drop guard is pushing into the Git branch, into the testing branch, METIO knows about the site for that and will also automatically deploy into the testing side. But not only that, what you can do, you can tell METIO to automatically sync the production side, like the database and the files. Because what you wanna do, you wanna do on the testing side, you wanna test the new code with the database from the production. It doesn't help if you, if here, if you test that with a three week old database dump. So you want, every time a new code comes, you wanna take the newest database from production and make sure that that actually runs. So you can do, we'll see that later, even fully automated testing. So what METIO, if you kinda configure it that way, you can say, okay, I wanna sync the database and the files from the production to the testing side in order for me to fully test and make sure that the new code really works. The clients can test and you can test. And in terms of processes, what you can tell, drop guard has an understanding of in testing. So it knows that some patches needs to be tested first and that's an understanding of these statuses. And it connects that into, in our case, cheeroad or others. And so you can create a ticket and say, it's okay, now please, does the testing. How you do that, if you do it fully automatically, if you assign it to the client, if you have a support person, if you have somebody of the development, it's your choice, but you should test on that. And then if testing is all good, what you do, you merge that Git branch into the production branch and the code again will automatically be pushed to the production side, automate the test will be run and your site is secure for your security. So that involves still involves some manual stuff. I mentioned before, we wanna do it fully automatically. So let's look into that. If you wanna do automated testing, you need another tool that actually can do that. There are hundreds out there. You can choose to do unit testing. If you wanna write unit tests, there is a visual regression testing which compares two sites visually, sometimes just pixel based, sometimes even DOM based, so they understand CSS changes and stuff like that. What you can do with our hosting stuff, as for us, a lot of things are based on Docker. You can actually start, let's say on Travis or on Jenkins or on CircleCI. These are just like the continuous integration tools that we all know. You can actually start the Docker container with Amazio running inside and you can take again the database from production and run fully automated tests. So you can make sure that let's say the code that you're gonna be pushing is not gonna change anything on the visual appearance of your site and that's what you want. You wanna make sure that if I now apply that patch of panels and I maybe see there there's a template change, I wanna make sure that this does not change my website because it should not. During regular feature updates, obviously that changes will happen but in security stuff, it's super easy to test because nothing should change. So visual regression testing tools, for example, are very good. But of course, unit testing inside Docker containers help as well to make sure that your workflows, let's say there's a change to workbench moderation and you wanna make sure that your workflows you configured with your clients together are still the same way behaving. So you can test all of that fully automatically and then these tools together with Amazio have the possibility to say that test passed and if that happens, now automatically merge. So you can fully automate that every time there's a security update, you can fully automate it. Disclaimer here that's not easy and you need to still write the tests. Our tools are not gonna write the test for you. They're just gonna support you in if you have tests written already to use them again and again but it's a good argument for like clients if they ask, okay, should we write automated tests? That is a very good reason because that thing happens every week. And so if you have a hundred sites every week, if it takes you one hour for every site, you need two people or even more to just do that. Like they're gonna be now doing nothing else than just testing stuff. And if you look right now, if you subscribe to security updates every week there is something new. And as Manuel mentioned before, we are adding so many new libraries. So suddenly we have updates from Symphony and other stuff and Gossel and Twig. They also have security updates. So it's just gonna be more. So you really wanna think that you have a tool first that monitors and the hosting environment that supports doing it full automatic. Okay, now we looked at a lot of graphs and arrows. Now we wanna actually see it in real time. So let's see it. So first of all, what I'm gonna show you is the highly critical. We learned before, we're gonna deploy that directly to production. In our case, this is the master branch. So what happens? We have a Drupal site. Somehow it appeared to be 8.1.1. It's a couple of weeks ago. There is at least one highly critical security update among because we are at 8.1.10 right now. So, and we're connecting that to DropGuard. And what DropGuard is gonna tell us here is that there is an upgrade from 1.1 to 1.10. It came out on the 21st of September and it is highly critical. We see there's another module, the DropGuard module itself. There is no update there. You're safe with that module. But Drupal core is vulnerable and we need to upgrade as fast as possible. DropGuard is doing that fully automatically. You don't have to do. Okay, can you hear me again? Perfect, okay. So what DropGuard is gonna do, we're gonna create a task, an update task. And we can see that here. So we are in the task tab and we see here that is gonna put Drupal core from 8.1.1 to 8.1.10. Again, we see it's a highly critical. So it's gonna do that. After some minutes, in that case, we see here it actually took two minutes to do them. The updates were applied and it pushed the changes into the master branch. In that case, I configured DropGuard to skip testing because we pushed it anyway to production. But you can configure it that way. Should do you still wanna go back to DropGuard and click test or not? Or you can also do that automatically. But in that case, I just did that. So we are now DropGuard pushed to master and we can see now in our master branch, we can see how there is a git commit by DropGuard. So DropGuard has write access to our git repository and it will tell us what it did. So it tells update the DropGuard from 8.1.1 to 8.1.10. And that is on top of all the other ones and what is now the hosting environment gonna do, it realizes, hey, there's a push, there's a new commit, I'm gonna deploy that. So a Misi.io is gonna start deploying that. And a couple of seconds later, we can see we have a Slack integration. So deployment statuses are flowing into Slack. And we can see here that the Misi.io bot committed or probably deployed on the master branch. It took him a minute and 34 seconds. And we can see here what exactly has been deployed. And we can see that the Drupal update 8.1.1 to 1.10 by DropGuard and this is the git hash in case we need that. And if we go back to the Drupal site, we have an updated fully up to date Drupal without needing to do anything at all. All you need to do is you maybe get a Chira ticket or you maybe see a Slack message and you have to be happy. Because your Drupal site is gonna be, and that happens fully automatically for 100 sites or 200 sites. And we have that running for amazing labs for around 80 sites right now. And so on Wednesday evening, when it comes out, you do not believe how good it feels to not do anything. Because at DropGuard, at DrupalGuard, we called people ahead because the Drupal security team was so nice to announce that there is something very big coming. So we had at least people on deck to do it. But we updated 70 sites by hand. And now, if the whole thing happens again, you don't do anything. You see just messages in Slack flowing in. All the sites are updated. Maybe one or two doesn't work because maybe somebody had the patch in there or whatever. But yes. Okay, let's look at it with a critical update. And in our case, the testing branch that we wanna do is called DropGuard. And what we also wanna do, we wanna synchronize the site automatically. Because last time we deployed to the DropGuard, it was maybe three weeks ago. And the code is very old. And also the database is very old. So we wanna synchronize, automatically the stuff from our master site so we can really look at two sites at the same time. Same process again. Now we start with Drupal 819. That was actually the case a couple of weeks ago when the 8110 came out, which Drupal will tell you, hey, there is an update. It will not help you actually updating it, but it will at least tell you, that's nice. So again, the same, we go to DropGuard. DropGuard tells us, hey, 819, there you should update to 8110. And now this time, it is critical. It is not a highly critical. So the other process will start. And the other process looks initially the same way. There is a task. The task will start two, three minutes later. The task will be applied and it tells us get branch to test changes are in DropGuard. So we did not push to master yet. It's just in DropGuard. And now what's gonna happen is the deployment system of OmazeIO is not deploying master. It looks at the DropGuard site and it is a DropGuard branch. And it will realize, hey, there's a change there. It shows you the URL, in our case, the development sites, which DropGuard one of them is. So we see here the branch in there is a bit of critical, a long one, but that's okay. So we can also test it there. And again, we see updated Drupal from 819 to 8110 by DropGuard, love of love. So far, the same thing as we had in master just is another branch. What comes now, though, is a bit of specialty. So within OmazeIO, you can define deploy tasks. And deploy tasks can be different per branch. So what I can do here, I can say, if you deploy into the DropGuard branch, I wanna define special tasks. And the really cool one is here. So every time that the deployment system of OmazeIO deploys to the DropGuard branch, it will, first of all, throw away the database that is currently there. And then, fully automatically sync the database from master to that branch where you are right now. So the synchronization, you don't have to worry about. It does it fully automatically. And then we run all the other stuff. We run upDB and we go on cache clear. That's a regular, but the really cool stuff is that on the deployment, you can fully automatically synchronize two sites. And be sure that the database is up to date. If we look at the deployment log, we can see here that the deployment system tells us executing before deploy task, thrush as called drop. Because we have a dash y in there and it tells thrush to not ask us. I mean, it still asks us, but it will do it automatically. It's not an interactive system, it's fully automatically. So you just wanna tell thrush, okay, just please drop my database. That happens here. And then the second one we see as called sync at master default, which means synchronize the master database to my local. And that will happen here fully automatically. And we have the newest database from master on DropGuard on that side. And now we can really look at the two sites. We can run visual regression testing, we can run unit testing, whatever you want, you can give it to your client. To test, you can test it yourself. And we can see here on the DropGuard site, we have eight, one, 10. We can test it, and when we're happy, we can merge the DropGuard branch into the master branch. The same thing as before will happen, we deploy to production. So it's still a bit of things involved, but again, these are not the highly critical ones. And we can also do that for all feature branch updates. Because there are a lot of updates among the Drupal community or all the contrib modules that are not related to security. But you still wanna keep up to date because if you wait too long, the security patches will not apply anymore. So we wanna update them on a continuous base and such a system allows us to not worry too much and even fully automatically test. That's it. If you wanna know more about either DropGuard, how that tool works, or AMAZIO, how the whole deployment system works, and what you can do, we both have booths here at the sponsor hall, come and talk to us. We're happy to show you how it works. We have demos, we have test sites, we have horrible broken websites that need to be updated immediately. And you can do that yourself. And yeah, and if you have any more questions, we're happy to answer them. Yes, you may be wondering if you have a question. Yeah, the question was if DropGuard considers all the updates between 8.1 and 8.10 or only compares 8.1 and 8.10. So you mean between Drupal 7 and 8? That, sure, DropGuard will detect it. I mean, DropGuard will not detect if the security issue is in a feature of your site that you don't use. That will be not detected, but it detects if your site is affected by the security release or not. Yeah, and the problem is, I mean, it's not a big problem, but the Drupal, the patches, they're only released to the newest version. So it theoretically could be that the security release that came out was for a feature that got into the module three weeks ago. But you're using the module of a year ago, so theoretically you are not affected. But nobody is gonna check you for that. The Drupal security just tells the newest version has a security patch, here is it. DropGuard will tell you that there is an update available and there is a security release. Yes, but nobody will tell you if you are affected or not. The only way to figure that out is look at the patch, see what exactly it does, understand what it does, go to your old module, looking at it and realizing if you're affected or not. So correct, because the security team just says they actually release now, there's these shields on the Drupal.org, that's exactly that reason. So it's only the newest version, but it's very dangerous to assuming, well that version is now for 8.22 and I'm running 8.17, so I'm not affected. You will most probably be affected. Of all the critical ones we have, they're going far, far, far back. Yeah, the question was if those two tools can work separately or only hand in hand. And if there is a cost, then how much is it, yeah. So the tools work independent from each other. You can use either DropGuard with your OWN servers and integrate it with your OWN task and ticketing system. You can use AMAZIO without DropGuard just for hosting purpose. For DropGuard, there is no cost for private sites and non-commercial sites, but there is a price for commercial sites or if you want to resell it as a support SLA's to your customers, for example. And then there is a price per site starting from nine Euro up to 59 depending on how many modules you have enabled and you want DropGuard to take care of. If you take both together, we give you a discount. And a beer. Yes. That's a good point. I left that a bit out. So the question is, even though we do the production stuff, shouldn't we still deploy to the testing in order to do the testing workflow? Yes, correct. So you can configure DropGuard, for example, to work as your developer would apply the update. That means whenever you commit an update to the master branch, you can merge the branch back to the stage branch, back to the dev branch so that the updated code base is available everywhere. And then you can run your automated tests on the stage branch, inform your developers to fix something on the live site. Yes, it is a good way, a good idea to definitely deploy also highly critical stills or in that site, test it, have Tira tickets or whatever ticketing system you use and at least make sure that the site still works. Because, yeah, it could theoretically be that you deploy something, you go to the start page and say, hey, it's still low, it's good, next slide. And then you realize thumbs up pages are completely broke. And yeah, that's a good point, thank you. Not yet, but in a month about, it will also check the coder module which you have included in your code base, but it's not enabled on your live site, yeah. Yes. Yeah, that was something very new a couple of weeks ago and we had the first time that the module is actually vulnerable just with being there. There was a huge debate at the end if it was correctly marked in the security level, because the problem is the Drupal security team only knows the amount of actual installed modules. And coder is a module that is most probably not a lot of installed, but maybe exists a lot. So that was one thing that we actually, as Amazio said, even though it's not highly critical, we fixed it from an infrastructure point of view. So we said the access to that file is not allowed at all. But that depends on your hoster if they are doing like mitigation actions from an infrastructure point of view. And yeah, and I think a lot of people were like surprised, oh wow, now we even have stuff, because it used to be just like, yeah, only the installed modules. And for example, the Drupal itself can only check installed modules as of right now. So there are issues also to check, like not installed modules and... For at least, I never know. Yeah, so just repeat the question. The question was if there are any free tools that I can recommend to monitor modules and to automate the updates? Yeah, yeah, no. Yeah, sure, sure. So yes, Nagios is a good option. There are also some other services. I think Drupal status is a module that helps you to monitor security updates for all your modules, for all your sites. To automate your updates, you can write your own scripts. You can use Trush, but it's very difficult to do the patch detection and to rewrite composer files automatically. So yeah, we do the development since one year we started, two years, we also started with our own scripts and we see there is lots of details you always need to respect. But the only thing is to write it by yourself. And you can configure Drupal that it sends you an email every time it realizes that there's an update. So if you have the update module installed and the email server works and your email address is in there, you will get an email at least from your Drupal site. So there's like another cheap way of doing it. We actually, at Amazio, you can configure custom crown scripts. We had somebody just running Drush up every night. I mean, it's... I mean, it can go very bad. Yeah, I said you can also run automatic backups, so you maybe want to do that before. But I mean, it's the super, super cheap and that's you should not do way because usually if something goes wrong, you don't really know what happened. So then you're gonna spend probably a lot of time in debugging and then fixing stuff. So it's a promise. What versions of Drupal are supported, seven and eight? You can also run Drupal 6 on Amazio, but there is no... No Drupal support. Yes. And Drupal 6 is a bit in the special state that the official support is ran out, but there are companies that provide the so-called long-term support, which means they are basically taking over what the security team did, but you have to pay for that. So the security team is only doing it for free for you for seven and eight. And for six, you have to pay a monthly fee with companies. So they are actually checking modules and making sure that they're up to date and stuff like that. And the reason was just that the Drupal forever said, we are gonna... The security team is gonna support the newest and the second newest version. In checking composer... Yeah, the question is if we monitor composer files, if we only update and monitor Drupal-related things or anything that we include it in composer. So currently, it's only the Drupal things, but give us three months about and then we will handle all available PHP projects that you include in composer and also NPM projects if you want to update Node.js or JavaScript files. Yeah, the question is if DropGuard creates tickets automatically or only updates existing ones. It creates tickets automatically and you don't need to use the DropGuard UI. You can control everything from your JIRA. So if you set a task to a status, that means it's test past, then an action on DropGuard or on Amazio or any other hosting platform can be triggered. Sorry? Yes? Yeah. Yeah. You can configure it whatever you want in here. That was just an example. How side of Drupal were you going to say this sets of NPM updates that we do? Yeah. So that's really a special thing in Drupal that they have a security level rating, but other projects, other open source projects have at least a similar thing. They also have a security updates and they announced the security level as well. It's not one to 25, but it's one to 100 or something like this. And we crawl different databases. So there are different databases like WalnDB, which has vulnerabilities of other open source projects. We crawl them all together, put them in a database and make the calculation if there's a new update and how critical it is. And map it to the one to 25 scale. Okay. Good. Then I wish you all a lonely evening and Secure Drupal-ing. And yeah, happy updating. Thanks.