Download the Free eBook: Built to Last: Understanding the European Cyber Resilience Act (CRA)

What’s in the SOSS? Podcast #71 – S3E23 Navigating the New Era: The EU Cyber Resilience Act Explained with Madalin Neag

Summary

In this episode of What’s in the SOSS, host Sally Cooper is joined by Madalin Neag, EU Policy Advisor at the OpenSSF, to demystify the European Union’s Cyber Resilience Act (CRA). As the tech industry shifts from treating open source as a free buffet to navigating a new era of regulatory liability, Madalin explains how the CRA establishes a horizontal cybersecurity baseline for digital products. The conversation explores the innovative concept of “open source software stewards,” the importance of moving beyond passive consumption to active upstream contribution, and why compliance should be viewed as an outcome of good engineering rather than a separate checkbox exercise. Whether you are a manufacturer of smart devices or a volunteer maintainer, this episode provides essential insights into how the CRA will reshape the global software supply chain, encouraging a secure-by-design mindset that strengthens the entire digital ecosystem.

This episode is part 4 of a four-part series on the CRA:

1. CRA Readiness: Practical Strategies for Open Source Communities with Megan Knight

2. Watering the Community Garden: Navigating the EU CRA for Open Source with Roman Zhukov

3. Private Forks, CRA Deadlines, and the True Cost of Open Source Compliance with Dave Russo

Conversation Highlights

00:23 – Introductions and Madalin’s role at OpenSSF
03:42 – What is the Cyber Resilience Act (CRA)?
05:27 – The CRA in the global regulatory landscape
09:05 – Relevance to open source and the “Software Steward” concept
13:02 – Moving from passive consumption to upstream contribution
16:20 – Practical steps for organizational readiness
20:26 – Should open source maintainers be worried?
24:12 – Insights from the Linux Foundation CRA Readiness Report
31:32 – What to watch for in the coming year
34:07 – Rapid fire round and concluding thoughts

Transcript

Intro Music & Promo Clip (00:00)
“If you’re maintaining an open source project in your spare time, publishing it under a free and open source license, and you’re not placing a product on the EU market in the course of commercial activity, then in almost all cases, you should not be worried about the CRA. Contributors remain contributors and the legal responsibility cannot simply be pushed upstream to the people writing code”

Sally (00:23)
Hello, hello, and welcome to What’s in the SOSS, the OpenSSF podcast, where we get to talk to developers, program managers, architects, engineers, policy experts, and all contributing community members for this amazing ecosystem we lovingly refer to as open source. We are sitting today in the middle of OpenSSF’s dedicated CRA quarter.

Meaning, we’re focusing our policy teams, resources, and community outreach on navigating a massive legislative transition. And this episode fits perfectly into that mission because today we’re joined by Madalin Neag, the EU policy advisor at the OpenSSF. Welcome, Madalin. Thank you so much for being here.

Madalin Neag (01:10)
Thank you very much Sally for having me. It’s a true pleasure to be here in this podcast finally.

Sally (01:17)
Finally, right? yeah, well tell our listeners a little bit about yourself, your role, and how you bridge the EU cyber policy and open source here at OpenSSF.

Madalin Neag (01:27)
Well, I’m privileged to be the EU policy advisor at OpenSSF, as you said, and I’m working at the intersection of cybersecurity, open source software and European technology policy. My purpose is to help connect open source technical committees and policymakers supporting the development of practical regulatory frameworks, aligning technical realities with evolving EU legislation and strengthening open source securities role in policy discussions.

I serve as a member of the European Commission Cyber Resilience Act expert group and as a delegate of European standards organizations, where I contribute to discussions, shaping the implementation and standards landscape of the theory. More recently, I’ve also been grateful to join multi-stakeholder platform, INISA’s ad hoc working group on security architecture engineering and vulnerability management, as well as the CyberStand EU Strategy Board.

All those activities and several others are reflected in my contributions to the OpenSSF Global Server Policy Working Group, my main playground within OpenSSF, helping coordinate global policy perspectives across our open source ecosystem.

Sally (02:39)
Love that Madalin, thank you so much. Yes, you do a lot for the community. And just before we get into the details on what we’re talking about, let’s think about this at a high level. For years, the tech industry has been really treating open source like a free all-you-can-eat buffet. And the scale of this is massive. Recent reports show 90% of companies use open source. I’ve even seen higher stats than that. 84% of commercial code bases contain at least one note.

