 Good afternoon everybody. We will get started in about a minute for now You can answer our poll question of what is security. I like how we've gone from Hell to wearing a cool hat to the latest iteration of Broadway theater Manifest is rapid illustrations of safety followed by the feeling of despair when your main site dies only to realize that it was a typo by your intern after management decided to switch to the next tip Technology their nephew right on the internet. I think we've all been there At least I've been there at some point maybe and now it got very quiet, so I feel like I should just start Okay, fine. Well, welcome. This is the security team presentation. Yeah. Oh, are you waving to somebody? Okay Little early for questions welcome. This is the security team presentation We've got a large number of slides and a bunch of stuff to get through so I'm gonna go ahead and get started I'm gonna come see it. Okay, so What is security and obviously the follow-up question is what makes something secure and you know We don't have a good answer for this which is ironic because we're the security team We have lots of answers of things that help make things secure But there really isn't any one single thing that makes something absolutely secure When we think about security, there's a lot of definitions for this Yeah, I don't think these are any of the definitions we would use maybe awareness of risk The the typical definition we use is this is what's called the CIA triad CIA is not reference referencing a government agency here in the US It's referencing three areas of security confidentiality integrity and availability But there's lots of answers here and it ultimately depends on your organization I'm here today working with the Drupal security team All of us are members with the exception of Tim on the end. Tim is with the DA We're a vault we're a group of volunteers who work to improve the security of the Drupal project as a whole Come on in find some space We've got some room at the table up front where we were all sitting earlier So Currently the security team has 29 full team members and five provisional team members They come from everywhere and they come from all different, you know use cases of Drupal from agency work to nonprofits To for profits to education So for the security team members that are up here I kind of like to go through and do a little bit of introductions here because it's nice to know who you're talking to My name is Michael Hess. My favorite vulnerability is probably sequel injection Just because you can do so much fun stuff with it Neil you got to turn your mic on Yeah, I'm Neil drum I Guess stored cross-site scripting Because then that you can pivot that to do more interesting things like sequel injection as as an admin I'm Angie Byron Guys both took my answers. I'm gonna go with Social engineering. That's a lot of fun You know using your charm and your wits about you in order to infiltrate your way into an organization And then you can do you don't need SQL injection or CSRF because you just grab the database on a USB stick and walk out Hi, I'm Benji Fisher provisional member of the team and Since all the good ones have been taken I'll say Insecure components or or not not keeping your software up to date because it's sort of like brushing your teeth You know you should do it, but are you? Have you seen these slides? As the non-security team member but member of the Drupal Association and helping to secure Drupal.org's infrastructure I'm gonna go With my favorite vulnerability being Supply chain or dependency resolution for vulnerabilities where a malware package can be introduced into something secondarily installed on your software stack Thank you everybody. So we have 29 full team members I've put some of their avatars up here some of these avatars and pictures of them are very very very out of date Like in this example, I still have hair. We won't go there You know we have people who volunteer on the security team But we also have organizations that in some manner sponsor work on the security team and so what this is is this is a Listing of organizations that were credited on four or more security advisories Between yesterday and a year ago yesterday because yesterday is when we ran the query for this So thank you for these organizations So lots of things that the security team does do and some things that we don't do and so I've got kind of a slide here to help coordinate and help you know set some expectations of what the security team does and doesn't do I'm gonna move this microphone This was not designed for somebody who likes to move around when they talk We we you know the primary thing we do is we help coordinate Disclosure to help keep Drupal secure. So if you get those emails on Wednesday, that is the primary thing we do And obviously it's not just the emails the emails are actually the easy part of the process It's all the work that happens prior to the emails of coordinating that issue We help with security related Drupal initiatives making sure that We have resourcing and that we've coordinated resources and if if Larger organization will need is brought into it. We help with that aspect We will help sometimes advise other open source security teams we've been doing this a long time I think 2004 or 2005 somewhere in there is when the security team was for 2005 Was when the security team was formally started? And so we've been doing this a long time We've got a lot of policies and a lot of procedures in place and we often coordinate with other open source teams on How to handle some of their bigger issues or how to get started? We've worked with get lab on there I'm sorry get hub on some of their security issues and kind of the formatting of that we've been an advisory member there We've also done some coordination with Google and other open source content management systems around You know Google's brought us all together to kind of solve some common problems You know we do some other things in here, but these are the main things that we are after as a security team in general We also have some misconceptions around things that people think we do But we don't do We do not proactively search for vulnerabilities and code We have 29 people we do not sit around and you know read every piece of code committed to Drupal dot org I Think that would be untenable for an individual to do there are team members on our team that actually do do code review, but it's not a primary goal of the team itself and Despite emails of pleas to do so. We do not fix your sites when they are compromised We are often interested in finding out how they get compromised But we don't help repair a damaged site. That's what your backups are for you. You are keeping backups, right? So the primary tool set that we use for for doing vulnerability remediation is something known as coordinated Disclosure and coordinated disclosure is exactly what it sounds like It's getting all the parties on the same page figuring out how we're going to address a problem addressing it and then letting the world know at the same time The the inverse of coordinated disclosure coordinated disclosure might be a zero day where somebody just says hey There's a security issue here That's bad. We don't want that to happen For a lot of reasons coordinated disclosure is a lot of work There's a fairly complex workflow that goes behind this Effectively we get a vulnerability that gets reported to the team and we do an initial triage of that vulnerability If the vulnerability appears to be valid we start working with the maintainer to figure out how to fix the vulnerability We don't proactively fix the vulnerability ourselves. We work with the maintainer of that code piece fix it test it and then eventually disclosure on a Wednesday We aim to do this around Wednesday at 4 p.m. UTC We've got the fixes ready to go at this point And it's just a matter of going through the effort of publishing the fixes and getting the releases out there The goal of this is to allow people to apply their security updates at a predictable time Without worrying if their sites are gonna break most of the time the goal is security updates only contain the security update itself so for example if we are doing a security update for a Module we will try not to actually fix Not to actually apply the security update to new features that have been released or new features that have been made since the last release But only to what was done on our last release effectively and get terminology We check out the tag that was made apply the fix there and then release a new tag By passing anything that's in the pipeline sometimes this doesn't work for a variety of reasons But that is the goal so that you're safe to apply that Version without actually having to you know worry. Well, what are all these new features going to be what what else is going to break? Now obviously in order for that to work. You need to be on the most current version of that module prior to the release or core so the output of this in the end becomes a coordinated a Security advisory which we refer to as an essay we abbreviate it and you can subscribe to these under your user edit page under Newsletters which at some point will probably move off of there Into another format, but there that's where all the newsletters used to be and I think we're the only one they are now You can also view them on Drupal.org at Drupal.org slash security and Drupal.org slash security slash contrib Occasionally we publish public service announcements public a service announcements are just you should be aware of this They're not necessarily something you have to take immediate action on and we don't typically handle those on Wednesdays Our goal with coordinated disclosure is we do this on Wednesdays Sometimes we have to do it on an off-cycle security release where we'll do something that isn't on a Wednesday And typically that's when things happen beyond our control When we issue a security advisory, we've got a lot of metadata attached to that security advisory. It's not just hey Here's the fix Probably the most important thing is The risk score now the risk scores are this you know generic fictitious site And what the risk might be to a generic fictitious site and obviously what you're doing on your site is You know you're gonna have to figure out what that risk is with what you're doing on your specific site But it gives you an idea of how how critical this might be You know it is it is a risk profile So some of you are running sites that have highly sensitive information your risk profile is significantly higher Some of you have sites that are effectively static brochure sites. Nobody's logging in. There's no user interaction There's only one user your risks are most of the time lower as a result We keep track of who's worked on what issue who actually fixed it Who actually reported it and who on the security team helped coordinate the process and that's tied into the issue credit system See the list of names and the companies from earlier in this presentation We also have version fields and how to fix the problem in some generic text Just some stats because we get asked for them in 2021 we had 10 core security advisories and 47 can trip in 2013 core and 38 can trip Okay Moving onward the end of Drupal 6. Yes Drupal 6 currently has Vendor provided support until October 22nd of 2022 That's hard to say twice and So if you're still running Drupal 6 anybody still running Drupal 6 Okay, couple people are still It's time to finally move off of Drupal 6 Which brings me to my next subject how many people are running Drupal 7 Okay, that's yet. Yes, we are starting so that that's more than can I get those hands again actually that's 85% of the room 89% of the room so we've kind of you know originally Drupal 7 was supposed to be end of life in 2020 it got a it got or 2021 2021 We bumped it a year to 2022 mostly because of COVID And we've now kind of changed this as opposed to continually bumping it We are reevaluating that decision frequently You can kind of see the Drupal 7 usage and the Drupal 8 and 9 usage and they appear to be Almost at that convergence point where you know, we'd expect them to continue on that trend afterwards Usage isn't the only thing we're making this decision on there's a lot of different Factors that go into this but ultimately in the end. This was a moral imperative to the project the security team Drees the Drupal Association and other concerned folks met and talked about this and tried to figure out what do we do here? How do we handle this and you know ultimately given the show of hands in this room? That's a pretty powerful sign that you know, I think we made the right call at this point We will at some point need to end of life Drupal 7 But it it has been extended for another year and we will continue to reevaluate that as time goes on We'll announce in July whether or not we're gonna bump it again And so we've kind of moved from this thing of well, you know Let's set a date and then let's continually like change the date to we're gonna evaluate this annually based on use need and other factors You know one of the reasons for this is running software. That's past end of life is really really risky The security team isn't watching out for it You're kind of just you know over there running it and it's kind of just you know doing its thing But it becomes a larger and larger attack surface You know large enterprises don't allow it If anybody's got you know those scanners out there they find end-of-life software and then you get emails saying hey You've got to take this off our network You know the other problem with end-of-life software that that's a larger factor here Is they often have other components that is required for them to run? that isn't part of the end-of-life itself and so you know if Drupal 7 still required PHP 5 3 that's a problem PHP 5 3 does not have any support from any vendor as far as I'm aware and Definitely not from the PHP project You know this is a this is from a site called sciware Which tracks some of these things and basically these are end-of-life products that got compromised in mass Because they hadn't been updated and so you know some of these are more serious than others But you know the bottom line here is running end-of-life or out-of-date software is not a good thing What does this come down to update? You know the minimum thing you can do is update. It's a little bit like brushing your teeth You know you put in a little bit of work and so you don't have to deal with a cavity later on I use this brushing teeth analogy a lot Because you know you do that daily work for you know Four minutes two minutes even a minute every day. Hopefully people are brushing their teeth for longer than a minute And it prevents you from having to do a bunch of work when your site gets compromised You know if you're running the software and we send out those Wednesday emails update the software easiest thing you could do So some other things you're able to do in this sphere is if you're using composer npm pin your dependencies Specify specifically the version of the software you want to be running so that your site doesn't accidentally upgrade To something that isn't insecure or something that breaks your site within a security window There's been lots of do you want to talk quickly about supply chain attacks since you brought it up? I mean there've been quite a few Some well some deliberate supply chain issues and some non-deliberate ones I mean even in the earlier days of npm do people remember the left pad situation right like you have the deletion of a dependency That was used by hundreds of thousands of sites and suddenly they couldn't build anymore And if people had committed deployment artifacts and all these things instead of relying on rebuilding them live from hot Linking from whatever repository their sites would still be up right and so but instead like half of the modern javascript based internet broke for like 36 hours or something like right and that wasn't even malicious Explicitly right and then you know the the other issue here is if someone compromises an upstream Dependency and releases a new version that is suddenly phoning home with database keys right like you do not want to suddenly Just accept that update on a regular cron run or something like that right we try and avoid these things and there's there's more To be said throughout the conference there's a couple other talks I don't know if you're gonna get to mention these or should I I don't think they're in the slide deck Okay, so We're working on supply chain security for Drupal's package management and updating In particular as part of automatic updates in the project browser initiative, so you'll hear more about this in the Dries note you can go to Ted Bowman's session which is Also Wednesday afternoon, I believe it's in the schedule that isn't here. Yeah, okay But yeah, lots of good things that we can do to protect ourselves, but also just some good hygiene That what we should fall pin pin your dependencies also You've got an entire operating system running. You've got other things that are running your site Make sure they're up to date as well So keep track, you know if you're hosting this yourself keep track of your Apache versions engine X PHP Lennox itself all of these things increase the surface attack range for your site itself You know the The you know this question here, you know keeping your reducing your surface area keeping your dependencies in code up to date PHP 5 3 I was originally going to say hey Raise your hand if you're running PHP 5 3, but don't do that Because you're pretty much telling me although the DA did not print Companies on name badges this year, but if they had you're telling me where I can go and attack because PHP 5 3 is pretty insecure at this point It's missed a lot of security updates. It tells me that if you're running that you're probably running older versions of kernels and other things So just keep your stuff up to date Anybody have any fun stories they want to share about up-to-dates or security best practices fun stories Fun in quotes Angie I feel like I need more warning than that. I will probably think of one fun stories I guess there's a famous Drupal vulnerability that goes by. It's I'm gonna get the name wrong What's the right way to say it say oh five that one? SA core zero zero five It was a famous one. It went by the tagline Drupal get in back in the day What was interesting about that one is that we traced the commit that caused that issue to be introduced into core and Drees committed it at about 1 a.m. On January 1st So it was a really good lesson in being mindful of you know What you're doing it when you might have had a few too many and maybe just go to bed instead of working on court I will tell you what that when that happened. I got calls from you know folks whose websites I was in some way responsible for consulting with and you know, thank you for updating my site. I Didn't My sites patch so I'm good, right? Did you patch your site? No, I didn't patch your site Well, then who patched my yeah, you're not very good No, you should assume that is compromised want to be attack patterns actually with sequel injection at the time was to Patch the site so that other people couldn't come in and get control of the site So speaking of patching sites What if you in your time zone or in your team you don't have the ability to be around on Wednesday and patch One of the things that we are working on is a product that the Drupal Association and the security team are offering called Drupal Stewart And this is a service that basically allows for some delay in patching highly critical updates Drupal Stewart acts as a web application firewall And it protects your site from certain known vulnerabilities before the vulnerability is disclosed and even before the update is released Web application firewalls work like network firewalls except they're down the food chain Basically, they look at the web request and they inspect it and if it meets a certain pattern, they deny it This is a great way to protect your sites against known attack vectors And in the case of Drupal Stewart unknown publicly attack vectors Stewart closes the gap Between the security release and when you update your site for highly critical issues That means your team doesn't necessarily have to be on alert to deploy a bunch of site changes quickly And for large multi-site installations in the enterprise where you know, it's not just as simple as hey Let's apply the patch and push it out to all of our servers. There's often a more complex QA process This can help with delaying that QA process It does have some limitations as everything has limitations at the moment. It only applies to highly critical core Vulnerabilities we may expand it in the future. There are some vulnerabilities that just can't be Can't be protected against using a WAF rule And there's a lot of false positives at times One of the things that we do with Drupal Stewart is we actually run it in what's called alert mode So that we can figure out what the false positives are in advance so they don't actually impact business traffic How does it work? So Security team is going to identify a vulnerability in its normal process that we think can be highly critical and mass exploitable So here's an example of one We figure out whether or not we can mitigate this with a web application firewall and we can And then when we release the PSA for all highly critical vulnerabilities We typically release a public service announcement that says hey upcoming on this date We are going to be releasing a highly critical vulnerability be aware We'll let you know whether or not Drupal Stewart actually can mitigate the problem so the WAF rules get communicated to our partners into a monitor only mode and We get feedback we do some refinements and Once we are ready to release we do the release prior to doing that release we switch this out of monitor only mode into enforcement mode and You've now got some protection against this between the time of release and the time it's updated now. This is a service It's not offered for free There's some pricing tiers to this there are three tiers around this I'm going to turn this over to Tim who's going to talk about our pricing tiers Yeah, the simplest way to understand this is that there are some platform level partners who've committed To cover everyone they host with so today aquea and pantheon cover all the sites hosted on their platform So if you're hosting with them, you are covered If you're working with another agency or if you own your own site There is a community tier level and basically it's between 10 and 15 dollars a month with some amount of usage based traffic To put the WAP in place. It's a globally distributed WAP application So the performance should be good kind of where you are and if necessary there are ways that it can be configured in concert with a CDM that's something you can talk to us about We tried to make it about as affordable as we can And all the proceeds we do make from it get reinvested back So hopefully we'll take those and put them into either bounties or security hardening programs Or other things that we would do with the security team and I would say as the early slide before we got to this Product came update update update is still the rule right this gives you this lets you schedule your update This says hey, there's a firewall protecting me while the vulnerability is there So I don't have to update the minute the release happens But over the course of the next day to maybe week you should still be hey doing your QA Making sure everything else is good and getting that update deployed so and just to be To be clear on that the the code fix for these is always free and always distributed This is a service that lets you delay applying that code fix Oh, and I saw a question submitted via your slide. I wish I don't know if you intended to take questions But one of the questions that I saw there was was about like how how steward works in terms of the WAF rules Themselves so the rules themselves are not shared publicly because they could be used to reverse engineer what the vulnerability was Right, so there you are routing through the service without direct transparency into those rules That's a kind of a limitation of the way it works But that's also why we're coordinating together with the security team and the platform level partners to you know check For false positives and things before we deploy so anyway Happy to answer more questions about that if you want to reach out to the DA at some point and we'll get there in One second if you're interested in learning more if you're a site owner and just want to sign up and see how this works You can go right now to Drupal org forward slash steward and follow the process to sign up and engage your site in it There is a 14-day free trial if you're a potential partner, please email Drupal steward at Drupal org and Tim or I likely Tim we'll get back to you with any questions You know Drupal steward's one way to apply updates quickly the other way to apply updates quickly is automatic updates You know the security team is working with the strategic initiative the I'm just David Strauss, I just blanked on his name. I apologize David Strauss is security member Ted is a provisional team member Ted has a presentation on Wednesday at 11 a.m On getting ready for automatic updates and core and kind of what this is going to look like and how it's going to work And how it's going to pull in the comp the composer dependencies and all all the mechanics that go around there one of the things that we're doing here is we're actually investing time and energy into a update framework and You know that could be used by multiple projects Neil do you want to talk about that a little bit as I'm putting you on the spot with no warning? Yeah, I mean the basic idea of automatic updates is Be able to automate composer and also Verify Cryptographically what composer is doing is you know comes from trusted source like it's been signed by Drupal works keys so you both know that you can't update automatically and You know if someone changes to stns or some sort of man-in-the-mill middle attack You're updating to something that Drupal dot work has provided signed rather than It's been a couple other supply chain probabilities where Attacker gets your automatic update system to download malicious code And that the framework is based on a standard an open source Standard called the update framework or tough to you F for short We'll talk about it a little bit also in the Drupal dot org panel tomorrow morning at 8 30 And I'm sure it'll get mentioned a little bit in this automatic updates panel as well And one of the great things about it is as we work together partly funded by things like Drupal steward And other collaborations We've made a php tough implementation that is also being explored By Joomla by type of three by other folks in the php ecosystem And we're hoping to kind of present it as a prototype so that it could be integrated into packages itself and make the entire php Ecosystem done so we're trying to prove it out in Drupal and get get the advantage of it We hope to secure everybody else because that's in the spirit of open source So given that I want to have time for Q&A. I'm not gonna actually take the time for people to answer this Well, apparently people are answer answering it. I'm glad that so far everybody has said yes and not what teeth But you know as we've mentioned earlier We use this analogy around brushing your teeth as this security framework and you know I know lots of projects I just got a bid for a project and they literally had a line item for security work at the end of the project and I'm like No Security is is this is the type of thing that has to be built into your daily workflow every time you take an action in the Site you are potentially changing your security footprint in your attack surface By adding that module by adding that third-party dependency by integrating a JavaScript front-end you increase that surface area Which isn't necessarily you know a reason not to do something, but you need to be aware of what those actions are It's not enough at the end of the project to come back and be like okay What security holes did we create because now you're fighting a release date and fixing your security holes? And so we typically talk about this framework of you know every time you do something Just take the extra minute or two to figure out what your security impact is so that you're not trying to do this at The end it is a lot more work to clean up a compromised site than it is to put a little bit of work in Every week towards your site security You know there are lots of like best practices around security. I'm not going to get into those There's I think there may be there's a history of presentations on security best practices But you know most of these are common sense Have a password policy don't make your admin user username admin and the password admin Don't you know don't commit secrets to your database like there's all there's all sorts of Best practices around security keeping your site up to David running the Running if you're running critical infrastructure making sure you've got the support in there to do it making sure that you're hosting is Up to what your site is don't you know spend lots of money on a complex website and then host it on you know Not performant hardware or not secure hardware You know shared web hosting is one of my Things that comes up a lot like if you're not doing shared web hosting right every single server on that site Is running as the same user account and if one of them gets compromised they can all be compromised Ask for code reviews This is like an easy thing to do. It's a great way to learn Ask for code reviews either from a peer from a consultant Sharing your code on Drupal.org will get people doesn't happen overnight But we'll get people to add comments to your code run a red team exercise We're effectively you turn to a group of people who are not directly involved in your site so can you compromise this and Anything is on the table from doing that from doing brute force attacks trying to guess passwords to social engineering Figure out if you can get into your site put your patch Wednesday on your calendar You know just make sure you've got the time set aside just to look at the end of the day What was released and does it impact our site? If you are interested in joining the security team there's a bunch of information on doing that at security dot Drupal.org slash join and We will be here on Thursday For our contribution day come find one of us wearing one of the three flavors of hats There's a blue version a black version and a white version flavors here and and a Yellow hat on the end But come find us if you're interested in getting started learning more come find us We do have about ten minutes left And I do want to have time for questions because this typically does take a Q&A standpoint. So is anybody Either come up and borrow a microphone if you would like to ask a question or we'll repeat it back Yeah, we'll repeat it Yeah So when traffic comes in what was the question? I'm sorry. Thank you So the question was the the individual has a site hosted on Pantheon They're using a third-party web application firewall in this case cloud flare and where does Drupal Stewart fit in? Thank you And the answer is that before your before traffic from the internet whether it's being routed through cloud flare or not Hits your website Pantheon takes care of enforcing the rule So it's built into Pantheon stack above your Site itself Yeah, so that is one of the problems with continually extending. I'm sorry. Thank you. I'm really bad at repeating these questions Question was what about Drupal 7 end of life? and the The ecosystem around Drupal 7 mostly contrived modules falling out falling out of PHP support So there's you know some contrived modules don't support Drupal 7 In that space And the answer is we're extending the support for core mostly the Contrib modules are still in the contrived modules hand and we don't have the resources To enforce that they get updated. We can't knock on a contributor's door and be like you must update this We can we can take responsibility for core itself. So, you know What does that actually translate to it translates to you may need to actually Watch that space to see if a module gets marked unsupported because the the maintainer no longer is interested in maintaining Drupal 7 code Which most aren't PHP? 7 Drupal 9 is the newest thing and going back and looking at the procedural oriented code of Drupal 7 Not that interesting for a lot of people There are some vendors in this space that may be willing to step in and help there But ultimately we can't force them to update Drupal 7 is PHP 7 compliant I think it's almost PHP 8 compliant. I'm not quite sure on that Yeah, but the intention is before Drupal 7 goes end of life to get it working on the latest versions of PHP and MySQL so that it can write it out for a while the other thing I would say about what Michael Michael's correct You can't we can't force anyone to do anything. It's an open-source community However, if you have some modules that are strategically important to you If you I don't know if I just still called this but it used to be called abandoned module process or something like that There is a process for taking over a module and if you you know Say you have to run a bunch of hacks in order to make it run on PHP 7 4 and the maintainer is a wall There's a process that you can follow to take over a maintainership of that module and it's pretty straightforward It's like ping the maintainer a couple of ways wait two weeks if they don't respond then file an issue and then you know For the most part, especially if you're present in the issue queue helping You know review patches and post things and stuff like that It's a pretty easy process and then that ensures that you don't have to run like a baby of like custom hacks on top of The module and then you could be part of the solution instead of kind of feeling like a victim waiting for you know Somebody to show up and do something There's also I've seen a lot of spaces where maintainers will say you can maintain the seven code and we'll keep Maintaining the eight or nine code so you don't actually have to take responsibility for all of it and some maintainers are very open to saying Yeah, please help us And if you know, you've got a bunch of patches in the issue queue and the maintainers not applying them and not allowing for You know collaboration talk to the DA Any other question Well, we'll help facilitate the process. They'll help facilitate the process any other questions comments or concerns. Yeah, so the question was The question was easy crowd The question was what what is the timeline for contrib maintainers to fix the issue and there's not a set Timeline on it what the security team likes to see is activity happening on the issue at at regular intervals There are some really really complex issues that take a while to resolve Especially, you know when you've got a module that's been around for a while it has a large use case and You know the the way the module is being used might actually be part of the security problem There there are sometimes times when issues can take you know several months to actually figure out What are the what are the issues to resolve? How are we gonna go about doing this what the security wants to team wants to see is progress on the issue? And so we you know we formally say I think it's I think it's a month We typically give a lot longer especially with COVID But we want to see that people are engaged commenting on the issue working towards a resolution and when when that doesn't happen We go through our abandoned module process Which is why back to Angie's point if you do have contrib space modules that are vital to your use Become co-maintainers you don't even have to be the primary maintainer asked to be a co-maintainer And one thing I'll add to that is like you know Often the security team will if they do have to mark contrib modules as unsupported because of a vulnerability That isn't responded to you right they might do a batch of those and at that time That's often when we see tons of people step forward and say hey wait, that's really important to me I want to help I want to get involved If you can try and do that sooner a part of your security practice can be hey Is there anything we depend on that looks like maybe it doesn't have enough support right and you can slip in there So you don't have to be reacting after you suddenly get the scary red message that says you're using an unsupported module So what what flagging those modules is unsupported is an enormous amount of work going back and unflagging them as Supported again is double the work. So if you can step in early, please do step in early It makes this a much smoother process for everybody Any other questions that I can remember to repeat Some on Slido, okay What is okay, so let me go through these in order Should core and contributed modules support EOL versions of PHP asking for a friend So By default core and contributed modules do support EOL versions of PHP because that's what they were built on You know, I think that core formally supports PHP 5 to Think that's right. I think it's five two or five three It's some very very early version that we don't have automated tests that work for it probably isn't supported very well I think that if you're you know, if you are running older versions of your stack including older versions of PHP Yes, it's good to update core But you probably have other security problems in there that aren't going to be solved just by updating core So yes, you're gonna resolve a highly critical issue by updating core, but you're not necessarily going to Like gonna you're not necessarily safe by just updating core What is Drupal Stewart What is Drupal Stewart? Is it only a service or more is it open? Is it an open source rule set? So I think Tim already answered this do you want to yeah, I addressed this earlier So again the rule set itself we don't publish because it could be used to reverse engineer the vulnerabilities It has to remain within the circle of trust which is why it's operated as a service Which is why we have infrastructure costs, which is why there's an expense associated But again, that's part of what we're using to finance things like the automatic updates effort to hopefully make it less necessary Right putting ourselves out of a job in that sense would be not so bad So yeah, we can't release the rule set there What's the recommendation do security review for internal code any automated way to do it? So there are lots of automated ways to security reviews I Am not going to repeat four letter words most of the time what they do is generate an enormous amount of false positives and Then you spend a bunch of time chasing ghosts That's not to say they don't have value where where they're valuable to me is if you're running a secure version of Drupal And you run it and it changes the output that might be worth investigating So if you've run it and you get you know 18 things and you've gone through the critical ones You're like yeah, these are all false positives and you add a new module and now you have 19 things That's probably something to look into but the the automated rule sets typically generate a lot of noise That's not to say they're bad there. They have a use. They're not the only thing you can do You know my my favorite thing. I don't know if anybody's familiar with rubber duck debugging You can Google it But effectively talk through your code out loud or have someone else talk through your code to you and you will spot lots of things Just by thinking through code and that's in that manner Also, you know, there are serve there are vendors that do this as their primary business model where they just do security reviews Finally also Just following general best practices like use the database API rather than write you write your own queries and You know if you use the API's Most of the time what you're doing will be secure by default Yes, that's absolutely correct You use the use the API's we have for databases for text for markup all of it And you get a lot because Drupal's a powerful platform on top of that and their pages on Drupal dot org for developers Describing how to write secure code in Drupal to talk about this in more detail. I Think that's answered all of these questions But it's hard to read and present because I'm looking down and I don't like doing that while talking about there's the Automated penetration testing. Yeah, that one. So automated penetration testing We have played around with this using third-party services And what ends up happening is just the number of things that get reported that are False positives end up being too much signal to noise One of the things that's been really really productive in the past if anybody has interest in funding it again Is we have done bug bounty programs Where we basically pay people to find security vulnerabilities Those are typically pretty good, but are expensive to run and they need a sponsor So if you are interested in sponsoring it, please come talk to me other than that it is 45 after the hour, I'm sorry, 15 We have five more minutes. Oh we have five more minutes So we have time for one more question that I will repeat. I do say that now any last questions Well, I'm glad we've solved all the mysteries about security Thank you very much everybody. Thank you all