Compliance Meets Code: The Cyber Resilience Act Through a WordPress Lens with Oliver Sild

Robert Abela: Welcome to the Melapress Show, your trusted source for WordPress expertise. Join us every Thursday for a live Q&A exploring security, administration, and all things WordPress.

And we are live. Today we have a very interesting discussion. Before we dive into today’s talk, a quick update about our plugins: last week, we released update 5.2.2 of our WP Activity Log plugin, which now includes support for Paid Memberships Pro, in terms of logging. The plugin can keep a log of what changes users are doing when using that membership plugin. I’ve also been on one of their live shows yesterday, which was streamed live on YouTube — I’ll share some links later on my socials if you’d like to watch.

Today, we have Oliver Sild, the CEO of Patchstack. Hello Oliver, how are you?

Oliver Sild: Hello, I’m doing really well.

Robert Abela: Good to hear. I’ve known you for a few years from WordCamps, actually. You used to have a different security solution; it used to be called WebArx, right?

Oliver Sild: Yes, indeed. It was called WebArx. It’s actually still the same company, but we did quite a hard pivot at one point. We were on a path of moving into almost an all-in-one solution, which is very common in the WordPress ecosystem. And then we made a decision: we know everything about vulnerabilities; we are really good at that, let’s just stick to this and continue building on top of that. So that’s when we also changed the company to Patchstack and really started focusing on security vulnerabilities in plugins, themes, and really just trying to solve this one particular problem.

Robert Abela: Nice. In fact, before we jump into the whole Cyber Resilience Act and all these discussions, first of all, can you maybe tell our listeners a bit about your history and who you are?

Oliver Sild: Sure. I’m Oliver, I’m the CEO and co-founder of Patchstack. The company was actually founded by me and Dave, who is from the Netherlands. Back in the day, I was doing a lot of malware research: domain-based auditing, looking up hacked websites, and helping companies to do incident response. Dave, our CTO, was at that time studying cybersecurity and was an active bug bounty hunter, looking for security vulnerabilities in government websites and things like that. We kind of combined the two worlds: from my side, the website security angle, where I saw a big issue, and then we built this community of ethical hackers who we work with to find new vulnerabilities, introducing the bug-bounty mentality into the company as well.

Today, by combining those two things, we are the largest vulnerability intelligence provider in the WordPress ecosystem. I was just checking: 73% of all known security vulnerabilities found this year in the WordPress ecosystem were actually originally coordinated and published by Patchstack. So if you’ve seen vulnerabilities being detected on your website, there’s a 70%+ likelihood that it’s actually work from our side: finding those issues, making them public, helping the developers to fix them. Our main core business is working with many hosting companies, digital agencies, and MSPs. When we identify security vulnerabilities, we’ve built software called Rapid Mitigate, which automatically mitigates those vulnerabilities. We have coverage of about 13,000 vulnerability-specific security rules that we can dynamically deploy on websites, making sure vulnerabilities are eliminated before hackers take advantage of them.

Robert Abela: Nice, very interesting. So basically, three out of four vulnerabilities are coming through you one way or another. For those who are not familiar with Patchstack, you also have the MVDP program, the Managed Vulnerability Disclosure Program, and this is one of the reasons why so many of those vulnerabilities come through you. I think over 1,000 plugins already in the WordPress ecosystem use Patchstack, right?

Oliver Sild: Yeah, 1,029 plugins, including some of the biggest ones like Elementor and so forth, are using Patchstack to essentially coordinate vulnerability disclosures. So if you find a vulnerability in Elementor, Elementor asks whoever found the vulnerability to report it through the Patchstack system. We help them validate it, make sure the vulnerability is getting patched properly, and communicate with the security researcher who reported it. All this information goes through Patchstack, which allows us to notify customers about security vulnerabilities before anyone else on the market. And if you know about the vulnerability first, you can also protect customers against those vulnerabilities.