Open source vulnerability. Massive corporations take this code, they put it into commercial products, and sometimes the creators might think that they need to guarantee its security. So the rules around this are evolving. The European Union recently passed the Cyber Resilience Act.

And it represents this shift in liability. So, Madalin, to set the stage for our listeners, what is the Cyber Resilience Act and what is the problem that it’s trying to solve?

Madalin Neag (03:42)
Well, I hope everyone that listened to us is aware about what Cyber Resilience Act or CRA is. But nevertheless, at a high level, the Cyber Resilience Act is the European Union’s new horizontal cybersecurity regulation for products with digital elements. It applies directly across all EU member states, and it’s intended to improve the functioning of the EU’s internal market by creating

a common baseline for cybersecurity requirements across those. The regulation is trying to address a challenge we have all experienced. Digital products are everywhere, yet many still reach the market without adequate cybersecurity or with inconsistent security updates or vulnerabilities that place the burden on users and organizations to manage the risk.

The CRA comes into this landscape and tries to change that by making cybersecurity a requirement throughout a product’s lifecycle. It expects manufacturers to consider security from the design and development phase, to manage vulnerabilities, to provide security updates, and maintain their products for an appropriate period after they are placed on the market. Ultimately, the goal is twofold.

to raise the overall level of cybersecurity across the European market, while also giving consumers and businesses greater confidence that the digital products they buy meet the required level of security. Of course, once you move from that high-level objective to implementation, questions quickly arise around open-source software, supply chains, standards, and how these obligations apply in practice.

Sally (05:27)
Well said, Madalin, that clears things up a lot. So where does the CRA fit within the broader European or global cybersecurity regulatory landscape?

Madalin Neag (05:36)
Well, if we go back to EU cybersecurity strategy published in 2020, the vision was to strengthen Europe’s cyber resilience by combining legislation, standards, certification, operational cooperation and investment. As the foundation, have Cybersecurity Act, which strengthen a NISA and establish the European Cybersecurity Certification Framework. By the way, that’s under revision. We then saw the adoption of NIS2.

to raise the level of cybersecurity across essential and important entities. And we have also so-called critical entities resilience or CER, which focuses on the physical and operational resilience of critical infrastructure. And those are cybersecurity focused policies. Additionally, we have policies or pieces of legislation that only include cybersecurity provisions.

like Artificial Intelligence Act, Machine Regulation or Data Act. There is another one that is quite particular called DORA, which introduced a comprehensive operational resilience framework for the financial sector.

CRA complements all of those by focusing on the security of products with digital elements. Rather than regulating organizations or critical sectors, it establishes, as I said, cybersecurity requirements for the products themselves, requiring manufacturers to build security into hardware and software throughout their lifecycle. It’s important to mention also that

Cyber Resilience Act replaces the cybersecurity requirements introduced through RED Delegated Act, RED Standing for Radio Equipment Directive. Instead of having cybersecurity requirements attached only to certain categories of connected radio equipment, the CRA creates a much broader and more coherent horizontal framework that applies across most hardware and software products placed on the market.

I also think that CRA should be viewed within the broader context of the use technology sovereignty agenda. So while the organizations often experience the CRA as compliance obligation, I think its significance is much broader than compliance. It represents a shift in how we think about software and digital products. Cybersecurity is no longer treated just as an optional feature or something addressed after the product is released. Instead, it becomes

an essential product characteristic that must be considered from design and development to vulnerability management and long-term maintenance. And because software supply chains are global, I personally expect the CRA’s influence to extend well beyond Europe. Much as GDPR-shaped privacy practices internationally, the CRA is already encouraging manufacturers around the world to adopt more mature and secure software development practices.

Sally (08:39)
Wow, Madalin, that’s such a good point. And globally keeping people safe and specifically your comparison to what happened with the GDPR and how that took into account globally. Wow. And then open source. I mean, open source has been deeply involved throughout the CRA discussions. What, in your opinion, makes this regulation particularly relevant to open source projects and communities?

Madalin Neag (09:05)
Well, open source became such an important part of the CRA discussions because everyone realized that modern software simply wouldn’t exist without it. You mentioned before that a lot of reports are already highlighting that more than 90 % of the software on the market are already containing pieces of open source software.

