Teaser

Oliver Sild: It allows hosting companies to finally offer security before the sites are hacked. So that’s a huge shift in the ecosystem.

Jesse Friedman: And that’s why I keep tying back over and over again that the hosting company has a responsibility to the brand of WordPress, to the ecosystem.

Oliver Sild: You only will take action once you know your site is hacked and the hosting company is sending you an angry message that, hey, your server is basically spreading malware and hosting phishing pages and doing all that kind of weird stuff, right?

Jesse Friedman: And so it doesn’t matter how secure your vault is, right? How thick that steel is. If the key is just sitting on the front stoop, it doesn’t matter.

Introduction

Jesse Friedman: Welcome to Impressive Hosting, where we seek to uncover the core tenets of great WordPress hosting. I am your host Jesse Friedman, and with me today is Oliver Sild from Patch Stack. We wanted to have him on today because he’s a security expert working on securing websites across the internet, and does a lot of work with hosting companies and thought he’d have a lot of great opinions for us today.

Oliver, thank you for coming on.

Oliver Sild: Thank you. Nice to be here.

Jesse Friedman: That’s great. Tell us a little bit about where you’re from, what Patch Stack is. Give us a little bit of background.

What is Patch Stack’s Origin Story?

Oliver Sild: So my name is Oliver. I’m the founder and the CEO of Patch Stack. I’m actually from Estonia, so this is right now later in the day for me compared to you guys. But yeah, Patch Stack kind of got started from originally building an internal tool.

I was running an agency back in the day where we actually built a lot of stuff on Joomla. And then at some point WordPress was basically taking over everything, but the problem we kind of noticed was the same where, you know, you build up the websites from so many different components and sometimes it’s becoming hard to track what kind of tools you’ve been using in certain websites and what is happening with them after you’ve deployed them and what needs maintenance and so forth. And then as my own kind of cybersecurity background, I was always additionally wary of what issues are present on those components that I’ve been using on different builds and things like that as well.

And then ultimately it kind of boiled into what Patch Stack is today, which is mostly a threat intelligence company with a very big focus on providing the fastest mitigation to security vulnerabilities.

Because when we look into the data, approximately 50% of the hacking incidents in the WordPress ecosystem happen because of security vulnerabilities within different plugins and themes and so forth that leave the websites exposed that remain unmaintained.

And then the second part of it is pretty much session hijacking, people using very poor passwords, stuff like that, which is a lot harder problem to solve because there’s the human element to it, right?

So we decided to go into solving this first half, which is essentially the security vulnerabilities. And we want to make sure that we are able to protect the websites and the users before hackers get to exploiting them. So this is something that we do for a lot of agencies. We work with a lot of web hosting companies to do that at scale. And this is really what we focus on.

Jesse Friedman: That’s great. So when did I start seeing Patch Stack show up at WordCamps and other conferences? What year was that?

Oliver Sild: So the company’s actually more than seven years old, so we’re not very new into this, but we did a rebrand in 2021. And this is the moment when we started really shifting our focus very, very heavily into threat intelligence. And then I think actually last year was the first year when we were sponsoring WordCamp Europe.

And then we also sponsored WordCamp US. And before that I think we’ve been at the WordCamps for like two or three years because we used to basically use WordCamp Europe as the place where we bring our entire team together once a year. So we are a fully distributed company, we have people in every single time zone, don’t have an office or anything, so we kind of always use WordCamps as a great way to travel together with our team and see each other face to face at least once a year.

Jesse Friedman: Oh yeah, that’s awesome. I come from a distributed company as well. Automattic is fully distributed and I know how great it can be. You have autonomy, you have the freedom to work the way you want to work and be productive the way that is best for you. But at the same time, you do tend to miss your colleagues, you do miss that in-office feel. So that’s great that you do a meetup around a WordCamp. So does that mean that Patch Stack is 100% WordPress focused, or are you helping to secure non-WordPress websites?

Oliver Sild: Actually when we started the company, I wasn’t even that much into WordPress. So as I mentioned, I started actually out of Joomla.

Jesse Friedman: It was Joomla.

Oliver Sild: And then we got into WordPress as well. And today Patch Stack is covering WordPress, Drupal, and Joomla. So we do threat intelligence for all three of them, and we provide auto-mitigation or vulnerability protection for all three of them as well.