Robert Abela: Good. In fact, we use you as well, and I’ve worked before with some of your team. For those who are not familiar, it’s very handy because most developers usually have a basic security understanding, but they might not have a solid understanding of what certain vulnerabilities are or how to exploit them. So in our case, if someone finds an issue in our plugins, they report it to Patchstack, and Patchstack verifies it (we don’t have to verify it ourselves). They even helped us reproduce the issue, we send the fix to Patchstack, sometimes they come back and say there’s still an issue, we get it fixed, and it’s all handled by Patchstack. On top of that, as you said, you also have a sort of virtual patching: it can be used as a traditional firewall that sits in front of your website, so if there are issues, they are not exploited.

Before we dive into the Cyber Resilience Act, from your perspective at Patchstack, what are the most significant security challenges facing WordPress websites nowadays?

Oliver Sild: I don’t know if you’ve seen our recent study, but something that has always come up is: “we’re already using Cloudflare, we’re fine, right?” You can replace Cloudflare with whatever firewall, Mod Security, Fail2Ban, all these things. A month or two ago, we actually decided to put that to the test: to see how much protection websites have when sitting behind Cloudflare and similar tools.

We signed up to about 20 different web hosting companies, looking at different hosts that use different security stacks: some using Cloudflare, some using Immunify, and all these different products. What we did was build a deliberately vulnerable WordPress website where we installed plugins with vulnerable versions that had already been mass-exploited: very critical vulnerabilities that had been through the media. Everyone knew about them. We signed up for regular web hosting plans, installed WordPress on them, and specifically targeted those vulnerabilities ourselves. Just to see how the default security solutions that hosting companies provide for customers stand against those kinds of vulnerabilities.

What we realized is that 88% of those attacks went straight through, and we were able to take over the websites. Which means the security promises and security solutions currently on the market are very generic. Cloudflare, for example, is very good at covering the network level. There are server-side solutions to notify you about malware attacks, or they’ve patched the PHP engine and things like that. But when we look at how websites are actually taken over, it’s all happening on the application level.

What I see as a problem in the industry right now is that all the web hosting companies are trying to protect WordPress websites, but they’re applying security on the wrong layers. I’m not saying security shouldn’t be applied there; it still should be, but there is a blind spot on the application layer. We released a white paper together with Sucuri at the beginning of this year, and what they reported back is that they basically saw half a million websites hacked last year alone. When we look at how those websites are being hacked, essentially, half of them are getting hacked due to compromised admin accounts: through session hijacking, poor passwords, lack of multi-factor authentication. And then pretty much the second half is plugin vulnerabilities.

Robert Abela: And if you look at some plugins, yours and the big ones, we have 5 million plus installs. As soon as you release a security update, all those websites are in the spotlight.

Oliver Sild: If you think about it, it’s still all an application issue, right? WordPress core itself could have two-factor authentication. It doesn’t. I wish it would. But because of that, if all the people using WordPress would use two-factor authentication, like what Melapress is offering, you couldn’t actually do a big part of those attacks. What I’ve always said is that actually covering WordPress security is quite easy. You need to make sure you don’t have vulnerabilities that can be exploited, so you have proper vulnerability management. You make sure your privileged accounts are secure, which means you have multi-factor authentication enabled. And then just don’t reuse your passwords. That’s pretty much a big chunk of what you can already do.

Something we really need to figure out in the ecosystem is that over the past 20 years of WordPress ‘ existence, we’ve really tried to solve security by asking “where can we hit as many flies at the same time as possible” without really focusing on where the security threats actually are, or how websites are actually taken over. We apply very generic solutions in front of it, and we can see that it just really hasn’t solved anything. So now we need to take a different strategy and really start focusing on the application.

Robert Abela: Good. Yeah, I agree 100% with you. Keeping your WordPress website secure is not that difficult. As you said, if you keep accounts secure, don’t share passwords, use user roles, and keep your software up to date, you’re pretty much there, quite frankly. This is not just common to WordPress: I used to be a systems engineer in the early 2000s, and we used Microsoft IIS. Most of the time when websites got hacked, it was because they were running outdated versions. Patch management has been a problem since the early days, not just in WordPress. But in WordPress, you have the added factor that a lot of people don’t have the technical expertise to maintain a website.

So, talking about vulnerabilities, and this brings us mainly to today’s discussion, the Cyber Resilience Act. You spoke about it at WordCamp Europe. For those who are new and have never heard of it, what is this law? Can you explain it first in plain terms?