So practically almost every commercial product today relies on open source components somewhere in its software supply chain. So if you’re creating cybersecurity requirements for digital products, you inevitably have to consider how those requirements interact with the open source development. One of the biggest concerns during the legislative process was ensuring that the CRA strengthens cybersecurity without

unintentionally placing legal obligations on individual developers who simply write or contribute to open source software. We have to take into account that CRE eats regulation about products with digital elements that are placed on the UMARC.

Simply publishing free and open source software is generally not considering or not considered placing a product on the market. The most recent guidance coming from European Commission also makes it clear that contributing code to an open source project doesn’t by itself create responsibility under CRA. Contributors remain contributors. Responsibility generally lies with the entity that publishes and controls

releases and governance, and even when the applicable obligations depend on whether that software is actually placed on the market in the course of the commercial activity. This is where maybe from my perspective, one of the most innovative concepts is appearing in the picture, the so-called open source software steward.

The theory recognizes that there are organizations such as foundations or other legal entities that systematically support the development and long-term sustainability of open-source software that is intended to be used commercially.

The guidance that I mentioned previously also provides another important clarification. Open source software stewards are determined on a project by project basis. The same legal entity could be an open source software steward for one project while acting as a manufacturer for another if it is commercially placed on the EU market.

As I said, from my perspective, the open source software steward is one of the series most innovative concepts. It acknowledges that the open source ecosystem heads in its own governance and recognizes the important role that foundations and similar organizations play in maintaining the security and long-term viability of software that in the end benefits the entire digital ecosystem.

I also think that it demonstrates that meaningful dialogue between policymakers and open source community can produce regulation that both strengthens cybersecurity and respects the collaborative nature of open source development. For me, one of the key lessons from the CRA is that good regulation doesn’t come from trying to fit open source into existing legal concepts. It comes from first understanding how open source communities actually develop, maintain and govern software, and then designing proportionate rules around those realities.

Sally (12:47)
Yeah, there’s a lot to unpack here. And I think there’s another interesting angle too that you’ve talked about, which is moving beyond the passive consumption of open source. How does contributing upstream actually improve security and reduce the compliance burden?

Madalin Neag (13:02)
Well, I think this is one of the most important mindset shifts we are seeing. For many years, organizations viewed open source primarily as something they consumed and forget about it. They downloaded components, integrated them into products and moved on. Today, that model is becoming increasingly difficult to sustain. And now we have evidence to support that. One of the most recent Linux Foundation Research reports dedicated to open source return of investment, found that organizations actively contributing upstream consistently report positive returns on investments with many seeing returns of two to five times their investment.

The value comes from reducing the obligated engineering effort, avoiding long lived private forks that cost a lot of money, resolving issues earlier. influencing project roadmaps and benefiting from improvements that are maintained collectively rather than by a single organization. Contributing upstream is therefore not just good citizenship. It’s good risk management and good business. And that’s particularly relevant from a CRA perspective. CRA is not only about understanding your dependencies, it’s about actively managing the risks associated with them.

Organizations that engage with upstream projects gain much better visibility into their security practices, release processes, governance, and vulnerability response that enables a more informed evidence-based decisions throughout the product lifecycle. I often say that compliance should be the outcome of good engineering, not a separate exercise. If you’re building software securely, generating trustworthy security evidence, engaging with your upstream communities and continuously managing your software supply chain, then compliance becomes a natural consequence of those practices. It’s worth emphasizing that contributing upstream doesn’t always mean writing code. It can mean improving documentation, funding security work, supporting maintainers, participating in coordinated vulnerability disclosure, improving release engineering, or helping projects adopt security best practices.

Every organization can contribute in different ways. Ultimately, I think we need to move away from passive consumption. If organizations rely on open source, and as I said, every organization does, then investing in the security and sustainability of the upstream ecosystem is really an investment in resilience of their own products and their own business. In my view, that’s where cybersecurity, compliance, and open source sustainability all come together.

Sally (15:49)
What a great view, Madalin. And I love how you’re making it accessible with lots of different ways to contribute upstream. It’s great to hear that reminder and ultimately just keeping everybody safer. So I’m thinking about, you know, what if I’m a manufacturer of, let’s say, I don’t know, I’m looking around here, a smart refrigerator sold in the EU. Where do I begin? Like what are the practical steps organizations should take today to prepare for compliance.