And honestly, what we are currently working on internally is actually Laravel. So the whole vision for the company is to provide this layer of security for any open-source-based web applications. So we kind of ultimately want to cover the entire PHP ecosystem.

And from there on move to JavaScript applications as well, like Node.js and stuff like that. But yeah, WordPress is a very big elephant in the room. If we talk to any hosting company and ask what is the main challenge for them, if they want to keep their servers clean and customer support tickets low about compromised websites and stuff like that, they tell us 70% of the volume of what they host is basically WordPress.

So this is where we needed to focus or put our majority of our focus as we started going to the market with that.

What responsibility do hosting companies have for their customers’ security?

Jesse Friedman: Yeah, let’s get a big question out of the way then early. What do you feel is the responsibility a hosting company has to the security of a CMS like WordPress?

Oliver Sild: That’s a really good question because I actually had this discussion just earlier today with one of our customers where they’re the largest hosting company here in our region. And they were basically saying that what is happening very often is that customers don’t really have a very clear understanding of where the hosting company’s responsibility ends and where the customer’s responsibility starts.

And I think that’s a problem which is caused a little bit by marketing, I think as well. When you look at like, I would say five years ago, every hosting company was basically marketing themselves as the fastest, you know, everything about speed, performance, stuff like that.

And now what we see in the past few years is that everything is basically jumping into the security side of things like “the safest” and “the most secure” and things like that. But now when you think about security, it’s a lot harder problem to solve than performance.

And with security specifically, the responsibility is a lot different. Because if I think about the secure hosting service, then I’m thinking about having the server being maintained, you know, making sure that the PHP versions are up to date, that the infrastructure configurations are secure, that the hosting environment is isolating different websites from each other so there’s no lateral malware movement, all these kind of things. Or even just going to the hardware level of how this data center is being secured and all that kind of stuff that I wouldn’t really want to deal with myself.

But then there is the question of what the customer is using that hosting for, what are they hosting on that hosting and what they’re doing with that application where the hosting actually has not a lot of control over. So for example, if they install a WordPress website and now they decide to install 50 different plugins there and never update them. So what really, how can that be the responsibility for the hosting if hackers take over that website? Because that website had a plugin that was unmaintained for one year and it happened to include a very critical security vulnerability.

Jesse Friedman: And if that does happen, the customer’s gonna blame the hosting company anyway.

Oliver Sild: Exactly, and it’s happening all of the time. And that is the problem that needs to be solved right now.

I think there has been a little bit of shooting yourself in the foot situation where you’re marketing the hosting service as secure, but you’re actually not covering the application security.

The customers are clearly pissed when you go and select the hosting company and then your website, you think that, oh, I don’t need to think about security because the hosting service was marketed to me as a secure hosting. And they cover, I can have a secure WordPress experience.

And then a month later it turns out your website is hacked. And obviously I go to hosting company, I ask like, “Hey, you promised me something that I did not get.” And I think this is a problem that needs to be solved because otherwise everyone is affected. On one hand, hosting companies are affected because they actually cannot promise that, because that is not in their control 100%.

But also from the end user’s perspective, this is bad because they are giving away their responsibility to someone that doesn’t actually take that responsibility. And ultimately, this is causing a lot of just unnecessary pain, right? And confusion.

What are some ways to ensure better customer security?

Jesse Friedman: Yeah. So you know what’s funny is that we have talked about this a lot in this podcast. A common theme that comes up throughout this podcast is that a hosting company has a responsibility back to the ecosystem to provide a great WordPress experience. And that can mean performance. It can mean the way in which you build add-ons or create a panel UI or security is obviously in the forefront. If a hosting company takes on the responsibility of selling WordPress and attracting customers through advertising, word of mouth, whatever it might be, that will probably be for many customers their first and only WordPress experience if it’s not a good one.

So if their site gets hacked, if it’s vulnerable, if it’s causing them a headache because it requires so much extra work for them to keep it secure, they’re gonna move on to something else. And they’re not gonna try this with another hosting company because they have no reason to believe that another hosting company is gonna be any more secure. They’re gonna blame it on the WordPress experience. And so that’s why I keep tying back over and over again that the hosting company has a responsibility to the brand of WordPress, to the ecosystem.

