 I'm Aaron Campbell. The reason that I'm here to talk to you about what WordPress is doing to keep your site safe is because I lead the WordPress security team. So I am pretty deeply involved in the things that we're trying to do to secure WordPress to keep it safe. A little bit of sort of my backstory cut as short as possible. I've been in the web development space professionally for about 18 years. Been using WordPress heavily as a tool for that for about 13. Have been contributing code back to the WordPress project for about 11 years and leading the security team for the last year, year and a half now. And it seems like our goal would be super obvious, right? Our goal is to keep WordPress secure. And that's close. And that is the thing that I hear most from people when I ask them what do you think our security team's goal is. But really, our goal is to keep WordPress users secure. And that makes our job a lot harder because no one just uses WordPress. Who here runs or uses regularly a WordPress site? There we go. Hands. Who here has one of those sites that has no plugins on it? Who here runs a WordPress site and does 100% of the hosting themselves? They don't use a host at all. See, there are all these other things that are tied up in the security of your WordPress site that goes far beyond just WordPress core code. And so we try to take a bigger look at what your actual experience is like in running a WordPress site and try to figure out what are the things that we can do to help make life as easy on you as possible around security. There's one more big thing that makes our job a little difficult and that is this number. This is the percentage of the internet that WordPress powers based on a sampling of the top 10 million sites. So yes, we're extrapolating a bit, but from a decent size sample, WordPress powers over 30% of the internet. We are nearing that place where one in every three sites on the internet that you visit is a WordPress site. And that is not all cat blogs or like my parents blog. I just spent this last week at DrupalCon doing some inter-project work, which has been pretty fun. But I listened to a talk by Pantheon who's actually here too. Their CEO did a talk there and they just did some research breaking down markets and what CMSs they use. And from the companies that say gross less than a million a year all the way up to companies that gross more than $10 billion a year in every single one of those markets that they divided it up into, WordPress while our share varies is always the most commonly used CMS. That's a lot to sit on the shoulders of any group of any project. It's a lot and we take it very serious. We work very hard to make sure that from all the way from those Fortune 500 companies down to the WordPress sites that my parents run are secure for those people in the way that they are using it. So speaking of the team because thank goodness it is not just me trying to do all this. I love to talk to people about the WordPress security team specifically and I get to hear a lot of times how people picture that team. And it's so drastically different than how I picture our team. I feel like when I'm talking to people they sort of picture like an elite force of trained security professionals which we do have. We may not look like this. Maybe our online avatars do. We're maybe the geek equivalent of this in a lot of people's minds. But even then that's not really how I picture our team. We have a volunteer team of just over 30 people. Many of whom do digital security in their professional day to day. These are in fact elite well trained people. But I picture us a little bit more like this which is kind of fun. And that's mostly because I feel like security online especially around WordPress which is where I spend almost all of my time is very much a balancing act. Yes we are good at securing things but I think what makes us really great at what we do is that we're good at finding the right balance. Security is always a balance between securing things as much as possible and also keeping them as usable and useful as possible as friendly and simple as possible. And finding that balance between those two is way harder than just securing all the things. It's sort of like bank vaults are super secure. Your house you want it to be secure but not bank vault secure. You want to be able to be carrying a bag of groceries and still get in your front door. That's an important task that you want to be able to carry out. Where is that proper balance? Where does that reside? And so I feel like that is a lot of what we do. Balancing usability and security as well as balancing security that is flexible enough for these Fortune 500 companies that do things very differently to be able to use it in a way that works for them. But also by default simple enough and functional enough that when my parents made their WordPress site it was secure. So some specifics around how we do that. We do a lot of things that everybody expects that we do. We do lots of code review. WordPress is ever changing ever growing ever pushing forward which is important. So we are constantly looking through new code code that's changing new things that are being added. A lot of people know about Gutenberg or you're going to learn all kinds of stuff about it today. And our team is actively watching all that code as it comes in to make sure that what is currently secure stays that way even though it's changing because again there's a balance. It would be way easier to secure WordPress and even the plug-in ecosphere and everything if we could just get it to hold still for a while. We could get better and better at sort of building this wall of protection around it. But it would quickly become pointless, useless, old. No one would want WordPress anymore. So we have this balance. Another thing that we do that some of you may know about is our bug bounty program. Who knew that WordPress runs a bug bounty program? Who doesn't know what a bug bounty program is? So we've always as long as the project has existed we have let people report security vulnerabilities. That's expected, right? We now have a much more efficient system for that where not only can they report security vulnerabilities to us, but we end up paying out a cash, thank you if you will, for them doing this responsibly. When someone finds a security vulnerability in WordPress we want them to tell us and let us fix it rather than publish it and let people break a bunch of WordPress sites. So we incentivize that with money. We pay out money to say thank you for doing this responsibly and helping us keep all our tens of millions of users secure. And that's all run through hacker1.com slash WordPress. Hacker1 is the most popular tool for doing this right now. It's sort of bug bounty program as a service if you will. And this is a relatively new project. We've been doing this for a little over a year. We launched a little over a year ago and we've had a lot of success with it. Not everything related to it is success, but there's some big ones. It really helped us increase the number of issues reported to us. It made it way easier to report security vulnerabilities to us, which I think is good. We can't fix things we don't know about. And while we're still at a point where far more security vulnerabilities are found by our security team than by outside people, getting the help of outside people is fantastic. They bring points of view that we don't. They bring use cases that WordPress is used by so many people in so many different ways. Hearing from them is important to our success. And so this increased number while it can feel like it might be a bad thing because we're hearing about more issues, ultimately it's a good thing because we're fixing more issues as well. We were able to make our reporters feel much more appreciated as drastically increased the number of people that repeatedly help us find security vulnerabilities. And this is important when you stop and think about it. Your site is being secured by this team, but also it has other people all over the world actively looking for potential problems and bringing them to our attention so that we can fix them. And with these cash thank yous for helping us, we get these people helping us over and over and over. And it's been fantastic. Right now, I just checked this morning, our average bounty paid out is $350 for valid issues. And it varies. We pay out based on severity, which we calculate depending on sort of worst case scenario with the bug, how many people it could potentially affect, what project it's a part of because our team actually covers more than just WordPress. We cover WordPress, BuddyPress, BBPress, WPCLI, which is command line tools that a lot of hosts use for helping manage WordPress stuff. All these things that are part of our ecosystem as well as WordPress.org, every WordCamp site, so the WordCamp Atlanta site, if there turns out to be a security vulnerability with that, our team helps handle it and our bug bounty program accepts reports for that as well. And in total in the last year we've paid out over $17,000 to help make sure that we are constantly getting things reported to us. Which I think is great. People look at hackers and we've made that a very negative term. Most security researchers consider themselves hackers, they just do it for good, they like to say. And so having them on our side is so, so much better than fighting against them. And the last big success that came from our bug bounty program was actually because we launched it on Hacker 1 and that is that it brought us much better tools. About a year and a half ago, just before we launched this program, the way that we handled all security issues in the biggest content management system on the internet was by email. And people would email us an issue and being able to communicate securely back and forth with them, send them potential patches that fix the issue, making sure that we were understanding all that was really difficult. Email is not fantastic for that. Especially when we want to keep our whole team involved and there's constantly the, I'm going to reply to this but maybe eight other security team members are also about to reply to this and that poor person is going to get inundated with reports or maybe we all assume that somebody else is about to reply to this and no one's going to because of that and they're going to get no answers from us. And so it's made our communication with them much more fluid and made it much easier to track issues from start to completion. But it's come with some struggles as well and I think that understanding some of the areas that we struggle in around security will help you get a better picture of just how active we are and how much we're doing. Over the lifetime of this program, only about 13.4% of reported issues are valid issues, which is obviously a struggle especially with a volunteer team that is volunteering their time. Some of them may get some hours paid by employers but by and large the vast majority is volunteer. Having to go through 20 reports to find two valid ones is time consuming. It sucks up a lot of time and no one wants to volunteer to push through a bunch of invalid reports. That's not fun work. We like to volunteer to do things that we enjoy doing, right? Something that we get some sort of fulfillment or excitement or something from. This is not it. We've been able to make some progress. This number is actually inflated. It's optimistic. It includes the first six months of the program where we ran it in sort of closed beta where it was invite only. At that time for six months every report was valid because what we were doing is taking valid reports that had come in and inviting those people that reported it to use this tool so that we could get used to it and train on it. For six months we had 100% valid reports. All the invalid ones we weren't even importing in. For this year, since January 1, the valid reports is only about 8.3%. It's even lower. We've been able to work with Hacker 1 and make some improvements on that that even though the number is very low, life has gotten a little bit better for the security team again. We helped them pilot a program and now they've released it called Human Augmented Signal. I think is what they're calling it. Basically our first line of defense is some automated tools. If you report an issue that says there's cross-site scripting in WordPress, we pop up a thing saying, were you an administrator for the WordPress site when you tested this? Because administrators are trusted, they're allowed to put JavaScript in posts and if you can put JavaScript in posts, you can purposely cause cross-site scripting but we trust those users that's acceptable. Again, balance of usability versus security. A lot of you I'm sure have found the need to use JavaScript at times in your posts or pages or whatever. That's necessary. Our first line of defense is those automated things that say, hey, here's some more information, make sure that this is actually an issue. Our second line of defense now is not the security team anymore, which is fantastic. It's a team at Hacker 1 that looks through the issues and filters out the obvious invalid ones, the ones that are terribly reported, the ones that have been tested with automated tools but didn't have any person actually verify the issue because we use all those automated tools too. We do very consistent regular scans of WordPress, even plugins in the plugin repository. If a common automated security scanning tool finds a problem with WordPress, it is a false positive. It is guaranteed to be because we're using them all the time. They get to filter out some of that kind of stuff. Of the completely invalid reports, which is about 65% of reports because the gap in between there are ones that are duplicates or informative, helpful, but not really an actual security issue, but of that 65%, about half of those we never touch. They never make it through to us, so it has been great. The other big thing I said that this new program has given us a better ability to communicate with reporters ties us closer to the people that are finding these issues. That also means that every report is a little bit higher touch since communication is easier and doing that is important. It also means that it takes more time because we do need to communicate very regularly and with a volunteer team, time is our most precious resource. I think that's the way it is with a lot of people in the web development space. Time is very important. Anywhere we can save time is important. Anywhere that we lose time, even though it's valuable, even though communicating with these people is extremely valuable, it's still a bit of a struggle because we start to run out of people hours. But these things that everybody sort of expects that we're doing, like code reviews and getting vulnerability reports and acting on them, these are not the only things that we do to try to keep WordPress users and all your sites secure. One of the biggest, most effective things that I think we do is build relationships with several big groups of people. First of all, plugin developers. I said that no one runs WordPress without plugins. That was pretty well confirmed by the fact that no one here said that they ran WordPress without plugins. So staying connected to plugin developers and what's going on there helps us keep everyone secure. This means keeping close contact with the actual code that's in our plugin directory, which is a pretty good sampling, although not every plugin is hosted in our plugin directory, but also building relationships with the biggest, most prolific or most complex plugins in our marketplace. So that we can talk to them when we need to. We actually have a private security team channel on Slack that we use for a lot of communication, and we have another security plugins room that's also private, but it's a place for us to talk about security vulnerabilities with plugin developers that can help be our canary in the coal mine, if you will. People that can test our patches so that when we roll out a security fix, you don't have to worry whether it's going to break your site. Because testing to make sure we don't break WordPress core is easy comparatively. We've put a lot of time and effort into building all these tests that we can run to make sure we're not breaking our own stuff. But plugin developers and the companies behind them, they have their own test suites that they can run to make sure it's not affecting their plugin, and we want them to do that, especially the really big ones like Yoast SEO and Jetpack and WooCommerce, these ones that are on millions and millions of sites. I'm sure at least a hefty number of you are running one or possibly all of those. And so we want to make sure that we don't break your site. And so building this relationship has helped us get better and better at securing your site without breaking it, because that's important. Other CMSs, I mentioned that I spent all week at Drupalcon. It's been fantastic to see how many of the problems that we're trying to solve are also trying to be solved by other content management systems. We are the biggest, and so most people are looking to us, but that doesn't mean that we can't learn from them. And it's been great to work closer with them in solving those problems and in identifying potential issues that affect all of us. If there's a problem in PHP and that's what's actually causing the security issue and someone reports it to Drupal and Drupal fixes it, we want to coordinate if it also affects us. We don't want them to release before we release, because then the bad people, the threat actors are going to say, oh, I see how that exploit works. Let's see if we can break a bunch of WordPress sites. We'd rather coordinate and work together, and so we've been doing more and more of that to ensure that vulnerabilities don't end up out in the wild before we've already fixed them, which is also the focus of our relationships with hosts, which we have built more and more. Wow, what is showing on the screen is different than what's showing on my screen. That's fun. Other CMSs is down there, and on mine it's up at the top. I must have two different versions of my slideshow running. That's fantastic. Hosts and WAFs, WAFs or Web Application Firewalls. These groups get a really different view of what's going on on the web than WordPress does. In the WordPress code that we can control and work on, each individual site gets a picture of what's happening to it. But hosts and these firewalls get a picture of what's happening across potentially millions of sites. It's given us a much better view of what's going on. Also, by building these relationships with them, we've been able to start protecting WordPress sites and WordPress users in a place that we've never been able to before at the network layer. We can't usually, before in the past, we couldn't protect a thing until it hit WordPress. But hosts and firewalls can block things before it ever gets to WordPress. You cannot break into a WordPress site if you can't even get to it. And they are able to stop things that far back. It's like if we're securing the door of the house, they're securing the fence around the yard. If everyone that they can keep out at that point, we don't even have to worry about. And so by working with them and helping them to develop rules to block malicious traffic that doesn't block actual useful traffic, we've been able to protect users in a way that we've never been able to before. And we have another one of our rooms that we use for security, security hosts, that we are able to talk about these things, work back and forth, and we're seeing hosts work with each other now to help protect WordPress users. We have representatives from the EIG, which includes Bluehost, Pressable, GoDaddy, all these people that are here, WP Engine, and Liquid Web, and also places that do these firewalls like Cloudflare and in Capsula, SiteLock, all these places, we're now able to leverage their tools to protect our users, which is pretty fantastic, really. And because they're able to protect even before we've released a fix, we've been able to leverage them to give us a head start sometimes in sort of this never-ending race that I feel like I'm constantly running between us and them, between the people that are trying to fix and protect and the people that are constantly coming up with new ways to break and exploit. And so they're giving us a head start in that race, but even then, even if we can't get a head start because of vulnerability isn't really blockable like that, we are very good at running this race between us and them because of automatic updates. Who knows sort of how the WordPress automatic updates work or that your site is constantly updating with security patches even if you're not doing anything with it? Yeah, so your site is being updated with security patches pretty consistently, even without any interaction from you, which is fantastic. It means that if something serious is reported to my team and we work through the whole process of repeating the issue and fixing it, running all these tests and working with these groups, and we are ready to push out a fix, our project is very public. Lots of people are watching us all the time, good and bad. And so once that's out there, once we've released the fix, people know about the vulnerability. But by that time, we're already updating all your sites to protect them even if you're sleeping or having dinner with a client or whatever. You can be in a client meeting unable to do anything and we can be updating all your other client sites, protecting them without any interaction on your part. And so we've focused heavily on this because this is one of our strongest tools at protecting everyone. Like I said, as soon as stuff is out there in public, people are going to try to exploit it. But we're going to beat them there and secure the sites before they get there because our automatic updates are ridiculously fast. We have pushed so hard to speed things up and make it as fast as possible because we have a lot of sites to update. Tens of millions of WordPress sites to update every time. But even for a sort of normal release that's not OMG, the world is burning down, just a normal release, we're updating tens of thousands of sites a minute. Usually right after a normal release, that'll hover around 50 or 60,000 sites a minute that are updating through our auto update system. So we can speed that up for really important issues by planning ahead and reducing the amount of time between each time your WordPress site contacts our upgrade site to see if an upgrade is available. So we can actually, this is if we're trying to roll out updates over say a 12 to 24-hour period we can roll out updates over a one to two-hour period. So it's super impressive. Every time I see it happen, it kind of blows my mind and I do this pretty regularly and I still can't get used to it. It's just really awesome. But in order to do that, in order to be able to update your site, who was a little scared just now when they heard that I'm updating your site without you having to do anything? Okay, well I'm glad that at least there's mostly all of you, trust me. But seriously, in order to do that, we had to work very hard to earn your trust. That's obviously important. If I update your site to make it more secure, but I break it, you have every right to be upset. That is unacceptable. We can't do that. We can't break sites. So our auto update feature rolled out years ago. This has been in WordPress core for about four years now. It took us a very long time just to get it right, to put it in at the very beginning. But since then, we have continued to improve upon it very regularly. The success rate for auto updates is more than 99.9%. But the failure rate is actually less than .001%. And the difference between those is because we have soft failures where something may have gone wrong, but the update was able to roll back to exactly where it was and we'll try again. And so only .001% have problems with our automatic updates. And that tells me straight up through the numbers tells me that you are far more likely to have your site break because it was hacked because it wasn't updated than you are to have it break because we updated it. Like by several orders of magnitude. So that is something that we are super, super proud of. Now whenever I do these talks, I know that everybody is worried about security. Like this is a thing we're all concerned about with our sites. And I know that I give sort of a bit of a picture of what we're doing, but I try to leave lots of time to talk about whatever it is that you are specifically interested in around security. So that's what I'd like to do now is some Q&A. Again, I'm Aaron Campbell. My Twitter handle is up there. So the slides will be tweeted out momentarily for anybody that wants any of those. But I would love to take some questions.