Oliver Sild: Sure. I’ve been talking about this a lot and quite ahead of time. The Cyber Resilience Act is a new law that was actually passed last year, at the end of last year, to be accurate. The easiest way to think of it is that it’s like GDPR in terms of seriousness, but it applies to software security. GDPR was focusing on personal data security. The Cyber Resilience Act is focusing on software security.

For example, if you’re a WordPress plugin developer and you want to make your plugin available in the European Union, it is then considered a digital product, and that means you need to comply with the Cyber Resilience Act and apply a specific level of security to that software.

For example, I’m taking a very close example from what we’ve seen in the industry. For years, plugin updates have been bundled. If there’s a security fix in a plugin, it’s often bundled together with a long list of other changes, and at the end, there’s “by the way, there’s also a security fix.” Some people don’t even mention it. All of this is going to be very illegal.

The Cyber Resilience Act says that all security updates need to be separate from functional updates. It’s also going to be mandatory for everyone who fixes a vulnerability to notify all users immediately, be completely transparent about fixing a vulnerability, and report that information to the European vulnerability database. This is actually quite literally why we built the MVDP for the WordPress ecosystem, and Patchstack was actually somewhat funded by the European government to build that platform.

You also need to have an SBOM (Software Bill of Materials). It’s like a cake recipe. You’re selling a cake, and your cake has a list of ingredients. Software now needs to have the same thing. If you’re making software available to the market, you need to have a list of the open-source components and libraries it’s made of.

Overall, depending on the class of your software, there’s a default class one and a class two for more critical infrastructure software. Patchstack, for example, falls in the highest class because we’re providing security, so we’ll need independent auditors to go over our compliance. For the lowest class, like a WordPress plugin doing forums or whatever, they would most likely just do their own self-assessment. But something to take into account is that it is going to change the ecosystem quite a lot, because the majority of plugins, especially those with any commercial element, are basically seen by the European government as manufacturers, and need to comply with all of those requirements.

Robert Abela: This is definitely a lot to break down. Let’s start with: because you said any software available or in use in the EU, is it premium software only, or also free? If I have a 100% free plugin with no premium version, should I still be compliant?

Oliver Sild: The way the Cyber Resilience Act differentiates is between organizations as manufacturers and stewards. If you read through the Act, one of the first things it says is “excluding open source software.” But then, when you read through it, you see: if the software is open source but the maintainer is a commercial entity, then it’s already a manufacturer. So, for example, if I have a free plugin owned by the company that I make available for free, but my company is a web agency, regardless of whether the plugin makes money, it’s already a manufacturer because the organization on top of it is commercial.

Something interesting also happens with WordPress itself. Is WordPress.org a manufacturer or a steward? Right now, it looks like WordPress Foundation is the steward for WordPress core. Stewards have a lighter compliance scheme, but they still need to comply.

If it’s just your personal project, on your name as an individual contributor to purely open source software (FOSS, free and open source software), and you don’t have full control over that software, then it’s considered fully open source, and you don’t need to comply. But when we talk about the WordPress ecosystem, how many of those cases actually exist? The majority of popular plugins are all commercial products.

And the thing with Cyber Resilience is that it doesn’t matter whether you’re actually making money. Even if you’re collecting data with that free product for any kind of commercial purpose, running ads on it, collecting metrics, if it’s free software but you’re collecting metadata to use for business purposes, it’s already considered commercial activity.

Robert Abela: You also mentioned WordPress.org and the Foundation. So what is the repo or the Foundation’s responsibility? Should they make sure that plugins in the repository adhere to these rules, and if not, kick them out? What is their role exactly?

Oliver Sild: What we see with npm and similar repositories is that they’ve already said all security-related discussions need to happen directly with the vendors. WordPress has been trying to take a different route, where they’re saying they have some level of control over the plugins in the repository. 

But I honestly don’t think that’s a good idea, because that would make them a shared maintainer for all this software, which comes with shared responsibility. I think ultimately WordPress.org should probably go in the same direction as other repositories, unless there’s a supply chain attack where a plugin has been changed to a malicious one, that is the repository’s responsibility to keep itself clean. But if there is a security vulnerability in a plugin, that is the responsibility of the vendor maintaining that software. All security reporting information should go directly to that vendor.