Madalin Neag (16:20)
The good news is that organizations don’t need to wait until 2027 to start preparing, and they certainly shouldn’t wait. My personal advice is to think of CRA Readiness as a journey rather than a compliance project. And the first step is understanding your role. Are you a manufacturer, an importer, a distributor, or perhaps an organization supporting open source? The CRA assigns…

Different obligations to different actors. So understanding your role is the foundation for everything else. Coming back to your example, if you’re a manufacturer, one of your first practical tasks is to determine how your product is classified under the CRA. Is it a standard product, an important product with digital elements under Annex 3 or critical product under Annex 4? That categorization is essential because it determines

the applicable conformity assessment procedure, the level of scrutiny, and whether a third-party assessment may be required before the product can be placed on the e-market. Next, gain visibility into your products and your software supply chain. You can’t secure what you don’t know exists. That means identifying your software components, understanding where they come from, tracking dependencies, and maintaining an accurate inventory.

typically through SBOM or due diligence reports. Both of them are part of the CRA obligations. The third step maybe is to assess your current secure development practices. Many organizations are pleasantly surprised to discover they’re already doing much of what the CRA expects. If your organization is already following frameworks like NIST,

secure software development framework, adopting practices such as threat modeling, secure coding, coordinated vulnerability disclosure, SBOM generation, provenance, or vulnerability management, you are already building many of the capability the CRA requires.

Another practical recommendation is to automate wherever possible. One of the biggest mistakes organizations can make is treating CRA compliance as a documentation exercise. Manual evidence collection simply doesn’t scale. Instead, organizations should automate the generation of security evidence as part of their development pipelines, like things like SBOMS, signed provenance, vulnerability scanning, security testing, and

machine readable security metadata. Those artifacts not only strengthen security, but also make due diligence significantly easier. coming back to the upstream, I would encourage organization to look there, to look upstream. Understand the open source projects your products depend on. Engage with their communities and contribute where you can. Stronger upstream ecosystems lead to stronger downstream products.

and that investment pays dividends in both security and long-term maintenance. Finally, don’t approach the Syrian isolation. We have already seen that, looking only at you, we have such broad cybersecurity landscape.

use the CRA compliance as an opportunity to mature your overall secure development lifecycle. The organizations that will be most successful are those that treat compliance as the outcome of good engineering rather than as a separate project. If security is embedded into your development process from the beginning, then demonstrating compliance becomes much more straightforward. In fact, that’s one of the key messages we have tried

in the past months to emphasize also through OpenSSF resources.

Sally (20:22)
Such an important key message, and it makes people feel better to understand where they, you know, where they can plug into this. And I’m just thinking about, you know, one of our biggest audiences at the OpenSSF are the maintainers, the maintainers who are working on open source projects, maybe in their spare time even, should they be worried about the CRA.

Madalin Neag (20:26)
The short answer is no. If you’re maintaining an open source project in your spare time, publishing it under a free and open source license, and you’re not placing a product on the EU market in the course of commercial activity, then in almost all cases, you should not be worried about the CRA. In fact, one of the key outcomes of the CRA discussions was ensuring that individual developers and volunteer maintainers would not accidentally become subject to obligations.

It’s also important to remember that contributing code to an open source project doesn’t make someone responsible under the CRA. The commission’s guidance and regulation recognize the collaborative nature of the open source development. Contributors remain contributors and the legal responsibility cannot simply be pushed upstream to the people writing code in their spare time. For example, publishing a security MD file, documenting how vulnerabilities are reporting, maintaining clear release nodes, having a support policy, generating an SBOM where appropriate, or adopting an OpenSSF project security baseline are all examples of good engineering and transparency practices. Contributors and upstream developers should follow those on voluntary basis because such signals help downstream organizations understand what they are consuming. And they do not transfer legal responsibility to the maintainer to upstream. That said, don’t think this… I do think this is an opportunity for maintainers because many of the same practices that improve security also make projects easier to adopt and trust. That’s a distinction I think is incredibly important.

We should never confuse voluntary transparency with regulatory compliance. If a maintainer chooses to publish information about their project security practices, they’re helping users make informed decisions, not certifying that the software is CRA compliant or accepting liability for how others use it. So my advice to maintainers is therefore quite simple. Don’t panic and don’t feel pressured into becoming a compliance expert.

