Cyber Resilience Act and WordPress – What to expect? 🔗 **Source:** [Cyber Resilience Act and WordPress – What to expect?](https://www.youtube.com/watch?v=yExZuWScxvk) > [!note]+ Document Notes > tags: [Cyber Resilience Act, WordPress, Security] > author: [MISSING] > source: [YouTube] > reference: [https://www.youtube.com/watch?v=yExZuWScxvk] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Cyber Resilience Act and WordPress – What to expect? > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - The talk explains how the EU Cyber Resilience Act (CRA) affects WordPress. It highlights duties for plugin authors, agencies, and platforms. :contentReference[oaicite:0]{index=0} - CRA entered into force in 2024 and applies from 11 Dec 2027. Vulnerability reporting duties start in 2026. :contentReference[oaicite:1]{index=1} - Stakeholders include manufacturers and open-source software stewards. Each has specific obligations under the CRA. - Risks include fines up to 2.5% of global turnover or €15 million. The act also adds reporting timelines of 24/72 hours and 14 days. :contentReference[oaicite:3]{index=3} - Bottom line: WordPress projects must formalize vulnerability handling, SBOMs, and CE marking paths before 2026–2027. :contentReference[oaicite:4]{index=4} ## 📖 Main Content - CRA sets horizontal cybersecurity requirements for “products with digital elements.” Software, plugins, and sites fall within scope when placed on the EU market. :contentReference[oaicite:5]{index=5} - Application dates: most rules apply 11 Dec 2027; Article 14 applies 11 Sep 2026; Chapter IV applies 11 Jun 2026. :contentReference[oaicite:6]{index=6} - Article 14 requires rapid reporting of actively exploited vulnerabilities. Notify ENISA via a single platform within 24 hours, then more detail by 72 hours. :contentReference[oaicite:7]{index=7} - Essential requirements mandate vulnerability handling processes and a coordinated disclosure policy. Provide security updates, preferably separate from feature updates. :contentReference[oaicite:8]{index=8} - Technical documentation may include an SBOM; market authorities can request it. An SBOM records components and dependencies. :contentReference[oaicite:9]{index=9} - Products require CE marking and an EU declaration of conformity before placement on the market. :contentReference[oaicite:10]{index=10} - Penalties include up to 2.5% of global turnover or €15 million for serious breaches. :contentReference[oaicite:11]{index=11} - The act recognizes open-source software stewards and tailors obligations accordingly. - Uncertainties remain around steward identification for WordPress governance. Communities must decide roles and processes. (Video claim; governance details may evolve.) ### 🗒️ Notes #### ⏱️ [00:11](https://www.youtube.com/watch?v=yExZuWScxvk&t=11) Introduction and speaker context - Emphasizes long security experience and community work. - Frames CRA as significant, like GDPR, for software. #### ⏱️ [02:47](https://www.youtube.com/watch?v=yExZuWScxvk&t=167) Scope and timing - CRA regulates “products with digital elements.” - Major obligations start in 2026–2027. :contentReference[oaicite:13]{index=13} #### ⏱️ [04:53](https://www.youtube.com/watch?v=yExZuWScxvk&t=293) Commercial intent - Open source is not automatically excluded if used commercially. - EU scope applies regardless of company location. #### ⏱️ [06:57](https://www.youtube.com/watch?v=yExZuWScxvk&t=417) Roles - CRA distinguishes manufacturers and open-source stewards. - WordPress needs clarity on steward responsibilities. #### ⏱️ [08:57](https://www.youtube.com/watch?v=yExZuWScxvk&t=537) Reporting - ENISA will receive vulnerability notices via a single platform. - Tight timelines apply for alerts. :contentReference[oaicite:16]{index=16} #### ⏱️ [11:03](https://www.youtube.com/watch?v=yExZuWScxvk&t=663) Enforcement - Penalties may exceed GDPR’s practical bite due to visibility. - Fines mirror high ceilings. :contentReference[oaicite:17]{index=17} #### ⏱️ [12:56](https://www.youtube.com/watch?v=yExZuWScxvk&t=776) SBOMs and updates - Prepare SBOMs; keep private but ready for authorities. - Ship security fixes separately where feasible. :contentReference[oaicite:18]{index=18} #### ⏱️ [14:59](https://www.youtube.com/watch?v=yExZuWScxvk&t=899) Governance homework - WordPress ecosystem must adapt processes for compliance. - Stewardship and directory features need updates. #### ⏱️ [18:57](https://www.youtube.com/watch?v=yExZuWScxvk&t=1137) Directory improvements - Suggests certification or labeling for compliant plugins. - Automate vulnerability reporting paths. #### ⏱️ [20:49](https://www.youtube.com/watch?v=yExZuWScxvk&t=1249) Agency impact - Agencies shipping sites become manufacturers for that product. - All included components must be compliant. ## 📚 References - [Regulation (EU) 2024/2847 — Cyber Resilience Act (Official Journal)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402847) — authoritative text. - [Council of the EU press release on CRA approval](https://www.consilium.europa.eu/en/press/press-releases/2024/10/29/cybersecurity-council-approves-cyber-resilience-act/) — political timeline context. - [ENISA: ENISA and the CRA](https://www.enisa.europa.eu/topics/cybersecurity-policy/cyber-resilience-act) — ENISA role overview. - [Mishcon de Reya: CRA and open-source software stewards](https://www.mishcon.com/news/cyber-resilience-act-what-does-it-mean-for-open-source) — steward obligations summary. - [YouTube: Cyber Resilience Act and WordPress – What to expect?](https://www.youtube.com/watch?v=yExZuWScxvk) — primary talk. ## 🗣️ Paraphrase - The CRA brings mandatory security duties to software shipped in Europe. WordPress plugins and sites fall in scope when marketed. - Teams must implement reporting, disclosure policies, SBOM readiness, and CE marking pathways before enforcement begins. ## 📰 Newsletter - The CRA countdown is on for WordPress builders. - Start with a security updates policy, a disclosure inbox, and SBOM generation. - Explore ENISA guidance and read the Official Journal text. - The WPCC community can prototype templates for disclosure, advisories, and CE documentation. - Useful reads: CRA Official Journal, ENISA CRA page, and steward guidance above. ## ✅ Action Items - DevRel - Publish a “CRA for WordPress” explainer with diagrams and checklists. - Run office hours on SBOMs, disclosure, and CE basics. - Demo a plugin security-update workflow separate from feature releases. - Developer advocacy: plans, talks, demos, and measurable outcomes. - Track adoption of disclosure emails and SECURITY.md across top plugins. - Target: 100 repos add SECURITY.md and contact within two quarters. - Education: workshops, curricula, office hours, mentorship programs. - Build a short course: “CRA Essentials for Plugin Authors.” - Include hands-on reporting drills and mock ENISA submissions. - Developer experience: docs, SDKs, examples, templates, quickstarts. - Ship templates for SECURITY.md, advisories, SBOM README, and update notes. - Provide CI examples for generating SBOMs. - Developer marketing: campaigns, content, funnels, and attribution. - Launch “Secure by Default” campaign tied to CRA milestones. - Measure conversions to compliant update flows. - Community management: moderation, code of conduct ops, surveys. - Survey maintainers about disclosure pain points. - Create a responder guild for coordinated vulnerability disclosure. - Internal/external/cross-project: align goals, SLAs, and feedback loops. - Establish a shared CRA working group across hosts, agencies, and maintainers. - OSPO - Policy & Governance: contribution policies, decision rights, charters. - Draft a steward policy template compatible with CRA governance hints. - License Compliance: policies, scanning, review, and training cadence. - Integrate license scans into SBOM pipelines. - Security Management: vuln intake, embargo policy, signing, attestations. - Define the 24h/72h/14d reporting SOP and escalation tree. :contentReference[oaicite:20]{index=20} - Software Inventory: SBOM strategy, ownership, freshness SLOs. - Generate top-level SBOMs for all released builds. :contentReference[oaicite:21]{index=21} - Developer Support: training, tooling, legal guardrails, consultation hours. - Offer CE documentation clinics and advisory reviews. - Community Engagement: upstream funding, MoUs, operator agreements. - Fund shared tools for disclosure and update labeling. - Strategic Alignment: KPIs, OKRs, executive reporting, initiative roadmaps. - OKR: separate security updates available for 50 key plugins. :contentReference[oaicite:22]{index=22} - Community - Maintainers: roadmap clinics, governance templates, release hygiene. - Encourage patch-only releases with clear “security” flags. :contentReference[oaicite:23]{index=23} - Contributors: onboarding paths, “first issue” rotations, pairing sessions. - Create “CRA starter issues” for SECURITY.md and SBOM tasks. - Sponsors: transparent budgets, milestones, deliverables, impact reports. - Tie funding to measurable compliance milestones. - Ecosystem: cross-project incident drills and coordinated disclosures. - Run joint tabletop exercises simulating ENISA notifications. :contentReference[oaicite:24]{index=24} - WordPress - Core: priorities, issue triage, performance budgets, release criteria. - Add flags for security-only updates in core release tooling. :contentReference[oaicite:25]{index=25} - Core Performance: profiling plans, metrics dashboards, perf bounties. - Track update latency for security patches. - Core AI: responsible AI guardrails, evaluation sets, pilot projects. - Document model dependencies in SBOM annexes when applicable. - Core Program: coordination rituals, cross-team dependencies, retrospectives. - Add CRA check to release checklists. - Mobile: app backlog, telemetry review, offline UX improvements. - Ensure patch delivery paths on mobile builds. - Playground: browser labs, reproducible bugs, education modules. - Host CRA labs: SBOM build and update separation. - Community: meetup kits, WordCamp playbooks, speaker mentorship. - Provide a “CRA lightning talk” kit for meetups. - Training: lesson plans, learning paths, certification pilots. - Pilot a “CRA readiness” badge for maintainers. - Marketing: campaigns, narratives, social editorial calendars. - Communicate benefits: faster patches and clearer advisories. - Support: response SLAs, knowledge base gaps, escalation paths. - Publish a user-facing advisory template. - Design: UX audits, design tokens, research backlogs. - Improve admin notices for security-only updates. - Documentation: DevHub/HelpHub gaps, examples-first patterns, style guide. - Document new update labels and disclosure contact fields. - Photos: content drives, moderation guidelines, taxonomy hygiene. - Provide alt-text guidance for advisory graphics. - TV: submission guides, caption quality, content indexing. - Record short CRA primers with captions. - Polyglots: translation sprints, glossary alignment, locale coverage. - Translate security advisory templates. - Accessibility: WCAG reviews, tooling, issues heatmap, audits cadence. - Ensure notices meet 4.5:1 contrast and ARIA guidance. - Meta: .org roadmap, API reliability, contributor tools. - Add repository fields: SECURITY.md URL, disclosure email, update type. Enable user notifications for security advisories. :contentReference[oaicite:26]{index=26} - CLI: command coverage, UX docs, plugin scaffolds, smoke tests. - WP-CLI command to publish “security-only” releases. - Hosting: cross-host checklists, defaults, telemetry for reliability. - Default to automatic installation of security updates. :contentReference[oaicite:27]{index=27} - Tide: scoring transparency, false-positive review loops, plugin outreach. - Add CRA-readiness signals. - Openverse: ingestion pipelines, moderation policy, education tie-ins. - Track SBOM for pipeline dependencies. - Themes: review throughput, lints, mentoring, test matrices. - Add disclosure and update-type checks in reviews. - Plugins: review throughput, security liaisons, provenance checks. - Require contact address and CVD policy fields. :contentReference[oaicite:28]{index=28} - The WPCC - Programs: fellowship tracks, microgrants, maintainer stipends. - Fund stewards to write disclosure and SBOM guides. - Projects: governance clinics, documentation sprints, release teams. - Coordinate a cross-CMS update-label standard with allies. - Funding experiments: matched grants, milestone payouts, transparent ledgers. - Tie payouts to CRA milestones and advisory quality. - FAIR - Technical independence: local metadata, provenance, and signature checks. - Sign advisories and updates; verify signatures in CI. - Policies and covenants: funding transparency, sunset clauses, anti-capture. - Publish steward covenants aligned with CRA language. - Productized governance artifacts: charters, operator agreements, scorecards. - Release reusable CRA policy kits for OSS projects. ## 🧪 Hypotheses - Projects that separate security updates will reduce patch latency by 30%. :contentReference[oaicite:30]{index=30} - Maintaining a public CVD policy will increase researcher engagement by 25%. :contentReference[oaicite:31]{index=31} - Automated SBOM generation will cut incident triage time by 20%. :contentReference[oaicite:32]{index=32} - Repository fields for disclosure contacts will lower unreported issues by 15%. :contentReference[oaicite:33]{index=33} ### 📊 Methodology - Run pre/post measurements on update latency across selected plugins. - A/B test repos with and without SECURITY.md and contact fields. - Time incident response with and without SBOMs present. - Survey researchers on reporting friction before and after changes. ### ❓ Questions - Who serves as the open-source steward for WordPress under the CRA? - How will .org surface security-only updates to site owners? :contentReference[oaicite:35]{index=35} - What CE conformity routes fit plugins best: internal control or third-party? :contentReference[oaicite:36]{index=36} ### 🔮 Future Research - Align cross-CMS advisory schemas to reduce fragmentation. - Evaluate opt-in user notifications for security advisories in WordPress.org. ### 💡 Implications - Practice: formalize disclosure intake and security-only releases. :contentReference[oaicite:37]{index=37} - Policy: define steward roles and governance transparency. - Security: faster fixes, better incident awareness via ENISA reporting. :contentReference[oaicite:39]{index=39} - Education: create concise maintainer training on CRA requirements. - Funding: sponsor compliance tooling and shared docs via The WPCC. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid ≈ Grade 9–10 (concise sentences). - Visual learners - Present: bullets, sectioning, clear labels. - Improve: flowcharts for reporting and CE steps. - Aural learners - Present: recorded talk. - Improve: 3-minute audio recap and TTS notes. - Verbal learners - Present: definitions and timelines. - Improve: glossaries for CRA terms and acronyms. - Kinesthetic learners - Present: none. - Improve: hands-on SBOM and advisory labs. - Logical learners - Present: timelines and roles. - Improve: decision trees for conformity routes. - Social learners - Present: community Q&A and working groups. - Improve: peer review for advisories and drills. - Solitary learners - Present: link pack for self-study. - Improve: self-checklists and worksheets. - Naturalistic learners - Present: N/A. - Improve: discuss sustainability benefits of fewer incidents. ### 📊 Accessibility Assessment - Screen reader semantics - Present: clear headings. - Improve: alt text for advisory images. - Keyboard navigation - Present: standard admin patterns. - Improve: skip links in advisory pages. - Contrast and readability - Present: ensure 4.5:1 for notices. - Improve: verify line-height and spacing. - Text resizing and reflow - Present: responsive admin views. - Improve: respect prefers-reduced-motion. - Media and captions - Present: captions on videos. - Improve: downloadable transcripts. - Forms and interactions - Present: labeled inputs. - Improve: inline validation for disclosure forms. - Standards reference - Map updates to WCAG 2.2 AA criteria. ### 🌍 DEIB Assessment - Cultural breadth - Present: EU regulatory focus. - Improve: examples from multiple locales. - Inclusive language - Present: avoids jargon where possible. - Improve: add plain-language summaries. - Neurodiversity support - Present: chunked content. - Improve: icon+text labels and predictable patterns. - Representation - Present: varied roles in examples. - Improve: highlight diverse contributors. - Psychological safety - Present: encourages non-blaming disclosure. - Improve: publish escalation paths and codes of conduct. ### ✅ Logical Validity - Strong reasoning - Causal claim: separating security updates improves clarity and speed. Supported by CRA guidance to separate updates where feasible. :contentReference[oaicite:40]{index=40} - Deductive mapping: if WordPress distributes in EU, CRA applies. Based on scope of “placing on the market.” :contentReference[oaicite:41]{index=41} - Fallacies - None detected in cited regulatory claims. - Tone of voice - Practical, urgent, and community-oriented. ### 🛡️ DARVO Analysis - Deny: no denial present; acknowledges burdens and deadlines. - Attack: none; focuses on solutions over blame. - Reverse victim/offender: none; emphasizes shared responsibility. ## 🎯 Conclusion - The CRA changes how WordPress software ships and supports security. - Start now: define disclosure, generate SBOMs, separate security updates, and plan CE documentation. - Coordinate across the community and use The WPCC to fund shared compliance tooling. <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=yExZuWScxvk)* **[00:00]** [Music] So, welcome to the last run of talks. I hope that you enjoy them and to to this afternoon is going to be great. So, I hope that everyone stay in track number two. I'm Vanessa Martinez and I'm going to be your NC. And today with me is Rashi. Rashi is going to tell us more **[00:30]** about Oliver. Can you please tell them most about Oliver and yourself as well? >> Sure. Hi everyone. I'm Rashmi Nagpal. I'm a machine learning engineer at Backstack. And today I have an incredible opportunity to introduce my fantastic boss standing there who is not just my boss but a very genuine mentor as well at Bat Stack and he makes sure we have all the resources we need for our work which includes multiple rounds **[01:01]** of having espresso martinis. >> You are so lucky guys. Great. Great. Great. Cheers to espresso martinis. >> Amazing. >> And apparently he is fascinated by eels. >> Yes. [Laughter] >> And he was also the part of the Estonian government actually army you know many moons ago he was leading their cyber security team and he was been awarded a medal of honor **[01:33]** by the government of Estonia. Isn't it super dope? >> It is. Can you please give him a round of applause please? Excited. >> Okay. Amazing journey. Can you please tell us more about the talk what he's going to talk about today? Sure. So today he will talk about CRA which actually mandates organization to make the vulnerability management life cycle in their workflow. So ladies and gentlemen, please put your hand together **[02:04]** and give a big round of applause to my boss and of course to the mentor of so many cyber security professionals out there, Oliver, CEO of Fat Stack. Woohoo. Have a good time. [Applause] >> Hello. I was told not to cross this line because then my face will be there, but um apparent it already is. So hello everyone. My name is Oliver. I'm the CEO and co-founder of Patchack. Um I've basically spent my entire life on **[02:36]** working on security uh hacking and defending and you know both side of the story. Um I built a communities in Estonia uh hacker space, courting space. So very much kind of like focused on the community building and that's what we've done in patch as well. We have a community of over 2,000 ethical hackers that help us uh in securing WordPress. And that's what we've done for the past uh I think eight years already. So it's been a journey. So how many of you even know what cyber resilience act is **[03:08]** >> except for? >> Yes, except for the patch tech. Oh no, five people. So actually this is the hardest slice I've ever had to do because uh this is not the topic for 20 minutes. Um but I think it's very very important that everyone knows about this and I think people need to read more uh about this as well. So you're going to get some homework after this talk. Um so I know some people are going to hate me immediately that I say that this is like GDPR. Uh but it is kind of like for me **[03:39]** at least to be be able to like make you understand kind of like the magnitude of it. Uh so it's not just like a like a small tiny uh new law that is being passed but it was passed already. So it was passed in October 2024. Um and um it essentially regulates uh the security u of products with digital elements. And what is the product with digital elements? It is a website. Uh it is you know a plug-in. It is WordPress core. uh it is essentially everything that you **[04:09]** can offer to a customer u or anyone or make available in the European Union to users um which is in in a sense a digital product. Um the main obligations of that law start from 2027 uh with an exception of early obligations that already start um in 2020 uh6 and some of the things are for example vulnerability handling. So if you're for example a plug-in developer, how do you handle security vulnerabilities if someone finds that? All of this is going to be part of that law. Um **[04:42]** so who needs to comply? Uh I really like that if you read the cyber resilience act, one of the thing first things written there is like open source software is uh excluded, but it's not uh free and open source software uh is not excluded. And there's a separate term for that called uh stewardship uh which we can talk about a little bit later as well. So uh if you have any users in the European Union, so it doesn't matter if your company is from the states, if it's from anywhere else in the world, if you are making your product available to the **[05:14]** European market, you need to comply with the Cyber Resilience Act. Um if your product has any commercial element, let's say for example a pro version. Um but that is also the the the the wording commercial in the cyber resilience act is interesting as well because it doesn't necessarily mean that you need to make money but it also means that if you have a commercial intent with your product. Let's say even if you have like uh you're pulling data from your free product and then making you know using it for ads or anything like that it also **[05:44]** basically means that you your product is commercial um and yeah like is it maintained by a commercial or like a legal entity in general um or if it's like completely open source but it's intended for commercial activities which WordPress is. Um so this is an inception because this is a slide inside of a slide. Um I hope you like it. Um essentially this is like just a way how to kind of like understand whether you're going to um basically be affected **[06:15]** by the cyber resilience act. So if you're like uh uh completely like offering like or like contributing into free and open source software that is completely just you know like GitHub uh you know uh a project of your own uh then you're most likely not going to be in scope but as soon as you're providing uh you know any kind of commercial activity do it or you know in a very broad sense as I mentioned um or if you're directly monetizing the project you are going to uh need to comply and why I wanted to show that is because it's important because cyber resilience **[06:46]** act is essentially putting everyone into two categories which is manufacturers and open source stewards. Um and there is going to be a slight difference in terms of how they need to comply. Um so let's talk about who who the manufacturer is in the eyes of the European Union. Um so there's like a basically like a big this text from the uh from the legislations actually and this the PD means product with the digital uh elements and like so essentially anyone who is manufacturing or marketing to such s such kind of **[07:18]** products are essentially considered manufacturers. Let's take an example. So a company or an individual building WordPress plug-in that has a paid version or a free version that collects data which is commercially beneficial to the owner. So essentially if you have even if you have a free version of a plug-in but it is commercially beneficial to you then you need to comply with the cyber resilience act. Um then there is an open source uh steward. Um so for example a legal person that is you know whose purpose is to essentially **[07:48]** maintain and support um an an open source software. Um so it has to be like a legal legal entity on top of that. And the example is WordPress. uh even though we have some questions about that because we don't necessarily know who is the actual open source stewart in the WordPress ecosystem is it really the WordPress foundation at this point or not um so this is this is a question I think we need to kind of like solve as well um so what is going to you know the road map to cyber resilience act kind of like look like this is very very **[08:19]** simplified uh but essentially there is going to be phase one which is uh the deadline is for 2026 so I'm telling you we have like one year and we are all ever very very late already. Um so the first things you need to manage vulnerabilities so vulnerability handling is part of the first phase. So managing vulnerabilities so does your website have a place to report vulnerabilities to does your plug-in have a place where to report vulnerabilities to in a very clear manner. um if there is a vulnerability. Do you have processes set up so you can **[08:50]** notify the European government that there is a vulnerability? So they so European government actually created their own vulnerability database which is essentially managed by NISA. Um so you need to like report the vulnerabilities in hours to them if it's for example exploitable vulnerabilities. You need to also inform your customers. Do you actually even have a communication channel to your users which is also a problem in the open source ecosystem. if you just built like a plug-in uh do do you have actual you know uh contact to them and espec **[09:23]** uh in cloudfest from here uh there was a project that was called espinator uh uh yes big applause to this team so they were already starting to work on basically bringing guest bombs into the WordPress ecosystem um so this is something that is going to be important as well and then the the second phase is uh and this is something that I cannot put into a slide because that involves so much more uh is to essentially have a risk based approach in general security by design of your entire product **[09:54]** transparency and you know you need to have the CE mark that you maybe seen on you know physical products that are produced uh for European markets we now have to have C marks for our websites for our plugins for you know for the WordPress core everything needs to have a C mark and depending on how there's essentially different types based on how the importance of the software or like the criticality of that software. Uh and you might actually need to have a third party uh regulator to give you the C mark. Um **[10:26]** not don't care about it, no compliance. Well, this is the scary slide. This is like, you know, we're going to take all of your money slide. Uh that's how European Union makes money, by the way. So, if if you don't comply, European Union is going to make a lot of money. uh that is the essentially the story and it's very similar to how GDPR works like it's either two 2.5% of your total global you know turnover u or it's up to like 15 million your whoever whatever is higher basically so this is the fines that we are talking about there is a **[10:57]** website I don't neester do you remember what the website name was for the GDPR tracker fine tracker I think um yeah so there's there was essentially a uh there's a website that is that is tracking all of the fines that are being done in for the GDPR Uh so we're going to see a similar website I think uh tracking all of the fines that are going to be in in the CRA. Something that I want to mention GDPR is so much easier to like make a like a uh like a straight face and say I'm compliant with it. Uh and actually not being and so nobody can come and like point a finger at you and **[11:27]** like oh no you're actually not compliant. You're going to get fined. CRA is going to be very much harder to make a straight face and say that hey I'm producing I'm like providing this product to the European market and like I'm compliant and then actually you're not because it's immediately you can immediately tell if you're not compliant or if you are compliant. Um so I think it's going to be much much easier for the European Union to start actually penalizing uh you know uh for the non-compliance of uh cyber resilience act compared to the GDPR. Uh just **[11:58]** something to keep in mind. So let's give some homework uh for the ecosystem. So plug-in you know product companies, plug-in developers actually this applies to agencies as well. Uh but ultimately like what I focused here is on like plug-in developers who are basically building digital product uh which is the plug-in. Um you really need to get vulnerability management and reporting in place. Um this is also very painful for us because we as as a company you know as patch we deal with a lot of vulnerability reporting in the ecosystem. uh and it's so hard in many **[12:30]** many cases to report vulnerabilities to the plugins which have a completely no contact information available. Uh this is you know this is just eating up our time the security researchers time. This is eating up the plug-in review team's time who is doing amazing work on like just hacking do all of that. Um we need to have basically like a standardized process of like just being able to report vulnerabilities where they you know need to go. um you need to notify your users of of vulnerabilities. So this is all of the stuff that you basically need to have set already in **[13:01]** one year like you have to have that basically set to to be compliant and of course you know notify the information to any um and you know prepare your sbombs you don't need to share the soms uh with the public but you need to have the sbombs uh available if someone basically is coming to ask from that. So you need to have you know you need to prepare them and you need to have them and right now like in the WordPress ecosystem we don't even have like products to you know generate this bombs and in one one basically in one year everyone needs to have them so we really **[13:34]** like need to speed those things up and I think overall just learn read about CRA like just like it is super important that everyone reads into this because there's so much information still that is you know even for me like on this slide It's like this is like the really like the tip of the iceberg. Um and for the WordPress and for the foundation like there's some things that current in the current setup is actually not possible for the plugins to even be compliant. Uh for example, cyber resilience act is uh basically **[14:05]** asking all software vendors to release security updates completely separately from the functional updates. Right now it's not not possible to tell whether an update is actually uh you know a security update or not in the WordPress ecosystem and everyone is kind of like baking them together into a single release and then everything is you know kind of in one thing. This is going to be non-compliance. Uh you need to have separate security updates and they need to be marked as a separate security update. So WordPress.org or for example definitely needs to have some sort of **[14:36]** like a flagging where you know to basically separate regular updates from the security updates. Um and yeah plugin we need to probably ask plugins to already start adding their you know uh vulnerability uh reporting information. So WordPress you know.org on the plugins kind of like a repository. It also needs to have a place where you know potentially the the someone like a security researcher or someone could basically uh report the vulnerability to that helps plug-in developers to become compliant faster. And something that is **[15:07]** like that I mentioned is that uh cyber resilience act is putting uh we're we're basically like into two categories manufacturers and you know open source stewards. So for the foundation as well like the question now is who is going to be that steward? We need to figure that out because we don't have much time. Um so something that let's say WordPress is going to be an open source uh so if the foundation is going to be the open source steward for WordPress.org then cyber resilience act is going to have **[15:38]** guidelines for governance and the governance guidelines are actually coming from that law. So this is something that you know WordPress is not currently compliant with and this needs to be solved as well. So this is homework for the entire ecosystem to read into this. But there is work for every one of us. Um, and that's it. [Applause] >> Amazing. Oliver, you have a question. Do **[16:08]** we have time? Right. Yeah, >> we should have time. >> We should have. >> I tried to speedrun through it. So, >> perfect. Perfect. Yeah, you are the the winner. You probably guessed I was going to ask a question or it's not a question but I mean I won't talk. >> I wish it would be here actually but you know >> yeah sorry I can come up. No it's uh I mean really thank you for for this great presentation. I've been going around to a lot of people saying oh CRA is a lot worse than you think. You're the first one who's actually shown how important this is for all of the CMSs. Right now **[16:40]** speaking, I represent Typo3, Drupal and Jumla and the effort that we are doing through the open website alliance to find a a CMSwide standard for handling the uh CRA stuff and we really want WordPress to be in on this as well. So uh >> WordPress needs to be this >> really. And I just wanted to to add um uh you mentioned the GDPR versus CRA. I think one important difference is that uh GDPR was **[17:11]** uh it's the customer that pushes you to be G GDPR compliant. When it comes to the CRA, the customer isn't going to care that much, but it's going to be a cost that you have to take and that the customer isn't going to understand that you have. Uh so that's the important difference uh that we have to deal with in I guess marketing and communication. Um it's also uh you're also commercial if you do uh support services even if you >> accept donations as well. >> H >> I also accept donations. **[17:42]** >> No donations is a special thing unless you make a profit. There's yeah there's standards being worked out on how that can be handled but donations seem like something that you can actually uh still receive to some degree anyway. Um and uh uh yes uh sbombs keep them tight to your chest because we're seeing reports now about the potential of esbomb trolls that will sue you for money just because they find issues. Yeah. **[18:12]** >> It's a software bill of material. So all of your dependencies and their security status. >> Yeah. It's like uh I I liked how this was explained at CloudFest uh by the Spinator team. I love that name. Um, it's basically like if you have a cake and it's you have like ingredients of what that cake is made of. So that's that's the document. >> Perfect. Thank you so much for your talk little talk. H can we well we have do you want to make a question? Perfect. Here we have two questions. Can can she please go first because this is close to **[18:46]** there. Perfect. >> Thank you. >> Thank you for your talk. So uh we're also we're an agency in France and we're specialized also at the intersection basically between web development and compliance and you know a variety of topic related to electronic invoicing and VAT regulation digital accessibility GDPR etc. Uh so basically based on what you said like my understanding is that uh WordPress itself should have an improved process review process for their uh WordPress directory and maybe **[19:18]** certain plugins that are compliant with the new regulation should have like some sort of certification label whatever um >> it's a C mark basically like uh like you have on the even like physical products. >> Yes. But uh today I think the WordPress uh review process is like very scattered and uh and that's why one of the reasons I think there's just such a variety of vendors that interpret different legislation differently and uh goes in line with what you said. So in your opinion how would you uh improve the process the review process and is there **[19:50]** anything any actions that can done like be done in the part on the part of the community to facilitate this process and to push forward these changes in the review process for the directory. Thank you. >> I think the directory needs to take into account that like this like the cyber resilience act is going to be something that is going to affect everyone in the you know in the community. So it should be you know kind of in their benefit to essentially make it as easy as possible for everyone in the community to become compliant and that you know is important **[20:21]** to include that processes into you know the repository as well like like as I mentioned like the repository should already show the information where to report vulnerabilities to maybe even automate parts of that security process maybe also you know help uh generating gas bombs for the plugins that are in you know present on the on the repository and so forth like all these think like the more uh the distribution can basically solve uh these problems for the community, the easier it is going to get for agencies even like you uh down there because you if you are **[20:51]** basically selling a website to your customer, this is a digital product. Uh and that means that all of the plugins that you use in that website including WordPress core need to have a CE mark. You cannot even use plugins then anymore to sell it forward because otherwise your own product is going to be non-compliant. So this is going to like you know like a tree basically like go into those layers. So it's going to Yeah. And again we have one year to do that. So >> thank you. >> Perfect. We sorry **[21:21]** >> just one >> h it was the same question. Okay we have just one more question. So you are the winner. >> Can Yeah. Yes. It's because we are pretty short on time. So just a little one please. The website you were asking for was enforcementtracker.com. >> Oh, enforcementtracker.com. You can see how much people pay for GDPR fines. >> Well, one more question cuz that was very short in case someone want to ask something. No one. >> If not, I'm going to talk about eels. **[21:52]** >> Yeah. Okay. But they are going to be in their booth if someone need to talk with Oliver. So, you are more than welcome to stop by and he's going to make the last question. Perfect. um you said as a plug-in developer I have to notify my users but if the plug-in is um installed over WordPress or the the plug-in repository I don't know who my users are >> and that's your problem >> okay um I mean under like I didn't you know I didn't make the law but it is going to **[22:23]** be a problem that's what I said like you need to be have you need to have a a way how to notify the users of vulnerabilities >> do you think WordPress punct the plug-in repository could um deliver such a feature so that >> it could make your life definitely easier and I think yes WordPress you know the repositories need to take more action in that sense. Yes. >> Okay. >> Perfect. Thank you. So now please give him a round of big applauses. Thank you so much Oliver. [Music]