Quite frankly, the repository shouldn’t even have visibility into vulnerability information because they are a third party in that case. Imagine if software sitting in GitHub had a security vulnerability, you would report it to the vendor, not to GitHub.

Robert Abela: I think it would be easier for WordPress to just stay out of it. But there is definitely work that WordPress.org needs to do, because, for plugin developers to be compliant, they would need to release security fixes separately from functional releases. WordPress.org currently has no way to flag updates as security updates.

Oliver Sild: Exactly. And also, what we’ve done with Patchstack and with various vendors, such as yourself, is bring in a “report vulnerability here” link into the plugin’s metadata, into the readme file. 

So if you go to WordPress.org, there is a place where you can find where to report vulnerabilities. But this actually should be part of the WordPress.org UI itself; it should be mandatory for every plugin to have a link to their VDP, and it should be right there as a button in the .org interface.

It isn’t right now. And there also isn’t the ability to release security fixes separately from functional ones. You can do it manually: you can say “this is a security fix”, but I think pushing vendors in the right direction is something WordPress.org should probably do, because we don’t have a lot of time left until these regulations kick in.

Robert Abela: One of the other requirements is that security updates should be security updates and nothing else. A few years ago, when a vulnerability was made public, it used to take weeks, maybe sometimes months, until it was mass-exploited. 

Just two or three years ago, we were talking about days. Nowadays, we’re talking about hours. As soon as a big plugin, some have millions of installations, announces a vulnerability, all the websites using that plugin are a target. 

You need at least a few hours or a day to test things. How will this whole requirement impact things? Because now the law actually requires plugin developers to notify all users immediately when fixing a vulnerability. And we don’t have direct access to our free users: WordPress.org does via the dashboard, but as a plugin vendor, you just release an update.

Oliver Sild: You’re raising a very interesting problem. A lot of vendors through WordPress.org don’t have a direct way of contacting their users at all, which is a problem on its own. That means vendors need to at least add this information to their website, and have to tell customers, “please keep an eye out for security update information through our blog.” Vendors themselves at least need to tell users upfront that they need to follow their blog or newsletter. But it is going to be the vendor’s responsibility to immediately notify their users about vulnerabilities.

And here’s the problematic thing: if you’re fixing a vulnerability, someone can look in the commit log at when you did it, then go to your website, and if they don’t see any notification that you fixed the vulnerability, they could sue you because you’re not following the Cyber Resilience Act regulation. That’s why I have a big concern with CRA: it is so fully confirmer-visible whether you are compliant or not. It’s definitely going to be a big challenge.

In fact, just about a month ago, Mandiant, the threat intelligence company under Google, released a study of how fast vulnerabilities are getting exploited. It’s been dropping from about a month to two weeks, and so forth. The most recent data for 2025 was minus one day, which is crazy. That means we’re already so behind the curve that there’s almost no point in hiding this information anymore.

This is something we’ve discussed in relation to how AI is changing the ecosystem as well. In the past, if a new vulnerability was found in a plugin, you needed at least some technical skills to take the diff of the fixed version, look into where the vulnerability was fixed, what the vulnerability was, and then write an exploit script. The ones who could weaponize quickly were more skilled hackers, so the volume of attacks was somewhat lower.

Now we’re in a situation where you can fully monitor the entire repo for all changes, run them through AI, and say, “whenever you identify a sanitization check being added into the diff, send me a notification, then tell me where the sanitization check was done and what kind of vulnerability it could have been.” And then AI just builds you an exploit script. The time to weaponization is now almost completely removed.

At Patchstack, we already get notifications immediately when plugins add sanitization checks and so forth; we see it anyway, and so do hackers. Their goal is to exploit it as fast as possible before anyone has had time to update. So, actually, if the vendor is not letting their customers know immediately, the only ones benefiting are the hackers, because they can exploit more websites while users are still unaware there was a security fix.