Continue building great open source software. And if you can adopt modern security practices because they improve the quality and sustainability of your project. Ultimately, I think the CRA sends a positive message to the open source community. It recognizes that open source is fundamental to our digital infrastructure. It protects the collaborative development model that has made open source so successful and it encourages better security practices without placing disproportionate burdens on the volunteers who make that ecosystem possible.

Sally (23:35)
Love that, Madalin. I’m thinking that that makes the maintainers job a little easier and also the open source security project baseline. We’ll link that in the notes for everybody in the show notes so they can learn more. thinking about also the recently published 2026 Linux Foundation and OpenSSF research. I have that in front of me here. And

There’s some fairly sobering findings around CRA readiness in the open source ecosystem. What surprised you about the results?

Madalin Neag (24:12)
What surprised me most was actually the awareness gap. Around two thirds of the organizations surveyed either weren’t familiar with the CRA or didn’t know whether it applied to them. And, yeah, given the broad scope of the CRA, that’s a significant finding.

This is why I think awareness and education are so important. I see this as a shared responsibility. The European Commission provides the legal framework and implementation guidance and ESA supports and creates complementary resources for helping with the implementation. And after that, we have European standardization organizations that are developing the harmonized standards that will provide practical ways to demonstrate compliance. Communities like OpenSSF help translate those requirements into

actionable guidance, tools and training for developers and organizations. So go read them. Take inspiration from those. Understand them. If anything needs to be updated, let us know. My advice to companies is simple and especially in the light of the results of this report. Don’t wait until the deadline to understand what CRA is.

Start by understanding whether the CRA applies to your products, identify your role in the value chain, and take advantage of the resources that are already available. There is a growing ecosystem of guidance, and organizations don’t have to navigate this journey alone.

Sally (25:39)
Love that, Madalin. And ~ you already touched upon what OpenSSF is doing to help organizations and open source communities navigate this transition with, you know, some of the initiatives, working groups, tools, training. Are there any upcoming activities people should know about?

Madalin Neag (25:55)
Well, I would say that we are a quite active community. We have the so-called working group global cyber policy that I mentioned before, which has two special interest groups, one dedicated to awareness and one dedicated to standardization. Just a few minutes ago, we had the CRI tech talk where we talked about Launchpad SIG progress. Launchpad SIG is another important special interest group sitting somewhere

at the border between working group global cyber policy and orbit working group, connecting regulatory landscape to the tools. We have a lot of resources and materials that are already published and they can be verified, they can be read and those are living materials. you feel, if you see any problem with those, do not hesitate to submit comments.

and feedback and I promise that we’ll take those into account. Additionally, our community is very active across the globe by participating into events. And I will highlight only the upcoming OpenSSF Community Day in Prague, where we will talk about CRA, but also the main OSS event in Prague that will follow in the next days and there

We will have also workshop dedicated to CRA and how working group global cyber policy can help you with that one. So summarizing, please join our meetings. You can come and see and understand better how CRA and other pieces of legislations are applying to you, what we have already done in this direction, how we can support you.

And please do not hesitate to bring with you your questions, your concerns. We are here to help through all those means that I mentioned before.

Sally (28:02)
Right, so anyone can join the global cyber policy working group and the other awareness and launchpad SIG that you mentioned are some areas they can learn more about. Also, our OpenSSF Community Day and the Open Source Summit coming up here in October. So we’ll link that down below. Thinking back, because you’ve been at a lot of events and you’re recently in Brussels for a packed week, including the EU Security forum that OpenSSF hosted. What were your biggest takeaways and what are the follow-up actions from some of those discussions?

Madalin Neag (28:39)
That was a great event and I’ll start by thanking very much to the speakers, but also to the people that attended that event. I should say upfront that the discussions were held under the Chatham House rule, so I won’t comment on who said what, but I can certainly share the main themes and my own takeaways. What stood out most was the strong consensus that cybersecurity and open source are no longer separate conversations.

they are becoming deeply interconnected to the CRA and broader EU regulatory landscape. A recurring message was that security has to be built in by design, not added later. That means investing in upstream open source projects, improving collaboration between manufacturers, maintainers, regulators, and standards bodies, and making software supply chains more transparent. Given that