And so, you know, the other thing that’s changed and shifted earlier in the previous decade: the company that I co-founded with a few colleagues that Automattic acquired was a company called Parka. We created a product called Brute Protect, and at the time we were trying to solve one of the most vulnerable areas of WordPress because inherently we know that WordPress, without any extensions, is pretty secure. What is the most vulnerable place? It’s your password. And at the time, WordPress wasn’t suggesting incredibly tough passwords. 1Password or other solutions like that weren’t prevalent. So, you know, a lot of people reused the same password over and over again, and it was super simple and it was like “password” or “123” or whatever it might be.

And so it doesn’t matter how secure your vault is, right? How thick that steel is. If the key is just sitting on the front stoop, it doesn’t matter, right?

Oliver Sild: Yeah.

Jesse Friedman: So Brute Protect was a solution that was a WordPress plugin that compiled attack vectors through cloud-powered data across all the internet and see where people were trying to hack into your site, trying multiple times to log in and failing.

And then what we used is we grabbed all that data and then we distributed it back out in real time to block those attack vectors. So it was like the first time that at least I had seen where, other than like something like Akismet, that was compiling information in real time and then distributing it across hosting companies in a way that’s working collaboratively with hosts.

Oliver Sild: Yeah.

Jesse Friedman: And I think that what we’ve seen since then is Jetpack Scan at Automattic.

Oliver Sild: Yep.

Jesse Friedman: And other solutions. We’re trying to bring the knowledge that we’re gaining from working with different hosting companies to create a hardened layer of security for the entire ecosystem. But at that time, customers didn’t care about security. The reason was, I think in my opinion, tell me if you think I’m wrong here, is that one is that they thought the host was gonna handle it all for them, and two is if you’re building a small blog, a mom and pop shop or whatever it might be, you don’t necessarily think that you’re vulnerable because why would anybody want to attack my site?

Why is my site under, why would you even want to get into the back end of my blog? I have nothing private or anything that’s gonna be powerful or helpful to you. But the reality of the situation is that these brute force attacks and other things out there, they just indiscriminately try to hack sites. They don’t care what’s on the other end of it because they might be able to get data, they might be able to get horsepower. They might be able to take control of the resources you have for your site to do something else more malicious or bad. So anyways, long story short. Do you think that that’s shifted in the industry? Do you think that the typical end customer is starting to think more about security, that it’s more front of mind for them?

Oliver Sild: I think for sure over the past five years, cybersecurity has become a mainstream topic, right? So everyone is thinking it’s not anymore like some nerdy thing that you’re going to talk about or something that less people care about. I mean, here you see cybersecurity being pushed through ISPs. You see it on the media and the news all of the time. So it’s obviously been getting to the people plus the younger generation who was maybe more tech-savvy is also growing up. So we have more people who are a little bit more tech-savvy than it was maybe a generation ago, right?

So I think there’s definitely a shift happening, but like you mentioned a few things which were specifically what we see is the customers don’t know that they’re vulnerable, for example. And if we look at WordPress ecosystem, which, you know, 20-plus years now, there has been security solutions around the entire time.

And then how much actually has changed in the sense of how many websites are getting hacked and so forth? It’s not that much and I think the reason for it is because most of the solutions that have been built for WordPress security so far have been reactive.

The biggest security companies that have been around are basically all based on malware scanning. WordPress is also like the only industry where malware cleanup or incident response is served as almost a security feature. It’s normalized getting a website hacked.

And I think that problem actually stems from that exact thing that you said is that people don’t know that they’re vulnerable and they don’t really care about security until they get hacked. And that’s how all of the solutions have been built around that. How we are now taking care of this thing after all these incidents happen.

And not a lot of attention went into like, okay, let’s look into what is even causing all of that and let’s try to solve it so those hacks don’t happen in the first place. And this is something where we were taking like a very strong direction in terms of like, okay, Patch Stack doesn’t do any malware scanning.

This has been like number one requested feature for I think five years. But we’re like, no, we want to just focus 100% on prevention and making sure that the customers, even through our hosting partnerships, that their customers know that they actually have security vulnerabilities in the first place.

So they would know that they need to even do anything because again, if you don’t know that you have vulnerabilities, then why should you even care? You only will take action once you know your site is hacked and the hosting company is sending you an angry message that, hey, your server is basically spreading malware and hosting phishing pages and doing all that kind of weird stuff, right?