Robert Abela: When you say customers, most plugins have the same model: a free plugin completely for free, and then a premium. Are we referring to premium users only, or also free? The difference is that with premium users, you have their email and direct contact. The free users are always a big problem.

Oliver Sild: It doesn’t matter. It applies to all. If you’re making software available to European citizens, you need to comply. If your software is commercial by nature, meaning it has a premium version, the software itself needs to comply, regardless of whether users are paying or not.

In terms of the free edition, as long as once the law is in place, you put a banner in the plugin saying “make sure you keep up to date with us, we have an RSS feed here, check our blog”,  and you have a blog feed where you release changelogs, you’re covering part of the issue. The compliance happens on the software level, not on the individual license level. The software itself and how it’s maintained need to be compliant, regardless of whether someone got the license for free or paid for it. Even if you have a completely free plugin owned by a commercial entity, you, as an organization, are considered a manufacturer of software.

Robert Abela: And one of the other requirements was reporting vulnerabilities to ENISA, the EU vulnerability center, without undue delay. Does this apply to newly discovered vulnerabilities or actively exploited ones? You know how the process works: someone reports a vulnerability through the MVDP, there’s no public advisory yet, and you want to fix it. At what stage should you be in touch with ENISA?

Oliver Sild: I do feel ENISA is trying to step into the CVE kind of world. I know that when there were budget cuts for CISA in the US, which manages the whole CVE program, ENISA was getting to a point of “we need to have a replacement for the CVE program because we can’t be sure this global infrastructure is reliable.” 

From how it’s been communicated to us, essentially, whenever a software vulnerability is being fixed, the moment when you’re notifying your users, that information needs to immediately also go to ENISA. So, it should be basically the same process: you notify your users and immediately notify ENISA as well.

Robert Abela: I see another requirement: you should provide security updates for the expected product lifetime or at least five years. If you look at our plugins or most plugins, you release an update, and usually around 50% have the latest version. The rest are still using earlier versions. In WordPress, there’s no “PHP-style” end of life. Should we be doing the same for every WordPress plugin version, or as long as you release the latest version with the latest fixes, are you covering everyone?

Oliver Sild: I personally think that introducing end-of-life to the WordPress ecosystem would actually be a very healthy thing. Especially taking into account, I don’t know if you remember last October, we organized a big cleanup event during Cybersecurity Awareness Month. We looked into plugins with very low installation counts that hadn’t been updated for a long time, started looking for vulnerabilities in those plugins, and tried to reach the vendors. I think we closed down over 1,000 plugins in a single month. And that’s only as much as we had time to do. I think there is a huge amount of plugins that have actually been abandoned, but there isn’t even a way for developers to say, “I’m not working on this project anymore, this is end of life.”

There needs to be some level of responsibility if developers abandon software without letting the customers know. The unified installation count of those abandoned plugins we helped close down was in the hundreds of thousands of websites still running them. And if you go into the WordPress admin interface, looking at all your installed plugins, it just shows you everything is up to date, but the plugin may have been removed from the repository for security reasons, and the WordPress core doesn’t even show you that.

Robert Abela: That makes sense, and I agree: if a plugin isn’t updated within a year or whatever, something should prompt the developer, and there should be some sort of system. But what about actively developed plugins? A real-life example: our plugin is version 5.2.2. Less than two years ago, it was version three. If there’s a security issue right now, should we release a patch for 5.2.2 and also one for version three, like WordPress core does, or do we just keep building the latest version?

Oliver Sild: I think it really depends on backwards compatibility. If there’s no separate migration needed to move from one major version to another, then I don’t think you need to maintain separate security fixes for every single version. But there’s a possibility that the European Union doesn’t care about that nuance and would just enforce everyone to do it. We were expecting to receive the specific guidelines from the European government around December, which should clarify exactly what the expectations are.

There is a scenario where, if you have a vulnerability affecting versions 3.1.1 through 3.1.7, you’d need to release a security-only fix on top of each of those: “3.1.1/security-fix”, “3.1.2/security-fix”, and so on. That would be an infrastructural nightmare in the WordPress ecosystem.

