 Bread lights on, everyone. Watch what you say. So before we, just to note, before we get started, I ask that people not take photos of me for privacy reasons. If I see a camera pointed toward me, I have an automatic response where I'll sort of flinch and duck out of the way, might hide behind the podium. Could be a little distracting for the session. So my name is Jess, and I'm better known as XJM on Drupal.org. I'm part of a team of about a dozen Drupal 8 core committers who review and commit everyone's patches to core. Within that team, I'm one of the two release managers. The two of us are the ones responsible for actually creating the releases you can install on your sites each month, as well as setting schedules, evaluating the potential disruption of changes, and so on. I've helped coordinate basically all of the security and minor releases we've had for Drupal 8 to date. And I've personally rolled most of the security releases myself. So when your Drupal site says security update required, you can kind of just think of that as me saying hi, maybe make your day a little better. I work for Acquia, and I'm part of the awesome Drupal acceleration team there. So the title of my session is Security, Drupal 9, and Navigating the Changing Web Landscape. The internet is a very different place than it was from back when Drupal 7 was released in 2011. And I'm not actually talking about headless setups or machine learning or multi-channel. I mean a fundamental shift in the way that web software is packaged, developed, and released. I'm talking about the launch of GitHub. I'm talking about the adoption of modern package managers like Composer, NPM, and Young. These shifts have affected how we developed Drupal, and they impact what we have to do to keep Drupal site secure now and in the future. So let's first take a look at what we already changed in Drupal 8. One of the most important changes we've made in Drupal 8 is that we actually schedule our releases now. And we follow semantic versioning to add new features without breaking backwards compatibility. Back in the day, Drupal was ready when it was ready with no new features shipped until an entire major version was ready to be released. Starting with Drupal 8, though, releases are scheduled and announced in advance. And we ship whatever features are ready by the date that they're supposed to be done. One of my responsibilities as a release manager is setting the schedule and making sure that nothing puts a release date at risk. Another important change with Drupal 8 is that we've adopted modern best practices and tooling. Overall, there's a lot more third party code in and around Drupal 8 compared to previous Drupal versions. You've probably heard that Drupal 8 depends on symphony and twig, for example. We manage and package Drupal 8's PHP dependencies with Composer, which is basically the industry standard at that point. At this point, we'll get right up here. Also, during the Drupal 8 development cycle, we refactored or rewrote basically everything in Drupal Core. There's code maybe in the batch API that hasn't changed in more than a decade, and the hook system is still around. But other than that, Drupal 8's APIs are pretty drastically different from previous releases. We also released Drupal 8.0.0 before the data migration path from Drupal 7 was stable, because we wanted to give new sites an opportunity to start building on Drupal 8 while we were finishing the migration path. So even though there are a lot of improvements in Drupal 8, even in Drupal 8.0, it's been a slow process for existing sites to adopt it. So with that in mind, let's take a look at what we're changing in Drupal 9. And the answer is not much. We want to keep innovating, but we do not want another difficult upgrade. So following the release of Drupal 8.0.0, we've adopted a continuous upgrade path, which is a concept we got from symphony. When we want to improve something now, instead of rewriting things wholesale, we add the new code in minor releases while leaving the old code in place. The old code is simultaneously marked deprecated with a link to the replacement. This means that, essentially, we're building Drupal 9.0 in Drupal 8.0.0. It also means that module developers don't have to wait around until Drupal 9.0 is stable to make their modules compatible with it. All they have to do is move away from deprecated code whenever it works for them. And then the same module code base will work with both Drupal 8.0 and 9.0 at the same time. Our target for the release schedule of Drupal 9.0 is for June of 2020, about seven months from now, with a fallback of December 2020. Drupal 9.0 will be exactly the same as Drupal 8.0.9, except for two things. The deprecated code that we have accumulated since 8.0.0 will be removed, and our dependencies will be updated to new major versions. Upgrading from Drupal 8.0 to 9.0 shouldn't be much more difficult than updating between minor releases so long as you keep up with deprecations. About two-thirds of sites are still running Drupal 7.0, partly because of the difficult upgrade path, and partly just because Drupal experienced its steepest growth during Drupal 7.0's active support. So it's gonna take a while to get all those sites updated. We took all this into account, and decided we needed to support Drupal 7.0 for much longer after Drupal 9.0's release. So it'll be supported until November 2021. Even if you're on Drupal 7.0 now, which I imagine a number of people probably are, the best thing that you can do to prepare your site for Drupal 9.0 is to update it to Drupal 8.0 now and to stay away from deprecations. The deprecation process and continuous upgrade path means that Drupal 7.0 to 8.0 is the last difficult update you'll have. And since Drupal 9.0 is basically just a continuation of the Drupal 8.0 series, Drupal 8.0's end of life is actually also in November of 2021, because that's when Symphony 3, the major version of Symphony currently used by Drupal 8.0 will reach its end of life. So I promised you we schedule our releases now and that releases are predictable. So in your head, fast forward to November 2021. Drupal 7.0 will have had nearly 11 years of support. Drupal 8.0 will have had six years. The end of life for Drupal 7.0 is a pragmatic decision we're making based on trends in the ecosystem. But the end of life of Drupal 8.0 is directly tied to the end of life for Symphony 3.0. And that's gonna become the new normal with our dependencies impacting our major release schedule. So when will Drupal 10.0 be released and when will Drupal 9.0 be end of life? It's a complicated puzzle to solve and it depends on our dependencies. So now we're gonna take a closer look at Drupal's dependencies, package management and dependency security and think about how those things affect both your site or application and Drupal's future. At the end of the day, the reason we have dependencies is to save work. We reduce the amount of code we have to maintain ourselves with the goal of increasing the overall code quality of Drupal as a project. People use Drupal to build powerful websites with robust data modeling. That's what we're good at. So why should we spend time maintaining software to interpret HTTP requests or run unit tests? Other open source projects have already done those things better so we should use them. That said, though, adding third party dependencies also adds new challenges to maintain Drupal and keep it secure. To explore the question of how our dependencies support and security affect us, I'll first give some very quick background information on Drupal's own security policies. Drupal practices coordinated disclosure which is described as a security model in which the vulnerability is disclosed only after a period of time that allows for the vulnerability to be patched. The goal of coordinated disclosure is to repair fixes in advance and allow sites a chance to update before giving potential attackers information that they could use to exploit the vulnerability. To facilitate coordinated disclosure, Drupal security issues are reported and handled in a private issue tracker. We release each fix with a security advisory during predefined security release windows on Wednesdays and we make the security fixes themselves as non-disruptive as possible. The goal of all this is to allow people to apply updates immediately at a predictable time without worrying that their sites are gonna break. Person in the back with a camera, please make sure that I'm not in the frame. Thank you. What was I saying? Okay, so an important part of coordinated disclosure is collaborating with other projects so that one project isn't disclosing vulnerabilities in another before there's fixes for both. So for example, back in May, there was a security vulnerability reported to the Drupal security team for a dependency library that Joomla and typo3 share with us. So we collaborated with Joomla and typo3 when releasing the fix for that and figuring out what date we should put it out. The coordination with other open source projects has actually become a significant part of the work that we do. Among all of the Drupal 8 releases we've had to date, one in three have involved our upstream dependencies. Now this doesn't mean that dependencies are any less secure than Drupal. Theoretically, all of the things being equal, we would have the same vulnerabilities if we were the ones maintaining the code. But it does have an impact on how we schedule and ship releases. When we have a vulnerability in our own code, we can review and test the fix ourselves in advance of disclosure. We can bundle multiple security fixes together in a single release so that site owners don't have to apply so many updates. When we're making a release for an upstream project though, all that goes out the window. Hopefully we'll find out in advance that a security release is gonna happen for one of our dependencies, but sometimes we don't. Sometimes we work with the upstream project to set a coordinated disclosure date that works well for us. But it depends on the project and it doesn't always work out. Sometimes we get patches ahead of time, but even then, testing a private, unreleased patch against a composer dependency is complicated. We also can't stage the core releases in advance when there's a dependency update. We have to wait for the upstream release, then test it, tag it, package it, publish it all the day of. And finally, an upstream fix is more overhead for both us and sites because we have to make more releases for fewer vulnerabilities rather than bold and blatant multiple vulnerabilities on release dates that work for us. Another challenge we face with security vulnerabilities in our dependencies is how to ensure that Drupal sites are secure when dependencies support cycles don't match our own. And I have an example to illustrate this. So we released Drupal 800 in November, 2015. And PHP 7.0 hadn't even had a stable release yet. So we've supported PHP 5.5 and 5.6 with our best effort to be PHP 7.0. We thought that we would be able to support it when it came out. Now, in July, 2016, so eight months later, PHP ended its official security coverage for PHP 5.5. However, throughout 2016 and 2017, nearly 20% of all PHP websites were still using PHP 5. And keep in mind, some Linux distributions provide their own security patches for PHP versions used by their long-term support releases. And PHP 5.5 was used by Ubuntu's trustee tar, which actually had security coverage all the way until April of 2019 this past year. A site owner using that stack might reasonably expect their applications to keep working on PHP 5. So early in 2018, we announced that we would require PHP 7, starting with Drupal 8.7.0, which came out this past spring and May. There was a risk in supporting PHP 5.5 for so long because it meant we had an increasing number of dependencies on old versions. We were weighing that against the risk of denying 20% of all Drupal sites any Drupal security updates at all, because you can't install an update if you don't meet the system requirements for it. Then in summer of 2018, months after we made our announcement about 8.7.0, we received a report of a URL rewrite and cache poisoning vulnerability that the researcher planned to disclose in August. My colleague, Wim, researched the report and found that the vulnerable code was present both in symphony and in the couples and libraries, including ZenFeed and Diaturals, which are used by Drupal Core. So we collaborated with the security teams of all three projects, as well as the researcher, to find a coordinated disclosure date that would work for us, and we came up with August 1st. So we planned to release it as SA Core 2018.05. Everything seemed okay, but then there was a problem that we discovered like the day of the release, which is always what happens, right? Very late in the process, I discovered that Zen had already dropped the HP55 support from those libraries in minor releases earlier that year. So we couldn't update Drupal to require the security versions from the release that we'd helped coordinate. Fortunately, it turned out that Drupal Core itself wasn't vulnerable because we were only exercising the symphony code, and we weren't using that part of the vulnerable Zen libraries at all. It was a near mess. What if Drupal had actually been vulnerable to using, if it had been using the Zen code and they were vulnerable through that path as well? We couldn't just drop support for PHP55 during a security window that would have caused mass chaos and panic. Would we have tried at the last minute to convince the maintainers of the upstream project to release a release contrary to their security policies, or would we fork the libraries and scramble to backport patches to an unsupported version? And then if we did that, what would that mean for updating those libraries in the future? So all this shows how important it is to keep dependencies on their latest versions, but also the complications we have for doing so. So let's take a look at Drupal 8's Composer dependencies and what managing them with Composer means. I have some illustrations. My colleague and fellow security team member, Cash Williams shared a Drupal Con Seattle. This is a diagram of Drupal 8's Composer dependencies as of our initial release back in 2015, along with their interdependencies. The purple arches at the bottom are Symphony, which like I said is our most critical dependency. Fast forward to 8.7, which was released back in May, and we have maybe a 30% increase in the number of dependencies. We've added a dependency to fix a security issue with PHP, we've added another that's useful for headless setups and so on, and those have brought their own dependencies with them. Now, of course, your typical Drupal site runs a lot more than just core, and even every contrived module is another dependency for the site and might bring its own dependencies with it. Even a simple distribution can add a lot. This is the diagram for Lightning, which I don't feel bad showing you because it's an Acquia product and I know it's well maintained. So Lightning is a starter kit for a generic Drupal site with some Acquia integration support baked in. Even the starter kit is already quite the tangle of over 100 dependencies, even without any advanced features like commerce or anything. And when you start building a site on top of this with additional modules and packages, it's easy to get to many hundreds of dependencies. Very few organizations can audit that much manually. So this brings me to some of the drawbacks of using Composer. Can I get more tea? Helpful person. Thank you. Run out of liquid. So yeah, so some of the, sorry, I'm sick and my voice is kind of going, so I'm trying to keep it lubricated here. So some of these problems here are general problems with any package manager and other are specific to Composer or to Drupal's implementation of it. Now the point of a package manager is to not have to worry about upstream dependencies or version conflicts in them. When you install a package manager, the package manager will helpfully pull in your project's dependencies and its dependencies dependencies and its dependencies dependencies dependencies and so on. So you don't necessarily know who owns or wrote the code you're installing or what it is. This can cause some of the release management challenges have already described where there's difficulty balancing stability with security, but it's also that much easier for something you didn't want in the first place to break your site or even to trick you into installing malicious code. Information about Composer dependencies also isn't surfaced anywhere in the Drupal user interface to where module information is. A related problem is that there's a disconnect between the security services Drupal provides and the security of Composer packages that contributed modules or site owners install. Something you might not have thought about is that Drupal.org is a package registry specifically for Drupal projects and it provides robust security features, rich metadata about releases, built-in security reporting, push notifications either. Where was I push notifications? Notes. Basically, Drupal.org is a package manager that does what every package manager should. It's just that it's built in-house by us. It gives you push notifications. It tells you when you need to update your site and then you also have coordinated disclosure for all the security advisories across thousands of projects and all that's facilitated by a volunteer security team. So we already actually have our own package management functionality. It's just that it's only for Drupal. And so integrating that with Composer and making it so that we get the advantages that we have from Drupal.org along with the advantages that we get from using Composer is a problem we haven't solved yet. For core, we update our Composer dependencies when they have a security vulnerability. If core itself is vulnerable, but that doesn't help you with vulnerabilities exercised by your own code or other packages you've installed. Unfortunately, Composer also lacks any form of built-in security auditing or monitoring. It lacks any concept of security advisories whatsoever. There are some third-party tools in libraries that try to fill this gap by tracking CDEs or declaring version conflicts with insecure versions of packages, but it's all often not always up to date and really no substitute for native functionality. Also, the vast majority of Composer packages are maintained on GitHub, which has no mechanism yet for private-issue reporting. This means that vulnerabilities often get discussed in public before they're fixed, preventing coordinated disclosure and increasing the possibility that an attacker can use that information to exploit some application that has the vulnerability currently. Just recently, GitHub did introduce beta features for security policies and advisories, and maybe that will influence Composer in the long term. We can hope. So I'm gonna leave this on my, when I look at my T here, I'm gonna leave that up there. So those of you in the room who are JavaScript developers, I think that it's adorable that I've just spent multiple slides talking about the perils of having a few dozen Composer dependencies. The modern JavaScript ecosystem is different in ways that terrify me and not just because my JavaScript coding skills peaked in about 2003, but I will admit that it's also a factor. Before we talk about the future of JavaScript in Drupal, let's talk about the past and present. These are Drupal 8's current JavaScript dependencies, although several of them are deprecated in 8.8 that might put little green strikes on those. Now, I can't show you any fancy illustrations of this because we actually don't use a package manager for Drupal's production JavaScript dependencies. They're just committed to core and will vendor assets directory. So 13 years ago, JQuery was committed to Drupal 5. It's this one right here. And then later that year, Carptastic was added to allow the garland themes colors to be customized. This is my Drupal old-timer test. Who remembers the garland theme? Yay! Okay, good. I don't feel old yet. Thank you for making me feel young. So then 10 years ago, JQuery UI was added to Drupal 7 to support accessible model dialogues. And all three of those libraries are still a part of Drupal 4 today. The rest of these JavaScript dependencies like Backbone, CK Editor and Match Media were new in Drupal 8. Now, 24 total packages doesn't seem so bad, right? When compared to those PHP dependencies. The trick here is that without a package manager or proper test coverage for a lot of our JavaScript, updating these libraries is both tedious and risky. And frankly, a lot of the JavaScript in these libraries is pretty legacy which adds to the maintenance burden. The list here is also a teensy bit misleading because in the list, JQuery got UI alone. Where's my evil friend up here? I put an asterisk by it for a reason. It accounts for more than, I think it's 38 separate libraries that are exposed to core. So it's not just one thing. So let's take a closer look at our history with JQuery and JQuery UI, which are the most tightly decoupled JavaScript dependencies we have. We'd really hoped to upgrade Drupal 8 to JQuery 3 before Drupal 8.0.0 back here. Is it finished not working? Let's get to the slides, that's why. There we go. But it was, JQuery 3 was still only an alpha at the time of its release. In fact, a stable version of JQuery 3 wasn't released until June of 2016, the next year. Now, by May 2017, JQuery was no longer providing minimal security coverage even for anything below JQuery 3. And there were publicly disclosed security issues with JQuery and JQuery 2 that said they would not fix. So I have called in here the JQuery 2 end of life. They never actually officially announced one, which might be tricky. Well, core itself was not vulnerable to this one particular Ajax vulnerability. At least one contrib module was. There was also some problematic documentation on Drupal.org that made it seem like that there was custom code that was vulnerable out there as well. Plus we were at least as concerned with the possibility of other vulnerabilities in the future. Public disclosure, no support from JQuery, exploits in the wild, Drupal sites hacked before we could mitigate it and so on. So given all that, we decided we needed to do a major version upgrade for JQuery as soon as possible. Overall, because of compatibility issues with JQuery and especially with JQuery UI, it was more than two years from when we first started tracking JQuery 3 at the time of its alpha until we were able to make JQuery core compatible with it. Even once complete, this update had downsides, those same compatibility issues that core had to resolve were just as likely to affect contrib in sites. So this was one of a couple things that made Drupal 8.4.0 a disruptive minor release, actually breaking people's sites and disincentivizing them from updating to a secure release. Weighing that against the very real risk of sites being hacked while we were stuck on JQuery 2 was a tough call. Ideally, we'd only do major version updates in major releases of Drupal, but other projects release schedules don't always make that possible. Overall, if we do need to break sites, we'd rather do it at least in a regularly scheduled minor release when sites can plan ahead for some disruption and test thoroughly before deploying. If we break sites with security releases, people can't plan ahead for that and it'll make it so they can't update immediately the way we need them to. So back in April, it was announced that JQuery 3.4 would be the last minor release of JQuery 3 and that JQuery 4 development is underway. No photos, please. Camera down. Put your camera down, please. No photos of me, please. If you didn't see this live at the start. So JQuery 4 development's underway and but JQuery UI, on the other hand, since that last time consuming update to be compatible with JQuery 3, it hasn't seen any development at all. And it was like things like 2017, there was a blog post about it. The last release was in 2016 and it's officially considered end of life now, which means that there's no security support for it anymore and Drupal Core is still using it. Plus, if JQuery 4 is released sometime in the next couple of years that puts us even in a trickier spot. JQuery 3 isn't guaranteed to have security coverage after JQuery 4 is released. And we know JQuery UI isn't gonna be compatible with JQuery 4, for sure. But JQuery UI is an important part of Drupal's user interface. It supports accessible modal dialogues and autocomplete fields, among other things. So what do we do? What do we replace that with? To tackle this problem, a bunch of us met with the JavaScript maintainers. We have one right here back in July and we agreed to start by deprecating the JQuery UI libraries core users directly and then moving them to contrib with the temporary backwards compatibility layer. So right now core exposes like 38 different things but only uses six of them. The remaining 32 things are gonna end up in contrib in Drupal 9 and people are gonna be encouraged to use that for their upgrade path if they need but find other solutions if possible since that's really dead code. So then we started to research and prototype potential replacements for the six components core does use and to see if they met our standards for quality and maintainability. Since we had to complete any deprecations by basically this week, the final step is to fork whatever was left into core so that we can patch it easily for security issues, reducing the technical debt and attack service without the 30 odd other libraries and continue to work on it in the Drupal 9 minor release cycle in the future. The goal will be to remove all of it by Drupal 10. Several of my colleagues worked on this over the past three months a lot and I have their faces up here. They managed to find a few react friendly future compatible libraries that were adding to Drupal 8.8 core so they'll be available for use in 8.8 and you can start porting your modules to them. The last big challenge though is the dialogue library which is a critical user interaction in a lot of Drupal UIs and critical point for accessibility. Replacing that will be a bigger project that we have to finish by Drupal 10. This issue is still open for discussion and we would love your help. So if you find one of these nice people or myself on sprint day, maybe you can help with that if you're a JavaScript or accessibility champion. So now let's talk about what JavaScript might look like in the future. I tease this a little bit by mentioning react friendliness in the last line. Did you notice that? It was a little subtle. In January of 2016, Drees announced that Drupal would adopt a modern JavaScript framework and the framework our JavaScript contributors fit is react. Now one of the advantages of react is that it's well maintained with a mature release process and we can be fairly sure we continue to be well maintained because it's used in fact by Facebook. Now you might have feelings about that. It's both the plus and minus columns for a reason because I'm trying to be fair here but it does give us a lot of future proofing. React also has a strict backwards compatibility policy and a deprecation process similar to our own. However, their major releases are quite frequent. Much more frequent than Drupals. Breaking changes every month or so. That said, the scope of the breaking changes actually probably isn't, like they don't break many things. So it's potentially not that much worse than we have with our other dependencies right now once you actually look at what they do. It's also surprisingly difficult to find any information about react security policies. I spent a lot of time researching this and I couldn't find anything. I had nothing about how to report a vulnerability, nothing about how securities manage. I found like one CDE for React on server that they provided security fixes for but there was no actual information. But anyone knows about this by the way, I would love it if you tell me. Not after the session because I have a meeting afterward but on sprint day find me and explain to me how it works. What I see as one of the biggest things we'll be facing for modernizing Drupals JavaScript is actually more about the modern JavaScript ecosystem itself. There's a tendency for JavaScript developers to create very small libraries and open source them independently which in some ways is great instead of installing a monolithic thing you can pull in just one teeny tiny piece that you need. And it's also really cool that there's this thriving open source community around this. Sometimes these packages can be as small as a single function which brings me to the infamous left pad. For those that don't know the story, what left pad was, it is a tiny library that adds left padding to the side of a string. Not the right side, mind you, just the left side. Back in 2016 for reasons that I won't go into because I only have a 40 minute talk, the authors of left pad chose to unpublish all of his NPM projects. And in doing so, he single handedly broke the builds of React as well as Node and Babel and thousands of other things. It was so disruptive that NPM actually took an unprecedented step of republishing the package without the author's permission. Most reactive app developers never deliberately installed this dependency and they may not have even known it existed because there was at least four or five levels upstream from that. This incident highlighted the risk and fragility from the large dependency trees that are common in the NPM ecosystem. Now there's a couple of things to keep in mind about this story. First of all, the author of left pad was not acting maliciously. And secondly, while a lot of things broke, they broke in a clean way with a fatal error on build. But any NPM package might have its own security vulnerabilities or might even contain malicious code tucked away inside something that seems useful to trick you. And when your application has hundreds or thousands of dependencies, four steps removed from the dependencies you declare, your potential attack surface increases significantly. So according to the end, this is my troll the JavaScript section to talk, just trigger warning. So according to the internet, if you use create react app to start a new react project, you'll get 1,568 dependencies right off the bat before you say hello world. Now when people say this, react developers would point out that you don't have to use create react app to build a project. And obviously it includes dev dependencies. So I couldn't figure out if this was just fun. So to understand better, I looked at a real project directly relevant to Drupal's future. The Drupal admin UI project is the proof of concept being built by the JavaScript modernization initiative for a fully decoupled Drupal admin frontend. It's built on react and uses web services to communicate with Drupal APIs. It's pretty slick. I checked and as of June, it has 1,732 production dependencies. Some 60 of those are hoisted version things. I couldn't do a flat install, but it's still 1,617 hundred. So this problem of large dependency trees is a real thing that we're going to have to handle in the future. Now there are mitigating factors from a security perspective. Unlike Composer, the popular JavaScript package managers like NPM and Yarn do include built-in functionality to audit all of your dependencies for known security vulnerabilities. And one thing that's obvious to me is that this is going to have to be a part of Drupal's workflow. Thank you Sally for patching a couple of vulnerabilities in dev dependencies, not production dependencies and a recent release of Drupal. It didn't get a security advisory because they were already declared in public and they weren't using Drupal in production and so forth. Now keep in mind, it is all not having known public security vulnerabilities. So this doesn't take into account malicious code that no one's discovered yet and vulnerability that's no one's discovered yet. It's only things people have already published. I don't know how complete the list is and I don't think there's any hope of coordinated disclosure windows or whatnot because we're talking about thousands of people. So something we're gonna have to figure out is when and how or if we'll issue security releases for our vulnerabilities in a Drupal React app, dependencies and how we'll balance stability and security with a dependency that's changing every day. So let's think about the lessons we can draw from all this. I think the most important lessons from our experiences is to be careful about external dependencies. They can add a lot of value but they can also expose you to fragility, instability and security complications outside your control, especially when you have hundreds or thousands of them. Every piece of software on your site is additional attack surface. The simplest thing you can do is limit what dependencies you add in the first place. Only add them if you need them and choose which you add carefully. Be sure to review your dependencies dependencies too because those are also going to become part of your application. Look not only at the functionality but at the code quality, package policies and release history. Another lesson here is to keep your dependencies up to date and to address deprecations and breaking changes before security coverage or lack thereof becomes an issue. That said, you should also lock the versions you're using so that you only get updated when you're specifically intended. New versions can introduce breaking changes, sometimes even in minor and patch releases. It happens all the time, I promise you. Indiscriminately updating to new releases also can put you at added risk if a package is compromised by a malicious actor. Think about which dependencies you need in production and limit the rest to your development environment. But keep in mind, development dependencies can expose you to security risks too. It's a common myth that dependencies don't need security process, they absolutely do. So keep them up to date too and consider a more secure development environment like a VM. Also remember that your dependencies mostly aren't covered by Drupal's security report. So be sure you're auditing their security. NPM and Yarn both have commands to audit packages for non-vulnerabilities. Composer, on the other hand, lacks any feature for checking security advisories. And a security checker that will audit your Composer lock files for those advisories is available from Symphony, actually. Oh, you're just trying to type. Yeah, so the folks, because I have, but there are a few work runs you can use for Composer's lack of staff. So Symphony has a security checker that'll audit your Composer lock for non-vulnerabilities. And there's also a couple of Composer packages that will declare version conflicts with insecure versions of other Composer packages, including one that Webflow Florian wrote for Drupal's security advisory specifically, which is handy. Keep in mind that these are third party tools and they won't necessarily have complete lists or be up to date because they're not maintained by the owner of the package because the owner of the package doesn't have a feature in Composer to use that for. In closing, the last general lesson I draw is that this is the new normal. Package managers in general aren't a new thing. Pair has existed since many of us could do singing impressions of our dial-up modems. But what's changed is that we have modern package managers that developers simply expect to use with large open-source ecosystems to build their applications. I don't think we can or put the genie back in the bottle. We still get a lot of advantage from using third party dependencies. And if we want to be sustainable as a project, we need to engage other communities and meet contemporary developers' expectations. So we need to adapt and iterate on our best practices so that we can stay relevant and take advantage of the new normal but then mitigate the risks they're in. Before I wrap up, let me circle back to the question I posted at the beginning of the talk. Based on all this, how long will Drupal 9 be supported? When will Drupal 10 be released? And what's Drupal's release schedule going to look like in the coming years? We want to have a major release cycle where each major release is supported for as long as possible because we know that's what site owners prefer. However, we also know site owners consider Drupal unstable if there are major version updates of dependencies in minor releases. So figure out what exactly we need to do before Drupal 9's release and how long we can support it afterward. We spent a lot of time evaluating the future of dependencies, including talking to upstream maintainers to learn their plans. We've also learned that during the Drupal 8 cycle that having external PHP dependencies adds pressure to support only the latest versions of PHP, which is not something we did before because before we were being considered of the long-term support, the long-term Linux distributions. Excuse me. We've also learned that it was very disruptive for us to drop support for PHP FUD and I imagine it was disruptive for sites as well. So it puts us in a tricky situation. Now if we time our releases right and set each major release's PHP requirement high enough, we should be able to provide at least three years of support for each major version. Unfortunately, three years is a far shorter period that Drupal site owners are used to these days. All in all, we think we should be able to support Drupal 9 until at least the end of 2023 for hopefully a three-and-a-half year lifetime. So my best guess now based on that is that we'll want to release Drupal 10 sometime in 2022. You heard it here first. No guarantees about that date, but if we're successful with the continuous upgrade path, it shouldn't matter what the exact release date is. If you want to help out with Drupal 9 preparation or composer support or educating me on how to deal with React dependency trees, you can join the contribution day on Thursday. There are Drupal 9 related sprints for first-time contributors and seasoned core contributors alike. Or you can join the Drupal 9 readiness channel in Drupal Slack. There are meetings at 800 UTC every other Monday or you could ask a question anytime. That's all I have for today. I have two minutes left, but I'm going to have to duck out and leave. So I'm going to press the red button. There we go. Because I have a meeting and I don't know if it got rescheduled. That's for the fact that this talk started 15 minutes late. So thank you all. You've been a lovely audience. I wish I could do a Q&A.