So the way how we integrate with hosting companies is also taking that into mind. So we provide them—

Jesse Friedman: That information.

Oliver Sild: Exactly, yes. So we provide them threat intelligence as a service where Patch Stack acts as their external threat intelligence and security team. And we provide them with the vulnerability intelligence where they notify their entire customer base, letting them know that there are security issues present on the website.

So the customers at least understand that they have now their own responsibility about their own application that they’re hosting there. And now that they… and that there is something that they need to do about it. And that’s where we most cases offer Patch Stack protection as we are providing the virtual patching and the auto-mitigation rules for each and individual of those vulnerabilities.

Actually it allows hosting companies to finally offer security before the sites are hacked. So that’s a huge shift in the ecosystem actually.

Jesse Friedman: I can attest to that for sure. I mean, working with Jetpack for a long time, we have backups as a solution, and because Jetpack does a variety of other things, customers were coming to us after their site got hacked or after they broke their site in some way and they weren’t enabling backups.

And so then they’d come to us and ask us, “Can you give us a restore point for your site? Is there any way that you happen to have one?” And of course, you know, at that moment we can’t help you. And so it would break our heart. And one of the things that I worked on heavily in my early days at Automattic was around the user experience of security.

This was coming from my time at Brute Protect as well, because it’s not just about hardening these things. As you said, you’re surfacing these vulnerabilities to these customers, but if they don’t understand what that means or how to take action on it, they’re gonna just let it sit there.

Oliver Sild: Yeah.

Jesse Friedman: That’s not any more powerful to them anyway. So the experience, the user experience that goes into all this stuff is highly important as well.

Just how important are automatic updates anyway?

Jesse Friedman: And I think that also leads us into why automatic updates are super important. I’d love to get your opinion on that because from my perspective, it’s not just about updating core files or plugin or theme files, which is important. You don’t want to have these outdated files for a long period of time. I think it also greases the wheels with customers. I can’t tell you how many hosting companies I’ve worked with who would tell us that their PHP versions are out of date, or WordPress is out of date across hundreds of thousands of sites.

And we’d say, well, why aren’t you updating it? It’s because we have millions of customers, so they have tied up revenue with all of these customers. You know, it’s very important to them that they keep them and they don’t churn these customers who are set-it-and-forget-it customers. They build a brochure website, it works perfectly. They don’t want to touch anything ever again, and they’re not understanding that everything’s evolving underneath them. And so they don’t log into their WP admin, they don’t go into the back end of the website and they just don’t ever want to touch it.

And then the reality is too, is something that also is a recurring theme on this podcast that we keep talking about is that if you’re running a blog or you run a hair salon or a hardware store or a bakery, you don’t want to become a web designer. It’s not your mission or passion in life to become a web designer and a web admin. All the skills that you put in place to build this website, you work through guides and you did how-tos and onboarding steps and all this other stuff. Just a few months from then, you’re not gonna remember all those things. You’re not gonna remember all those details. So when you go back into the WP admin all of a sudden and you’re told to update all these plugins, the repercussions of what those steps take could be daunting. It could be overwhelming to them.

So anyways, I’m curious what you think about that. How do you approach that in a way that’s accessible to customers? And also are you segmenting your customers? Do you think about it from the perspective of a customer who’s doing it all by themselves, who is that baker who doesn’t necessarily know how to do stuff on the web versus maybe an agency who runs enterprise-level clients and actually deeply cares about this stuff. And they’re gonna look at that report every single day.

Oliver Sild: I honestly think that for simple websites, auto-updates is a must-have. But what we need to think about also is, again, let’s look into the data. In how many cases are auto-updates even available? Last year there was almost 8,000 new security vulnerabilities that we helped uncover and basically the new vulnerabilities that were published, over 30% of them did not receive an update at all from the vendor.

So now there is a question like, what should this web admin do? They have a website that has a security vulnerability and 30% of those cases, they have nothing other to do than delete the plugin or basically find an alternative or just stay vulnerable, right?

So because of those reasons, and actually when we even now talk to enterprise customers as well, this is where auto-updates is not feasible at all. There are many, many cases like CI/CD workflows that you need to run everything through, like software development lifecycle, you know. Updating the plugins to new versions takes even more time there than it actually takes for someone who just runs a simple blog.

So for that reason, we actually decided that we are going in a completely different direction where we’re just starting to…