The logic behind having separate security fixes per version is that people could just click “security fix” and get automatically protected; it could actually help WordPress have very good automatic security updates without breaking anything. So you could have WordPress core offer the option where all software updates are manual, but security updates are automatic. That would be possible if, for every version, you release security fixes separately. But it would require quite a heavy lift from all plugin vendors.

Robert Abela: It is a bit of a problem; we don’t have that release cadence. But it seems like the market is heading in that direction anyway. I know plugins with a release cadence of every two weeks. Without wanting to remain relevant in the market, you kind of have to. So everyone is pushing each other.

Your personal opinion: Why do you think such a law was needed? In software, not just WordPress, we already had processes in place. The idea of a vulnerability disclosure program and responsible disclosure has been around since the mid-90s or earlier. There was HackerOne and all these programs. There were never official laws, but vendors took care of these things. Do you think these laws were needed to standardize the process?

Oliver Sild: I think we kind of answered that at the beginning of our discussion: why half a million WordPress websites are getting hacked 20 years after we’ve had security solutions of all kinds applied at the hosting level. We’re still in a situation where the number of hacking incidents is going up, and there’s so much malware being used for criminal activity. And when we look at the entry point of all those attacks, it’s the application layer.

The big problem is that the web right now is the wild west, where you never know what the standards are for a software developer who has released a product. Anyone can, and I’m actually even concerned about this whole “vibe coding” thing, because who is going to take responsibility for all the code generated that way? There are going to be people using AI to generate code with no idea what they’re doing, getting this responsibility put on themselves.

But I think ultimately it’s great. It’s bringing standards into software security: everyone needs to have some basic security processes in place when making software publicly available. Right now, we’ve seen products released to the market as “best, most secure software,” and then you look into the code, and you’re just… shocked. The problem is that the users of that software have no capability of looking at the code and realizing whether the promises are completely made up.

I think it’s going to make the web a lot more secure. When we think about having an SBOM, if you go to a shop and buy food, imagine nobody would tell you what it’s made of. Software is just the ecosystem getting more mature. Big parts of the products we consume today are digital products. We just need to make sure this digital element gets secured. Otherwise, we’re going to get scammed and hacked left and right, and nobody’s going to take responsibility. And if nobody takes responsibility, there’s no reason to improve. In the end, end users are just going to be the ones paying.

Robert Abela: I agree 100%. Nowadays, it’s still the wild west. There are some programs and stuff, but there’s no real clarity. So just to recap: what do plugin vendors and developers need to do? They need a VDP – a Vulnerability Disclosure Program, right?

Oliver Sild: Yes, you don’t have to use a managed one, but as I can attest from your experience using Patchstack, using a managed solution is really helpful,  much easier, and much less work. It also depends on whether you have security people on your team.

The big problem is that with AI, the amount of fake security reports being sent to people is insane. We call it “beg bounty,” begging for a bounty. If you have a website, someone has probably sent you an email: “hey, I found a security vulnerability in your website, will you pay me a bounty into my PayPal and I’ll tell you what it is?” And usually what these turn out to be is SPF records missing, DMARC configuration issues, missing security headers, that kind of thing.

What the Managed VDP helps with is filtering all of this out. If there’s a high load of those noise reports, and you’re not a security expert yourself, you will ultimately start dismissing the real ones that actually matter. That’s the whole goal of the MVDP: to simplify that process. 

As a security company, we have the biggest experience in the WordPress ecosystem of triaging security vulnerabilities. We’re actually already the biggest CNA in the world in terms of vulnerabilities coordinated. We’ve built systems that allow us to validate vulnerabilities really fast and very accurately.

If you don’t want to build that capability in-house, using a managed solution is quite good. But if you don’t want to use a managed one and you have a security team internally, you can create a security.txt file or create a very specific policy and process for how security vulnerabilities should be reported to you, how they are processed, and have that documented. That’s quite a lot of work, though.

Robert Abela: Good. So you need a VDP, you need to release dedicated security updates on their own, and you need an SBOM, a Software Bill of Materials, basically a list of all the third-party components your plugin uses. For those not familiar, most plugins use third-party components, such as JavaScript libraries. I think WordPress itself has hundreds of dependencies. I can imagine.

