 My name is Jackson Dale. I work for Ernest and Young. I'm the digital experience team lead in Sydney. Absolutely stoked to be here, so obviously just the quick spiel of our EY. We are putting a large amount of investment into Drupal at the moment and you can see that through our acquisition of Adelphi Digital, which is where I came from last year. That was around about November, so we're celebrating our one year anniversary at the moment. Through the acquisition, we can now say we've delivered over 100 GovCMS projects and Drupal projects. We have 40 plus developers all across the east coast of Australia and I think just last week we went live with the Department of Foreign Affairs Smart Traveler site. It's awesome. It shows the capability of the GovCMS platform and how you can do some cool things, integrating with Amazon's Pinpoint, I think it's called. Pinpoint? I've got the right to have my pinpoint, yeah. Doing some awesome subscription services in that sense and I think just over a week now it's got about 15,000 subscribers, so pretty cool things happening there. I have the pleasure of introducing Jess, who has taken eight flights from Wisconsin to be here. So, Jess boasts a pretty impressive resume in Drupal. She's been at the forefront of the community for many, many years now and she's one of two core Drupal release managers and I think I speak for a lot of us when I say that her work and the security team has made us sleep a little bit more soundly at night. So, in this talk, Jess is going to explore how Drupal 8 core has made its way off the island by leveraging industry standards like semantic versioning, package management, third party libraries and other external tools and how these changes will affect Drupal 9 and even Drupal 10. So, without further ado, I'd like to welcome to the stage Jess. So, just a note before I 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, maybe hide behind the furniture, maybe hide behind the nearest person. So, don't do that, it's distracting. So, yeah, as you said, my name is Jess and I'm XJM on Drupal.org. I'm part of a team of about a dozen Drupal core committers who review everyone's core patches. The 12 of us are the 12, 13, something like that. We're the only ones who can actually accept changes into the core project. Now, within that committer team, I'm one of the two active release managers. The release managers are responsible for creating the Drupal releases that you can actually install on your sites each month, as well as setting schedules, evaluating the potential disruption of changes, managing scope, and so on. I've helped coordinate all of the releases we've had for Drupal 8 to date and I've personally, as he said, rolled the majority of the security releases myself. So when your Drupal site says security update required, you can probably think about me saying hi. I work for Acquia and I'm part of the awesome Drupal acceleration team there. Our team works mostly full-time on Drupal core. 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 when Drupal 7 was being developed back in 2009 and 2010. And I'm not talking about multi-channel or machine learning, personalization, or headless setups. I mean a fundamental shift in the way that Web Software is developed, packaged, and released. I'm talking about the widespread adoption of GitHub. I'm talking about modern package managers like Composer, NPM, and Yarn. These shifts have affected how we develop Drupal and they affect what we need to do to keep Drupal site secure, now and in the future. So I'll first briefly introduce what we changed in Drupal 8 and what we're changing in Drupal 9. I'll go over how our dependencies affect our security process. We'll take a look at Drupal 8's specific PHP and JavaScript dependencies, along with a peek at the future of JavaScript in Drupal. And finally, I'll close with some lessons for secure package management that are applicable both to your sites or applications and to Drupal core. So let's first take a look at what we already changed in Drupal 8. One of the most important changes in Drupal 8 is that we actually schedule our releases now, yay! And we follow semantic versioning to add new features in minor releases without breaking backwards compatibility. Now back in Drupal 7 days, Drupal was ready when it was ready with no new features available until an entire major release was ready to ship and no major release shipping until those features were done. Starting with the release of Drupal 8 though, releases are scheduled and announced in advance and we ship whatever features are ready by those minor release dates. Now one of my responsibilities as a release manager is setting the schedule and making sure that nothing puts a release date at risk. Each minor release of Drupal core receives six months of active bugfix support, followed by six months of security coverage only. Another important change with Drupal 8 is that we've adopted modern best practices and tooling. You may have heard that Drupal 8 depends on symphony and twig, for example. Overall, there's a lot more third-party code in and around Drupal 8 compared to previous Drupal versions. Now we manage and package these third-party PHP dependencies with Composer, which is basically the industry standard at this point. Also, during the Drupal 8 release cycle, we refactored or we wrote basically everything in Drupal core. There's code maybe in the batch API that hasn't changed in more than a decade and hook system's still around, but other than that, Drupal 8 is pretty drastically different from previous Drupal releases. We also released Drupal 8.0.0 before the data migration path from Drupal 7 was ready, because we wanted to give new sites a chance to build on Drupal 8 while we were still finishing that migration path. And while the data migration path for monolingual sites has been stable for a few releases now, we're actually still working on the last few issues to stabilize the multilingual path. Public service announcement, if you have a Drupal 6 or 7 multilingual site, we would love, love, love, love, love you to try help us test the multilingual migration path. You can ping me in Slack or quiet one in Slack is actually the person who's probably most interested in that right now. She's one of the migrate maintainers. So even given all that with the migration path, despite the fact that there are a lot of improvements in Drupal 8, even as of 8.0 and much more now as of 8.8, which is going to be released next week, it's still been a slow process for existing sites to adopt it. That's snarling tazzy devil. So with all that in mind, let's take a look at what we're going to change in Drupal 9. And the answer is not much. Happy quacka. We want to keep innovating, but we don't want another difficult upgrade. So following the release of Drupal 8.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. And then the old code is simultaneously marked deprecated with a link to the replacement. This means that essentially we're building Drupal 9 in Drupal 8. It also means that module developers don't need to wait around for Drupal 9.0 to be stable to make their code compatible with it. They can just move away from the deprecated code on the schedule that works for them, and then their code base will actually work with both Drupal 8.0 and 9.0 at the same time, which is something that Drupal Core supports for the first time ever now. Now, our target release date for Drupal 9.0 is June of 2020, about six months from now. We have fallback dates in August and December in case we don't make that schedule. A long-term support version of Drupal 8.0 will also be released at the same time, and that'll probably be 8.9. So Drupal 9.0 will be exactly the same as 8.9, except for two things. The deprecated code that we've accumulated since Drupal 8.0 will be removed, and our dependencies will be updated to new major versions. Upgrading from Drupal 8.9 or 9.0 shouldn't be much more difficult than upgrading between minor releases is now, so long as you keep up to date with deprecations. Now, about two-thirds of Drupal sites are still running Drupal 7, partly because of the difficult upgrade path I mentioned, and partly just because Drupal experienced its steepest growth during the early years of Drupal 7.0's production support. We took all this into account and decided we needed to support Drupal 7.0 much longer after Drupal 9.0's release, so it'll be supported until November of 2021. Even if you're on Drupal 7.0 now, the best thing you can do is update your site's latest version of Drupal 8.0. That's going to become Drupal 8.0 this next week, which I will be tagging from here in Tasmania, by the way, first minor release from the Southern Hemisphere, so you can work on updating your sites to that, and that'll prepare you for Drupal 9.0. Just keep away from deprecated code. So take a nap, relax, Drupal 7.0, you've still got several years to finish that upgrade. So the deprecation process and continuous upgrade path actually mean that this upgrade, this Drupal 7.0 to 8.0 upgrade, should be the last difficult upgrade you have. If we do it right, the continuous upgrade path should make it so that in the future, major updates are much easier. Now, since Drupal 9.0 is just essentially a continuation of the Drupal 8.0 series, we're actually ending up lifeing Drupal 8.0 at the same time as Drupal 7.0. In November of 2021, in this case, because that's when Symphony 3, which is the major version of Symphony currently used by Drupal 8.0, will also reach its end of life. So I've promised you that we schedule our releases now, and that releases are predictable. So fast forward to November of 2021. Drupal 7.0 will have received almost 11 years of support. Drupal 8.0 will have had about 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 for Drupal 8.0 is directly in response to the end of life for Symphony 3.0. And that's going to become the new normal with our dependencies influencing 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 going to take a closer look at Drupal's dependencies, package management, and dependency security, and think about how these things affect both your sites or applications 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 and maintainability 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 also spend our time and energy writing code to interpret HTTP requests or run automated tests? Other projects have already done those things better, so let's use their code instead. That said, though, using 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 brief background information on Drupal's own security policies. Drupal practices coordinated disclosure, which is defined as a security model in which a vulnerability is disclosed only after a period of time that allows for the vulnerability to be patched. The goal of coordinated disclosure is to prepare fixes and allow sites a chance to update before giving potential attackers information that could be used to exploit the vulnerability. To facilitate coordinated disclosure, Drupal security issues are reported in a private issue tracker. We release each fix with a security advisory during predefined security windows on Wednesdays, or actually, I'm sorry, very, very early Thursday morning here. And we make the security fixes themselves as non-disruptive as possible. The goal of all of this is to allow people to apply security updates immediately at a predictable time without worrying that their sites are going to break. Now, an important part of coordinated disclosure is actually coordinating with other open source projects. For example, back in May, we coordinated a release with typo3 and Joomla for a library all three projects share. We released the fixes on the same day with those two other projects because we don't want one project to disclose a vulnerability that could be exploited in another before the fixes are available for both. And this coordination with other open source projects has actually become a significant part of the work that the Drupal security team does. Among all the Drupal 8 security releases to date, one in three have involved our upstream dependencies, one in three. Now, this doesn't mean our dependencies are any less secure than Drupal core. Theoretically, all their things be equal. If we were maintaining the code ourselves, we'd have the same number of vulnerabilities. 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 in a single release so that site owners don't have to apply so many security updates. When making a release for an upstream dependency, though, all that goes out the window. Hopefully, we'll find out in advance that a security release is going to happen for one of our dependencies, but sometimes we don't. Sometimes, we can work with the upstream project to set a coordinated disclosure date that works 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 release in advance for the upstream release. We have to wait until the upstream release is published, then retest it, tag it, package it, publish it all the day of the release. And finally, an upstream fix is more overhead both for us and for sites because we have to make more releases for fewer vulnerabilities rather than bundling multiple vulnerabilities on release dates that work for us. Another challenge we face with security vulnerabilities in our dependencies is how to ensure that triple sites are secure when dependency support cycles don't match our own. And I have an example to illustrate this. Back in 2015, when we released Drupal 8.0.0, PHP 7 hadn't even had a stable release yet, so we supported PHP 5.5 and 5.6 with our best effort to be compatible with PHP 7. In July of 2016, PHP ended its own official security coverage for 5.5. However, throughout 2016 and 2017, nearly 20% of all PHP sites on the Internet were still using PHP 5.5. Now, keep in mind some Linux distributions provide their own security patches for versions of PHP used by their long-term support releases. And in this case, PHP 5.5 was used by Ubuntu's trusty tar. Trusty tar had security coverage all the way until April of 2019 this past spring. So you can understand why a developer using that stack might reasonably expect their PHP 5.5 applications to keep working. At the same time, though, many releases of Composer packages around that time were starting to also require PHP 7. PHP 5.5 had no security coverage, and even PHP 5.6 was going to be out of security coverage soon. So in early 2018, we announced that we would require PHP 7, starting with Drupal 8.7.0, which came out in the spring of this past year in May. There was a risk in supporting PHP 5.5 for Solom 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 sites any security updates at all because you can't install an update if it adds system requirements that your host doesn't meet. Then, in the summer of 2018, months after we made that announcement about 8.7, we received a report of a URL rewrite and cache poisoning vulnerability that the researcher planned to disclose in August of that year. Now, my colleague Wim, no pictures, please. My colleague Wim researched the vulnerability, do you see how quick that was? Wim found that Drupal was vulnerable because the vulnerability was present in both Symphony and a couple of Zen framework libraries, including Zenfeed and Diatros, which are actually used by Core itself. So we collaborated with the security teams of all three of those projects, as well as the researcher who'd reported it, and came up with a disclosure date that would work for everyone, which was August 1st. We planned to release it as SA Core 2018.05. But then there was a problem. You can probably anticipate that there was a problem, otherwise I wouldn't be talking about this. Very late in the process, I discovered that Zen framework had also already dropped support for PHP 5.5 a year earlier in minor releases of their packages, despite that 20% of PHP sites were still using PHP 5.5 at that time. So we couldn't update Drupal to use the security release we'd helped coordinate because we didn't meet the PHP version requirements for it. Fortunately, it turned out that Drupal Core itself was only vulnerable because of Symphony. We weren't actually exercising the vulnerable code in the Zen libraries themselves. It was a near mess. What if Drupal had actually been using the vulnerable code in the Zen framework? We couldn't just drop support for PHP 5.5 during a security window that would have caused mass chaos and panic. When we have tried at the last minute to convince the maintainers of these upstream projects that have lots more audience than just Drupal, we have said, hey, you need to make a release contrary to your own release policies just for us because we're a special snowflake. Would we have forked or overridden the library's code and tried to backport a fix to the release that we were using? And then what if backporting had taken weeks or months? What would you have done then? The reporter was going to disclose that at a conference a week later. And then what about updating those packages if we had hacked them? So all this shows how important it is to keep dependencies up to date, but also the complications we have for doing so. So let's take a look at the specific composer dependencies that Drupal 8 has. What they're for, why they're there, and what managing them with composer means. I have some illustrations that my colleague and fellow security team member Cash Williams made at Drupal Con Seattle. This shows Drupal 8's composer dependencies as of our initial release back in 2015. The biggest segment here is the purple, which as I've said is symphony, our most important dependency. The green is Guzzle, our HTTP client. Guzzle replaced a single Drupal 7 function that had, this is true, an N-path complexity of over 25 billion. Arguably a good choice for our maintainability to adopt a third-party library for that. The yellow is a small library for validating email addresses. The orange is Doctrine, our annotation parser for plugins and such. Gray is Us, Drupal Core. The pink is the Zen framework stuff I mentioned earlier, stuff for parsing RSS feeds, plus Diaturals, which is our PSR7 implementation. And then squeezed in between that and symphony is Twig, which powers our theme layer. Now, fast forward to 8.7, which as I said was released back in May, and we have maybe a 30 to 50% increase in the number of dependencies in Core. The new salmon-colored stuff here is StackCores, which is the cross-origin resource-sharing library useful for headless setups. The typo3 far stream wrapper next to Twig is a library we added in a January security advisory to mitigate a remote code execution vulnerability in native PHP functionality. Finally, the blue stuff here being new is actually a little misleading. We have a dependency we've had since Drupal 7. It's just that before it was in a weird stale and slightly forked version. We had to do a security update for that back in January for that remote code execution in native PHP functionality. So in 8.7, we fixed it to be an actual compulsive dependency, so we could manage it more easily in the future. Now, of course, your typical Drupal site runs a lot more than just Core. And every could trim module is another dependency on the site and might bring its own dependencies with it. Even a simple distribution can add a lot. So this is the diagram for Lightning, which I don't feel bad showing you because it's an Aquia product and I know it's well maintained. Lightning is a starter kit for a basic Drupal site with some Aquia integration support baked in. And even this starter kit is already quite the tangle of dependencies with over 100 things there. This is 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. By the way, Lightning had the fewest of the distros that Cache presented to us in Seattle, so just keep that in mind. So few organizations could audit this much manually. Oops, wrong way. So this brings me to some of the drawbacks of using Composer. Some of these are general problems with any package manager, others are specific to Composer itself or Drupal's implementation of it. The point of a package manager is to not have to worry about upstream dependencies or version conflicts. When you install a package, the package manager will helpful pull in the project's dependencies and its dependencies, dependencies, dependencies, dependencies, and so on. So you might not actually know what you're installing or who owns it. This can cause some of the release management challenges I've already described, where there's difficulty balancing stability and security. But it also makes it that much easier for you to install something you never intended to install in the first place that might break your site or even contain malicious code. Information about the Composer dependencies also isn't surfaced anywhere in the Drupal user interface that way the module information is. Our related problem is that there's a disconnect between the security services that 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 actually a package registry specifically for Drupal projects, and it provides robust security features. Rich metadata about releases, built-in security reporting, push notifications, and coordinated disclosure across thousands of projects, all centrally facilitated by a volunteer security team. Think about that for a second. 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 in modules you've installed. Unfortunately, Composer also lacks any form of built-in security auditing or monitoring. In fact, it lacks any concept of security releases whatsoever. There are some third-party tools in libraries that try to work around this by tracking CVEs or declaring dependency conflicts with insecure versions, but it's all opt-in, not always up to date, and really no substitute for native functionality. Also, the vast majority of Composer packages are maintained on GitHub, which so far has no public mechanism for private-issue reporting. This means that vulnerabilities often get discussed in public before they're fixed, which prevents coordinated disclosure. Although I will say that just recently, GitHub did introduce beta features for a place to add your security policies and a way to create security advisories, which are helpful that will influence the Composer ecosystem in the long term. So those of you in the room are JavaScript developers. Might think that it's kind of adorable that I just spent multiple slides for, like, 10-plus minutes talking about the perils of having a few dozen Composer dependencies. The modern JavaScript ecosystem is different in a way that terrifies me. And not just because my JavaScript coding skills peaked in about 2003, although I will admit that is 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 production JavaScript dependencies as of 8.8. Several of them are deprecated in 8.8. Those are the ones that have a strike-through on the slide. And then the two highlighted in pink are new in 8.8, and I'll talk about them more in a little bit. I can't show you any fancy illustrations of this because right now, Drupal Core doesn't use a package manager for our JavaScript dependencies. They're just committed to Core straight up in an Assets folder. So 13 years ago, jQuery was committed to Drupal 5, our first-ever JavaScript dependency. JavaScript in 2005, how innovative. Later that year, Farbtastic was added to allow the Garland theme's colors to be customized. I need a quick show of hands here. Who all remembers the Garland theme? A lot of Drupal old-timers in the room. Go team! Now, 10 years ago, jQuery UI was added to support accessible modal dialogues in Drupal 7. This is when Drupal starts to look more like the Drupal we recognize today. Now, all three of these JavaScript dependencies are still a part of Drupal 8 Core today, even after more than a decade. Then the rest of the JavaScript dependencies here, like Backbone, CK Editor, and Match Media, were all new in Drupal 8. Now, these 18 or 20 total packages doesn't seem that bad, right? Like we were talking about 50 composer dependencies before. The trick here is that without a package manager or proper test coverage, updating these libraries is both tedious and risky. And frankly, a lot of the JavaScript both in these libraries and in Core itself is pretty legacy, which adds to the maintenance burden. The list here is also a teensy bit misleading, because jQuery UI there with the yellow asterisk accounts by itself for 38 separate libraries that Core exposes. So, let's take a closer look at our history with jQuery and jQuery UI, the most tightly coupled JavaScript dependencies we have. We'd really hoped to upgrade Drupal 8 to jQuery 3 before Drupal 8.00, but it was still only alpha at the time of our initial release. In fact, a stable version of it wasn't released until June of 2016, the next year. By May of 2017, jQuery was no longer providing any security coverage for anything below jQuery 3 at all, and they were publicly disclosed security vulnerabilities with jQuery 2 that they said they would not fix. While Drupal Core itself wasn't vulnerable to these issues, at least one contrib module was. Plus, there was some kind of problematic documentation on Drupal.org that made a suspect custom code out there was probably vulnerable as well. And we were at least as concerned about other possible vulnerabilities in the future. Exploits in the wild, public disclosure with no support from jQuery, sites hacked before we could mitigate it and so on. So given all of that, we decided we needed to do a major version upgrade for jQuery as soon as possible. Overall, because of compatibility issues with jQuery 3 and especially with jQuery UI, it was more than two years from when we first started making jQuery 3 compatible with Drupal Core at the time of its alpha release until we were actually successful in 2017. And even once complete, this update had downsides. All of the compatibility issues we had to deal with then went on to affect sites, themes, modules, custom code. Wrong way again. So this was one of a couple things that made Drupal 8.4.0 in particular a disruptive minor release. Actually breaking people's stuff and disincentivizing them from upgrading to a secure release of Drupal. Weighing that against the very real risk of sites being hacked while you're stuck on jQuery 2, it was a tough call. It's a common misconception that semantic versioning doesn't allow a major version update of a dependency in a minor release. Semantic versioning actually only covers your project's own API. But still, major version updates of dependencies in minor releases are not what people expect. Ideally, we'd only do such updates in major releases of Drupal. But on the other hand, as you can see, other projects release cycles and schedules don't always make that possible. And overall, if we do need to break sites, we'd rather do that in a regularly scheduled minor release when people can plan ahead for the disruption rather than in a security window when people can't plan ahead. Since that time-consuming dependency update two years ago, we've been using jQuery 3. And then in April of this year, it was announced that jQuery 3.4 was the last minor release of jQuery 3 and that jQuery 4 development was underway. It's 46% complete. I updated this screenshot today. So here we are in almost the same situation with a major release of Drupal coming up soon. On the other hand, jQuery UI hasn't seen any further development since the last time we updated it. In fact, it's officially considered end-of-life now, which means there's no security support for it whatsoever. And if jQuery 4 was released sometimes in the next couple of years, this puts us in a tough spot. jQuery 3 isn't guaranteed to have security coverage after jQuery 4 is released, and we know that jQuery UI isn't going to be compatible with it because there's no changes being made to it anymore. But it is- jQuery UI is an important part of Drupal's user interface. It's not about the model dialogs, it's about the R-complete fields, among a lot of other things. So what do we do? What do we replace it with? To tackle this problem, a bunch of us met with Drupal Core's JavaScript maintainers back in July. We agreed to start by deprecating the jQuery UI libraries that Core doesn't use itself and then moving those to contrib for a temporary VC layer. Then we researched and prototyped potential replacements for the library Core itself does use, looking for libraries that met our standards for code quality, maintainability, and so on. Now, since we had to complete our deprecations by the beta deadline, which was a few weeks ago, the final step for us is to fork the remaining parts of jQuery UI into Core so that we can patch them ourselves in case of a security release. And then we'll work to continue this replacement during the Drupal 9 minor release cycle. The goal is to have it all done by Drupal 10. Several of my colleagues and I worked on this over the past three months, we have a couple of people on the slide here, and we found a few good React-friendly libraries that we've added to Drupal 8.8 Core. Those are the ones that were in pink on the earlier slide. The last big project for us is to replace the jQuery UI dialogue, which is a critical user interaction and a critical point for site's accessibility. Replacing that is going to be a bigger project, one that we need to complete in the next couple of years. The issue is still open for discussion, and we actually love your help with that, and we're willing to work on bad old JavaScript code and convert it into new shiny JavaScript code. We have a lot of work to do before Drupal 10 still. So now let's talk about Drupal's JavaScript in the future. I teased this a little bit by mentioning React-friendliness on that last slide. Back in 2016, Dries announced that Drupal was going to adopt a modern JavaScript framework, and the JavaScript framework that our JavaScript contributors picked was React. One of the advantages of React is that it's well-maintained in the process, and we can be fairly sure it'll be well-maintained in the future because it's used and backed by Facebook. Now some of you might have feelings about that. It's in both the advantages and risks column for a reason, but at a minimum it gives us some future proofing. React also has a strict backwards compatibility policy and a deprecation process similar to our own. However, their major releases are more frequent than Drupal's, breaking changes every 18 months or so. It's also surprisingly difficult to find any information about React's security policies you'd think that would be on their website somewhere, but it's not. Presumably Facebook has incentive to keep both React and its upstream dependency secure, but I couldn't actually find any information at all about how to report a security vulnerability or how security is managed. What I see as the biggest challenge that we'll be facing, though, is actually more about the modern JavaScript ecosystem itself. There's a tendency for JavaScript developers these days to create these very small libraries and open-source them independently, which in some ways is great instead of installing a monolithic thing you just pull in the one teeny-tiny piece that you need. And it's also cool that there's a thriving community of open-source development. Sometimes these packages can be as small as a single function, which brings me to the infamous LeftPad. For those who don't know the story, LeftPad was, is actually a little NPM library that adds padding to the left side of the string. Not the right side, mind you, only the left side. Back in 2016, for reasons I won't go into, the developer of LeftPad decided to unpublish all of his NPM packages. In doing so, he accidentally, single-handedly broke the builds of thousands upon thousands of packages, including React as well as Node and Babel. It was so disruptive that NPM themselves actually took a totally unprecedented step of republishing that package without the author's permission. Now most React app developers never deliberately installed this dependency and may not have even known it was there because it was at least four or five levels removed from their code. This incident highlighted the fragility and risk that's inherent in the large dependency trees that are common in the modern JavaScript ecosystem. Now there's a couple things to keep in mind about this story. First of all, the author of LeftPad wasn't acting maliciously. And secondly, while things broke, they broke in a clean way with a fatal error on build. So comparatively speaking, it was easy to discover, report and fix. But any NPM package might have security vulnerabilities or might even contain malicious code tucked away inside something that seems useful as a way of tricking 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 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've said hello world. Now, when people say this, React developers respond to point out that you don't have to use Create React app to build a new project. And obviously, since it's about creating an app, it includes dev dependencies. I couldn't tell if this was just fun. So then I looked at a project that's directly relevant to the future of Drupal. The Drupal admin UI project is a proof-of-concept that's being built by the JavaScript modernization initiative for a fully-decoupled Drupal front-end. It's built on React and uses JSON API to communicate with Drupal. As of June, I didn't check recently, but as of June, it had 1,732 production dependencies. So this problem of large dependency trees is a real thing, and we're going to have to deal with it in the future. Now, there are mitigating factors from a security perspective, thankfully. Unlike Composer, the popular JavaScript package managers like NPM and Yarn do include built-in functionality to audit all of the dependencies you have for security vulnerabilities. So one thing that's obvious to me is that this command is going to need to be a part of Drupal's regular workflow in the future. Keep in mind, though, that this is still only auditing known public vulnerabilities. I don't know how complete the list is. Probably depends on the project, and I don't know that there's any... Well, there certainly isn't any hope of coordinated disclosure windows and whatnot with, you know, 1,700 different projects. So something we're going to have to figure out is when and how or if we'll create security releases for vulnerabilities in Drupal's React app dependencies. Also, we have to figure out how we're going to balance stability and security with these dependency trees that change almost every day. So let's think about some of the lessons we can draw from all this, right? I think the most important lesson from our experience is just 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. Every piece of software on your site is additional attack surface. The simplest thing you can do is to limit which 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 a part of your application. Look not only at the functionality, but at the code quality, package policies, and release history. Another lesson is to keep your dependencies up to date and to address deprecations and breaking changes before a lack of security coverage becomes an issue. That said, you should also lock the versions that you're using so they only get updated when you specifically intend it. New versions can introduce breaking changes, as we've seen sometimes even in minor or patch releases. Plus, indiscriminately updating to new versions can also put you at added risk if one of the packages is compromised by a malicious actor. Think about which dependencies are needed in production, and limit the rest to your development environment. But keep in mind the development dependencies expose you to security risk, too. It's a common myth that dep 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 built-in commands to audit package security, but Composer, on the other hand, lacks any feature for checking security advisories. There are a few workarounds you can use. The folks behind Symphony have an open-source database of known vulnerabilities, as well as an automated checker that you can upload your Composer lock file to and audit it for vulnerabilities in that database. There's also a couple Composer packages that declare version conflicts with insecure versions of other packages, and that includes one that Webflow wrote for Drupal itself, which I definitely recommend using if you have a Composer site. Just remember that it's written and supported by Webflow, who's one Drupal contributor, it's not an official Drupal project. In closing, the last general lesson I'd draw, I made three words into one there, is that this is the new normal. Now, package managers in general aren't a new thing. Pear has existed since many of us could do singing impressions of our dial-up modems. What's changed is that we now have modern package managers that developers simply expect to use to build with projects with huge open-source ecosystems. I don't think we can or should put the genie back in the bottle. We still get a lot of advantage from third-party dependencies, and if we want to be sustainable as a project, we need to engage with 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 also mitigate the risks therein. Before I wrap up, let me circle back to the question I posed 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 the Drupal release schedule going to look like in the coming years? We want a major release cycle where each major version of Drupal is supported for as long as possible, because that's what site owners prefer. However, we also know site owners consider Drupal unstable if there are major version changes that break stuff in minor releases of Drupal. We've also learned during the Drupal 8 cycle that having external PHP dependencies adds pressure for us to use only the latest versions in support, only the latest versions of PHP. But at the same time, dropping support for PHP 5 and 5.5 and 5.6, there was a lot of work for us, and I imagine it was hugely disruptive for those site owners that were still using it. So we'd like to minimize how often we have to do that in the future. To figure out exactly what we needed to do before Drupal 9's release and how long we can support Drupal 9 afterward, we've spent a lot of time evaluating our dependencies, including talking to upstream maintainers to learn their plans. If we time our releases right and set each release's PHP version requirements high enough, we should be able to provide at least three years of support for each major version. It's a shorter period than Drupal site owners are used to today. And we're also still not sure what we're going to do about the end of life of PHP 7.4. For those who haven't heard, PHP 7.4 was just released as a stable version, I think, last night, and it's going to be the last version of PHP 7. The next release of PHP 7 is PHP 8.5. The next release of PHP is PHP 8. That'll be out next year, or so they say. And so far, PHP has not budged on extending the security coverage for 7.4 beyond three years, so it's currently scheduled to be end of life at the end of 2022. Other than that, if we can find a way to work around that problem, we think we'll be able to support Drupal 9 until probably the end of 2023, based on the other dependencies. And then based on that, my best guess right now is that we're going to want to release Drupal 10 as early as 2022, probably the middle of the year. That's soon, right? That's not that far away. Now, there's no guarantees about that date. But on the other hand, keep in mind, if we're successful with the continuous upgrade path, it shouldn't actually matter as much what the actual release date is. So that's all I have today. If you have questions, feel free to come up to me during the break or join the D9 readiness channel on one word in Drupal Slack. You can ask a question of the Drupal 9 contribution team there anytime. Thanks all for listening, and thanks to EY Digital and Drupal South for helping me get here. It's a real pleasure to finally be at this event. I've wanted to come to Tasmania for years. I've wanted to come to Drupal South for years. So I'm glad to be here. Thank you.