What is Patch Stack’s approach to virtual patching?

Oliver Sild: We needed to find a… because our mission as a company is to provide the fastest mitigation to vulnerabilities, and then the only way for us to do that is to completely bypass the software development lifecycle. We need to be able to mitigate the vulnerabilities without touching any of the code and affecting any of the performance, but basically eliminating that vulnerability on the site at the same moment when the vulnerability is being discovered. And that’s what we do with our virtual patching engine and how we are… I think we have 11,000 virtual patches available to date, which is by far the largest collection of vulnerability-specific security rules in the entire WordPress ecosystem, right?

So we can deploy them on demand to websites that have specific vulnerabilities and we can also pull them off when the website is not vulnerable anymore and has updated to the fixed version. And I have a funny story about that because Patch Stack is part of Google for Startups alumni program. So we were invited into cybersecurity and AI program that was hosted by Google. And we were in one of their AI programs and they were saying how they were using the Gemini models to basically patch security vulnerabilities in code. So they were trying to figure out how can they use AI to basically patch code.

In the end, they realized that this is not a viable solution because the AI is basically like, “Oh, this is a vulnerability.” And then they realized that the solution for AI to fix the vulnerabilities was to comment out code and actually break the functionality. So on paper there’s no vulnerability anymore, but it’s not usable anymore.

And then we asked them like, “What problem are you actually solving?” Because ultimately developers can also release the patches. The problem is that nobody’s deploying those patches on time, and it takes too much time to deploy patches through software development lifecycle and things like that.

And when we look into the statistics again, where vulnerability is getting disclosed and it takes two hours to weaponize it, you are already exposed. So I think we need to have something faster than just auto-updates or relying on auto-updates, which would not cover 100% of the time. And we need to have something that mitigates it before that, and just do it faster. That’s kind of my take on it.

Jesse Friedman: Yeah, that’s an interesting perspective, especially since a lot of power of WordPress comes from the fact that plugins and themes are extendable.

Oliver Sild: Yeah.

Jesse Friedman: Core is extendable by plugins and themes, but you have these accessible by anybody. A single developer can write a plugin and then solve a problem for you, but maybe they’re not a security expert themselves.

Oliver Sild: Absolutely.

Jesse Friedman: And so, how can you expect someone like that to be able to run an update?

Oliver Sild: And now…

Jesse Friedman: And so yeah, so I think it makes a lot of sense to think about it from a more global perspective of analyzing it from the perspective of the fact that these developers may not have these skills or this knowledge. And so maybe there needs to be something that helps in core to help identify those things as well. It’s an interesting balance because you want to make customers feel comfortable installing plugins. And of course, the first time that plugin gets installed, it goes through a review process. It’s made sure it’s secure. Yeah, that’s interesting.

So what is the user experience like inside of the WP admin? Is Patch Stack a plugin? Does it run at the infrastructural level? Are they interacting with you? Are they interacting with the hosting company?

Oliver Sild: So Patch Stack is more like a SaaS product, right? So you go to patchstack.com, sign up, you get your own dashboard. You can add all your WordPress, Drupal and Joomla sites into a single dashboard. And then you use the agent to connect the website to Patch Stack. And what happens is that the agent is including the virtual patching engine and basically acts as a kind of connector to basically send information between the website and Patch Stack and that information is just including the information. What this website is based off, so we can profile it on our side and tell that, okay, now there’s this new security vulnerability that was just recently discovered in plugin X in version 1.6.2. And it happens to be that website is in that vulnerable range. So we can push from our side immediately the virtual patch and auto-deploy it. So if anyone, any hacker is trying to exploit that vulnerability, there is a specific security rule in place that is basically eliminating the exploitation possibilities.

So the plugin itself on the WordPress admin side of things is very… it’s actually hidden under settings and security. And we don’t have some sort of… you don’t even really see the presence of it there. So it’s very, very low touch. We’ve wanted it to be as lightweight as possible for websites, and we’ve even benchmarked it in a way that it has to be the most lightweight security product ever for WordPress websites, because if we work with hosting companies, we want to make sure that there is no performance impact on it whatsoever if we want to be able to provide this vulnerability management and mitigation for hosting companies at scale.

Hosting companies will have access to that panel, basically. And they will have the full overview of all the vulnerabilities across all of their sites, what virtual patches have been deployed, what kind of attacks have been prevented, and all that kind of insights. So that is their kind of experience.