Oliver Sild: Yes. For example, WordPress uses React. And something that’s being discussed a lot right now is that we’ve talked about plugins, but based on current discussions in the European Commission, if I’m a digital agency and I’m selling you a website, then the website itself is a digital product. That means the website itself might also need to become compliant with CRA, which opens up a huge can of worms. 

For your website itself to be cyber resilience compliant, you need to make sure every plugin you use has an SBOM, is compliant with the Cyber Resilience Act, that WordPress core itself is compliant, and that the website is also compliant. Which means agencies need to start looking at “can we even use certain plugins?” If those plugins are not yet compliant, you cannot build a website that is compliant.

That being said, for plugin developers, becoming compliant quickly is actually an opportunity, because there are going to be plugins that agencies cannot use because they can’t build compliant websites without them.

Robert Abela: That was going to be my next question. So if I’m an agency, maybe I don’t do any custom development at all; I literally get WordPress, an off-the-shelf theme, and off-the-shelf plugins, and hand it over to someone. What is custom development nowadays, really? Is software engineering in general custom development because you’re using third-party libraries?

Oliver Sild: Yeah, majority of the code is putting different JavaScript libraries together, using something on the backend: it’s always a combination of combining multiple pieces of software, and that is already software development. And that is what WordPress is. You take the WordPress core and combine plugins. Every website is very unique in that sense. Even if you’re making custom CSS changes, this is already software. So you need to make sure it’s compliant.

Robert Abela: Do you think, looking forward two or three years, we’ll see many fewer hacked websites? Do you think this whole thing of cleaning hacked websites is only a business in the web as a whole system? Do you think that will slow down?

Oliver Sild: I hope so. I do believe what I’ve seen is that in the WordPress ecosystem, the problem of insecure websites has been monetized instead of solved. I do hope that if WordPress core becomes more secure and needs to ensure a higher level of security standards, maybe fewer accounts get hacked. 

Maybe WordPress needs to enforce stronger account controls, session controls, things like that. CRA will push them to do that. And if all the plugins want to stay on the repo or remain relevant for agencies, they need to have much more rigorous security processes in place. End users would get notified about vulnerabilities faster, and vulnerability management in general will become a complete standard in the ecosystem.

I think that would be a direction where we see a lot more secure WordPress ecosystem as a whole and a lot fewer hacked websites. I do truly hope so. But I think WordPress is a big ship to steer.

I think there’s going to be some level of panic in June. That happened with GDPR as well. But what we need to take into account is that there’s a GDPR Enforcement Tracker website where you can actually see how companies are getting fined every single day, €1.5 million, and so forth. Cyber Resilience Act has exactly the same fine structure as GDPR. The big difference is that GDPR enforcement happens when data has leaked. There had to already be a massive privacy or security failure. With the Cyber Resilience Act, European government can fine you just for not having a VDP, for not releasing a security fix separately from functional changes, or for releasing a security fix but not immediately reporting it to the EU. And you cannot hide it. It’s going to be so visible to everyone. It’s very easy for the European Union to start enforcing it very, very fast.

Robert Abela: So before we close, in terms of dates, what are we looking at? By when do you need to have a VDP?

Oliver Sild: The VDP has to be in place by June 12th of 2026. The SBOM, I think, is a bit later, but what we recommend is getting the VDP and SBOM set up first; that’s the basics for any plugin developer, and it’s also the easiest. 

After that, you need to start doing risk assessment for your software, have some level of automation in place for vulnerability scanning within your own code base, and, depending on your product, you might also need regular penetration testing. I can actually share our Cyber Resilience checklist made for WordPress,

Robert Abela: Good. A lot of food for thought. Thanks a lot, Oliver. Anything else before we sign out?

Oliver Sild: Just, don’t leave CRA to the last minute. Don’t be the one panicking in June. Be prepared, read into it. It’s going to affect the entire ecosystem; it doesn’t matter whether you’re in the States, Australia, or outside the EU. If you don’t want to block your software from being accessed in the EU, you need to become compliant. And making it more secure and following those standards is going to make everyone more secure as well.

Robert Abela: And as you said, it can also be a selling point; agencies will start looking at these things. Absolutely. Thanks a lot, Oliver.