the vast majority of software dependencies are indirect, organizations need much better visibility into the components they rely on. Another clear takeaway was that compliance shouldn’t be viewed as checkbox exercise, what I mentioned before as well. The series is just one piece of much broader regulatory landscape alongside other initiatives affecting cybersecurity, digital products, and why not AI.

Organizations need a holistic strategy that combines regulatory compliance with secure development practices and robust supply chain management. Of course, AI was another major topic. There was a lot of optimism about AI’s potential to improve vulnerability detection, automate security tasks, and strengthen software assurance. For me,

The follow-up actions are quite practical. We need to help organizations better understand their responsibilities under the CRA, especially as many are still at an early stage of preparedness, as we have seen, and as you highlighted, that was present in the report. We also need to continue supporting the open-source ecosystem with better tooling, guidance, and upstream contributions, because improving the security of shared components benefits everyone. Finally, it’s important to stay engaged in the ongoing policy and regulatory discussions so that the implementations remain practical and support both innovation and cybersecurity.

Sally (31:19)
So looking ahead, we have our September deadline, a December deadline for the CRA’s implementation timeline. What do you think organizations should be paying attention to over the next year?

Madalin Neag (31:32)
I think the biggest message for organizations is that the time to prepare is now. Waiting until the deadline is likely to make compliance much more difficult. One misconception I still see is that the CRA is simply another regulatory checkbox. In reality, it’s driving a broader shift toward secure by design development, stronger software governance, and greater visibility into software components and dependencies. Organizations that approach it only as a legal or compliance exercise

will miss the opportunity to improve their overall security posture. Another area that deserves much more attention is software supply chain transparency. Most organizations rely on hundreds or even thousands of open source components, and more than 90 % of those dependencies are indirect. Understanding what’s actually in your products, how those components are maintained, and how vulnerabilities are managed is becoming a core capability rather than

are nice to have. The CRA clearly places responsibility on manufacturers for the products they place on the market, while at the same time encouraging contributions upstream to improve the security and sustainability of the open source projects everyone depends on. Finally, organizations should keep an eye on the broader regulatory picture. The CRA doesn’t exist in isolation.

It’s part of an evolving European cybersecurity and digital policy framework alongside initiatives such as NISTU, CSA, the AA Act, and future cybersecurity certification developments or future cybersecurity regulatory development. Rather than addressing each regulation separately, organizations will benefit from building

A unified governance and risk management approach that can support multiple requirements over time. Ultimately, the organizations that will be in the strongest positions a year from now won’t necessarily be those that have the highest amount of documentation. They will be the ones that have embedded security, software governance, and supply chain transparency into the way they build and maintain products every day.

Sally (33:53)
Thank you, Madalin. Okay, it’s time for a rapid fire round. These are gonna be fun questions to get to know you better, for our audience to get to know you better. Just say the first thing that comes to mind. Are you ready for the rapid, rapid fire round?

Madalin Neag (34:07)
Yes!

Sally (34:09)
Okay. What’s your very first computer or operating system?

Madalin Neag (34:15)
I don’t remember my first computer, I know it had a Pentium One CPU and as operating system it had Windows 95.

Sally (34:25)
Oh, interesting. Most overused buzzword.

Madalin Neag (34:30)
Well, especially with regards to CRA, I think ready or compliant.

Sally (34:36)
Yeah, that checks out. favorite open source mascot.

Madalin Neag (34:41)
Of course, the Honk.

Sally (34:43)
Aw, nice Honk. Okay, mild or spicy.

Madalin Neag (34:48)
Mild.

Sally (34:49)
Mmm. Best location for a conference.

Madalin Neag (34:52)
I would say Italy, wherever in Italy, just pick a city in Italy.

Sally (34:57)
Nice. I would love to go. All right. finally, if our listeners could take just one thing away from our conversation today, what would that be?

Madalin Neag (35:08)
Don’t think of the CRA only as a compliance exercise. Think of it as an opportunity to build more secure and trustworthy software. The organizations that will succeed are those that embed security into their engineering practices from the start. The very next step is simple. Take a closer look at your software supply chain, understand what components you’re using, how they are maintained, and whether your security and vulnerability management practices are ready.

Start now, because building those capabilities takes time and good security is ultimately the foundation of good compliance.

Sally (35:46)
Wonderful, what a reframe. Thank you, Madalin. And with that, I want to wish everybody a wonderful day, happy open sourcing, stay cyber safe and sound, and we’ll call it a wrap.