Jesse Friedman: So the end user, are they required to take steps to enable this? Does it work out of the box?

Oliver Sild: Works out of the box. Yeah, so the plugin is getting installed and mostly everything is automatic from the hosting side of the integration. And then basically, yeah, the site is just connected to Patch Stack and starts receiving the virtual patches for vulnerabilities that are present on the website.

Jesse Friedman: Right. Yeah. So one of the things that we’re working on constantly with WP Cloud, which is a cloud platform built specifically for WordPress, is ensuring that every hosting company that we’re working for or working with has everything up to date and all these security holes are plugged as well.

And so what we’ll actually do is do it at a higher level, beyond that so that we are making sure that the hosting company understands that there’s a patch that needs to be made. If they don’t correct it immediately, we can actually maintain the security hardening by doing it ourselves, then rolling it out to the entire infrastructure beneath us.

And so one of the core tenets of WP Cloud is security, and there’s a variety of things that we do. There’s firewalls, DDoS, all this other stuff, but plugin management and theme management is absolutely vital and it’s one of the things that we’ve built into that entire…

How should we think about layers and WordPress security?

Oliver Sild: So I think what you’re actually bringing up is a very important topic that I actually covered at CloudFest this year as well, which is the thinking of layers, right? And especially in the WordPress ecosystem is you have network layer, you have server layer, and then you have essentially the application layer, which is the WordPress installation itself.

And then what you need to basically do on each individual layer is different. So for example, the best thing to do on the network layer is to have a DNS WAF that is basically filtering out trash traffic, reducing the load that the server is even getting in the first place. What you should do on the server layer is everything related to backups, malware scanning, stuff like that, because you don’t want to… if you read the Patch Stack annual security white paper, which we released during CloudFest, there is a problem where hackers are basically taking over WordPress websites and then the first thing that they’re targeting is actually malware scanning plugins, and then putting themselves into the whitelist of those. So you don’t want to have your malware scanner to be in the same environment where it’s compromised. So it’s defeating the purpose a little bit.

Jesse Friedman: That’s really shifty how they make themselves whitelisted instead of just disabling the plugin altogether.

Oliver Sild: Actually, this causes a lot of problems because then the customers are having false sense of security because they think that they installed a security plugin that lets them know when there’s malware. But because the malware scanner itself is compromised as well together with the website, then it’s quite bad.

And then when it comes to application security layer, what actually is the best thing to do? There is virtual patching, because for virtual patching, you cannot do virtual patching on the DNS level because you don’t have the visibility into what the application is made of. And you also don’t have visibility into the sessions, which is very, very important for virtual patching because you don’t want to basically deploy a vulnerability-specific virtual patch to a site in a way where it’s blocking off, for example, admin users. We need to deploy virtual patches in the cases where everyone else is basically getting blocked, but admins are being left… where we don’t need to trigger the virtual patch for admin users because otherwise it, for example, breaks the builder or something like that, which happened earlier last year with Bricks Builder, where basically all the known DNS WAFs and server-level WAFs all failed to protect against this remote code execution. Many, many thousands of websites got hacked. The only way that actually saw were able to prevent that vulnerability from being exploited was a virtual patch that was specifically targeting that specific function that was vulnerable, but leaving admin accounts unpatched.

And this is only possible if you do virtual patching on an application layer with hooking into basically WordPress runtime. So we need to use the right tools on the right layers, but all layers need to be covered.

Conclusion

Jesse Friedman: Yeah, that’s great point. Let’s continue this conversation. We’re at time for this episode. We’re gonna have to come back with Oliver and continue on a continued episode. Oliver, thank you so much for joining us today, but we’ll be back next week.

Oliver Sild: Thank you.

Jesse Friedman: Thanks for joining us on another episode of Impressive Hosting, where we uncover the core tenets of great WordPress hosting. Do you have a follow-up question for today’s guest, thought or comment on anything we talked about, a future guest suggestion, a hosting horror story? What do you think makes great WordPress hosting? All your comments shape the show. Drop them on impressive.host. We also appreciate you following us on social media and subscribing to the podcast on your favorite platform. Finally, do check out our list of open-source projects that need support at impressive.host. Whether it’s code, community, or cash, you can make a difference.

See you next time.