In this conversation, Josh speaks with Mikael Barbero, head of security at the Eclipse Foundation. They discuss the foundation’s role in enhancing the security posture of open source projects, the importance of Software Bill of Materials (SBOMs), and the various security services provided to projects. Mikael explains the challenges and strategies involved in implementing security best practices across a diverse range of projects, as well as the foundation’s proactive approach to navigating security regulations and compliance. This is some great security work happening for open source projects.

This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.

Episode Transcript

Josh Bressers (00:00) Today, open source security is talking to Mikael Barbero head of security at the Eclipse Foundation. I’m very excited to have Mikael here. So I saw a talk your crew gave at one of the open source security summit things about SBOMs in the Eclipse Foundation.

And I reached out to you, was like, hey, you should come talk about that. But as I did more and more research at the Eclipse Foundation, holy crap, this is an epic organization. So, Mikael, why don’t you introduce yourself, tell us a little about kind of who you are and what the Eclipse Foundation is and what you do. And I just have so many questions.

Mikael Barbero (00:35) First of all, thank you, Josh, for having me there. It’s really a great honor to be there and talking with you. So as you said, I’m head of security at the Eclipse Foundation. So I lead the security team at the foundation. And our main mission is to help our projects to improve the security posture of their supply chain. But maybe before we dive into that, I can introduce you to a bit the Eclipse Foundation for those who don’t know us or think that we are the foundation of the Eclipse IDE.

Josh Bressers (01:00) Yes.

Mikael Barbero (01:04) because that’s what we hear very often. ⁓

Josh Bressers (01:06) Yes. Well, and that’s what I knew you

as, but as I started, you have over 400 projects now. Like, it’s wild.

Mikael Barbero (01:11) Exactly,

420 and the ID is maybe between 40 and 60. I don’t have the exact count, but if you count the main project and the various plugins, it’s 40 to 60 projects. And the rest are other things. And we have projects like Adoptium, free open source distribution of OpenJDK, Java distribution. We have projects in the automotive world. We have IoT projects, so Eclipse Mosquito.

a very well-known MQTT server that are used by many tinkerers at home. So it’s also an Eclipse project and many others. ⁓ So yeah, we have all those projects, but very widely diverse in various languages. And what we do for them is to provide services for them to thrive. So we have ⁓ internal IT team to provide them with ⁓ services. So we used to offer ⁓ Git hosting or CVS hosting.

That was in the early days when there was nothing available. Yeah, I know, we’re old, But nowadays, of course, they use GitHub, but we provide additional services on top of GitHub so that we can actually enforce the second service that we provide is ⁓ actual governance for the project. So one of our main services is to ensure that the project are venture neutral, open, and transparent.

Josh Bressers (02:12) man.

Mikael Barbero (02:37) So by that we actually have rules and ⁓ we ensure that ⁓ nobody can ⁓ come and ⁓ take over a project ⁓ or that the election of committers of people who actually have right permission to a project, it is done via public election with free motivation and not just because someone has been hired.

by the company that is mainly maintaining the project and would like to add someone new. So that’s the kind of service that we provide. So IT governance, but also some marketing to help our project do conferences, organize meet-ups. And finally, the last thing, and that’s the very origin of the foundation is the IP and legal management. So we own the trademarks of all those projects to protect them from

Josh Bressers (03:05) Right.

Mikael Barbero (03:33) ⁓ some of the nasty moves that we have seen in industry in the recent years. That cannot happen when you have a project at the foundation. ⁓ But we also ensure that there is an IP duty agency, a license compliance check if you want for our projects. So that’s what we’ve been doing for the last two decades. And because that was the concerns of industry, right? Nobody wanted to get sued because they were incorporating GPL code into their…

Josh Bressers (03:37) Yes.

Mikael Barbero (04:02) their products. But for the last four or five years now, the concerns have shifted a bit and it has been moved to security, of course. And the threat of being attacked by the supply chain ⁓ has been a big concern. So that’s why we’ve created this team at the foundation.

Josh Bressers (04:21) Well, I want to point out, I’m going to put a link in the show notes, but you have a page for the security team where I think you’re doing something I’ve never seen another foundation do, where you’re explaining when a project joins the Eclipse Foundation, there’s a bunch of security services you provide to the project where you help them with vulnerabilities, you help them understand what’s going on security-wise in their project, you help them with SBOMs, this is the one I hope we’ll get to.

soon. There’s so much to talk about. that’s so cool, right? That’s not, that is something I feel like all of the security nerds probably just assumed everyone knows, but like no one probably knows this. So I think writing this down is incredibly cool.

Mikael Barbero (04:50) Sorry, I’m out.

Thank you. So yeah, we promote and encourage our projects and help our project adopt best practices specifically on supply chain security because there’s been a big focus. So everything on SBOM, mitigating supply chain attack, mitigating threats like the threat models that is detailed by the SLSA project at the OpenSSF. That’s definitely what we do for our projects. But of course we need to do that at scale because we are founded in

20 plus projects, so we cannot go after each other and have them individually. sometimes we do point to point help, but we need to tool ourselves to define our processes so that we can scale for projects. And for that, we don’t have much choice than everything that we do is to actually empower our projects. So the very first thing that we’ve been focusing on the first couple of years is to help our project to secure their GitHub configuration.

Josh Bressers (05:37) Yes.

Mikael Barbero (06:06) the settings of their GitHub organization and repositories. So enabling branch protection, of course, enabling two-factor authentication, that was a given for that, ensuring that the CI, CD tokens, the GitHub tokens have restricted permission by default and so on. So all the good stuff that you can get from OpenSSF Scorecard and other projects to assess your repositories, we’ve developed tools so that we can ensure that all of our projects are configured.

the right way. So that’s one thing that we do. as you mentioned, we don’t only do supply chain security, we also help our project understand how to do vulnerability management or how to handle vulnerability reports from security researchers. So on that side, we basically act as facilitators between security researchers that speak specific language and open source.

individuals that speak another language and we try to make them understand each other and ensure that everybody is on the same page regarding the deadlines or ensure that the project understands that the security researcher will want to publish that within a given time frame, the report or the publication and ensure that there is actually follow-up. that’s also one of our main missions.

to help our project understand what is coordinated vulnerability disclosure and do that the good way.

Josh Bressers (07:39) Which is really hard to do. I know a lot of people take that for granted sometimes just because when you work with certain organizations it feels easy or like they have it all figured out, but it is so much work. And especially from your perspective, if you have 400 projects, you probably have way more than 400 open source developers and trying to make them understand what’s going on is really hard sometimes. Like really hard. I know exactly, man.

Mikael Barbero (08:01) colors.

Josh Bressers (08:09) Just thinking about that again, like brings back, I used to do this when I was at Red Hat. And I would say 80 % of the time it’s not too bad, but man, that 20%, like, holy cow, it goes south fast sometimes. But also I guess at the same time, projects you’re working with understand who you are, they understand what you’re doing. So it’s not like you’re just some rando showing up one day in an inbox. It’s like, hey, guess what? I’ve got a bunch of security vulnerabilities for you, which is pretty cool.

Mikael Barbero (08:33) Yeah, totally.

It really helps to be from the foundation so that they understand that it’s really for them that we are here. And of course, we have many projects that are already very mature on that and that they don’t need much help from us. They know how to do that the good way. But for the newer ones or the smaller ones, definitely they require our help.

Josh Bressers (09:00) Yeah. Okay. So you mentioned you have tools, for example, I’ll just use the GitHub repos in this context. When you say tools, do you mean like actual, like technology, like automation, or are you talking about just like, here’s a document I need you to read developer of this project.

Mikael Barbero (09:18) So it’s both. But for the GitHub part specifically, we actually developed a project called Otterdog So it’s a little pen on the octocat, the sea otter is the predator of octopus and cat and dogs. I’m rambling. ⁓ So this is a tool that…

Josh Bressers (09:19) Okay.

guys.

I love it. That’s great.

Mikael Barbero (09:47) helps project to maintain and configure the GitHub organization as code. So you can think of it a bit as a Terraform ⁓ configuration, Terraform module for GitHub, and there are actually Terraform support for GitHub. But we had very specific needs where we want to have good default that we control and that cannot be overridden. And we want to also give the flexibility to the project for some settings.

where they obviously have to tweak that and configure the whole thing in their own way. So that’s why we actually developed this tool on our own. And that’s, course, an open source project at the Eclipse Foundation, and anybody is open to use it.

Josh Bressers (10:31) Okay, cool, that makes sense. Yeah, I mean, that’s one of the challenges, right? Is a lot of the security things we talk about are not run the script and you’re done. It’s often humans need to be involved and there’s ongoing maintenance and you have to do it over and over and over again, because goodness knows you might set up your Git repo correctly and then someone does a thing and now it’s all broken, you know?

Mikael Barbero (10:54) Yeah. And so that’s what the tool actually provide us. We have some kind of dashboard for us, for the security team, so that we can monitor on a continuous basis the security configuration of all of our organization at GitHub. So we have 250 organizations, ⁓ 4,000 repositories or whatever. ⁓ And yeah, to check if branch protection is enabled on all the important repositories is critical.

Josh Bressers (11:00) Nice.

even imagine. ⁓ thinking about it, I see GitHub rate limiting me in my mind. That’s like the story of my life usually when I do things with GitHub. So wow.

Mikael Barbero (11:25) So that.

Yeah, we had these kind of issues, but ⁓ I’m lucky to have ⁓ tremendous and wonderful people on the team that have been developing those tools and those best practices and they’ve been doing great. just to mention them as well, because that’s super important. The work that we’ve initiated for the last couple of years, we got help from and sponsorship from the Alpha Omega project, OpenSSF project.

Josh Bressers (11:45) That’s cool.

Mikael Barbero (12:02) that helped us bootstrap all those initiatives and to hire the first couple of people so that we can start this work. So, ⁓ very grateful for their support.

Josh Bressers (12:11) Awesome. Yeah, yeah, they’re a great team. The goal was to turn money into security and they seem to be pulling it off. it’s very cool. Okay. All right. So let’s, man, I want to just kind of talk about SBOMs for a little while because I feel like that’s the thing I reach out for. That’s the thing I absolutely love. so kind of tell us about this, cause I’m not going to do it justice. It’s the, we’ll say, I’ll set you up is the Eclipse Foundation.

Mikael Barbero (12:19) Exactly.

Josh Bressers (12:40) is publishing SBOMs for, I’ll say all your projects and we’ll put that in air quotes, because we know it’s not everything yet, you know, that takes time. Will you tell me, is it everything now? Okay, okay. Just checking. But yeah, and this is, assume the CRA is one of the driving forces behind this effort. So I will just stop talking and you take it from here, Mikael.

Mikael Barbero (12:50) No, no, that’s the vision.

Yeah, for sure. So the SBOM initiative, it’s not about us generating SBOM, it’s helping our project to generate those. Because of course we could use generic tools to generate SBOM or just take the SBOM from the GitHub repositories that are available for free when you use dependabot and so on, but they usually are not very accurate regarding…

Josh Bressers (13:16) Yes.

Mikael Barbero (13:35) they’re not as accurate as the one that you can get, for instance, from build time ⁓ tools. So what we’ve done, and that’s a bit ⁓ the opposite of what we’ve done with Otterdog is we don’t have any much tools on that, but we have a lot of practices and ⁓ ready to use or ready to customize workflows, for instance, for projects to help them start generating as well. So we are there to help and we promote those initiatives. And of course, we ⁓ improve.

our playbooks with time and with the new ecosystem that we take over because we have Maven, have Maven Java, we have NPM, we have Python, have Go and others and some are easier than others, of course. So currently we have, I think about 20 or 25 projects that are generating SBOM for each of their releases. So, and that’s what we really target because our initial use case for SBOM.

course CRA we can discuss about that a bit later but the main request that I had from ⁓ my executive director is to be able to answer ⁓ in very short time for the when the next log4j will happen what are the project and the releases that are impacted. So that’s the main concern that we have we need this information so we want to store the historical SBOMs of all of our projects and what are their releases.

Josh Bressers (15:03) Okay, all right, let’s start with the generation piece. Because usually when someone says they need an SBOM, the answer is just, run this tool and you get an SBOM. But that’s not what you’re doing, right? You mentioned build time, because there are different stages to build an SBOM. There’s, for example, before the build, when you have source code, there’s during the build when you’re actually doing the things to make the, in your case, it’s a lot of Java. So obviously you have to compile Java. And then…

there’s post release where you might add other things and you mentioned build time. So tell us what kind of, does that mean and what does that look like?

Mikael Barbero (15:41) So we tend to promote build time as well because we feel like that’s the most accurate, the one that represents the best, what is the output of our projects at the foundation. So we have a couple of products, but we have a lot of frameworks as well that deliver libraries. So it’s really at build time where we see what it is built against and that we have the better vision about the environment where they are built on.

and where we can deliver the most accurate as well. So the tooling, we promote the usual tooling, the most common or the best tooling that we can find for each ecosystem. So for instance, Maven Java, that is a Cyclone DX Maven plugin. ⁓ Pretty straightforward on a single module project. As soon as you’re talking about multiple repos, multiple sub-modules and so on, it requires a lot of tweaking.

So that’s where we are gaining expertise and we can actually help our project to do it the right way, to have an accurate representation of their dependencies.

Josh Bressers (16:51) Sure, sure. And so you’re going to a project with basically instructions to modify their CI system to run in the case of we’ll just pick on Java, cause why not? To run the cyclone DX Java. No, it’s the Maven plugin you said you’re using, right? So the Maven plugin, install the Maven plugin. It runs during the build. It spits out an SBOM In theory, we’re all good now, but we’re not really, right?

Mikael Barbero (17:21) Yeah, because what do you do from there? You have a nice list of dependencies, but what do you do from there? that’s why we, from the beginning, we had the need of having a central registry where we can actually store those SBOM for further analysis. So we pick up dependency track for that. The OWASP open source project, we felt like it was ticking most of the boxes that we had in terms of requirements.

Josh Bressers (17:23) Well, right. Right, right.

Nice.

Mikael Barbero (17:49) So ⁓ we help also our project to push the SBOM over there so that after that Dependency Track has many features like continuous scanning of those SBOM for new vulnerabilities on some OSINT ⁓ vulnerability sources. But there is also legal ⁓ or license checks and license policy on Dependency Track that we can implement.

We are not there yet, but we eventually plan or hope that we can merge or at least ⁓ make our IP due diligence processes from 20 years ago ⁓ more in line with what we do for vulnerability management and Dependency Track seems to be a good opportunity for that, but we are still far from going there.

Josh Bressers (18:37) For sure,

for sure. mean, you got to one step at a time, right? Right. Okay. So that’s really cool sounding. And we mentioned Java, but so every ecosystem is different, right? It’s the things you’re doing for the Java people are not the things that you’re going to do for the go or Rust or pick. I mean, the eclipse on days you have every technology on the planet somewhere in the projects. So how are you approaching the.

I guess the need to differentiate between different things, because it can be a considerably different kind of skill gap, right? Where like the lessons you learn on Java don’t necessarily have a whole lot to do with Go, for example.

Mikael Barbero (19:20) Yeah, so again, shout out to the team. They are really great at learning stuff that an ecosystem that they don’t know about. So they are doing great at learning Go when you’re actually a Python developer ⁓ and others. But we can also count on our community. So the first couple of projects that we picked up, ⁓ we recently picked up a mature project in some ecosystems.

Josh Bressers (19:26) Nice.

Mikael Barbero (19:48) where we knew they would be helpful and they would be willing to work with us to learn ⁓ all of this so that we can build these playbooks ⁓ for other projects to use. So it was really relying on the skill of the team and relying on the first early adopters of those initiatives to help us build the playbooks for the SBOM Generation and all those ecosystems.

Josh Bressers (20:14) pretty cool. And obviously all of this work is in the open. So anyone who wants to look at your playbooks can go, I will, I think I have the right link. I’ll check with you later, but I’ll make sure there’s a link in the show notes for all of this. Cause I mean, this is the cool thing. Like the Eclipse Foundation publishes everything you do, which is awesome.

Mikael Barbero (20:18) course.

Yeah, we have what we call the security handbook for projects and that’s definitely available for everybody to use. again, if I may, a big shout out to the sovereign tech fund who actually invested in the Eclipse Foundation to help us boost up this initiative as well for this year in 2025. And of course we will now continue with other project, but the initial work on the registry and the first early adopters, that was an investment from the sovereign tech fund and we are very grateful for.

Josh Bressers (21:00) Yeah, that’s a great team. They’re doing amazing work. It’s phenomenal. I’m excited for the day every country has the equivalent of the sovereign tech. No, it’s the agency now, right? I think they renamed themselves.

Mikael Barbero (21:01) from the help. Yeah.

Yeah, exactly. is not the agency. The fund is still a program of the agency.

Josh Bressers (21:16) Yeah. Okay.

Of course it is. ⁓ it’s also easy to understand, but okay. So I want to ask you, Mikael when you went to projects and you’ve said you, want to make these SBOM things, did you have, like, was it agreement? Did you have some pushback or something? Cause I know like one of the challenges I’ve had is I work with the open SSF on a group called SBOM Everywhere. And I’ll, I’ll talk to an open source project and they’ll say, why do I need this?

Mikael Barbero (21:21) Yeah.

Josh Bressers (21:46) I’m like, well, you kind of don’t like it. It isn’t, it’s not for you. It’s for the next person down the step from you. And maybe you don’t, I mean, if you don’t do this, does it affect you negatively? No. You know, it’s a hard sell sometimes, right?

Mikael Barbero (22:06) Yeah, but we have a very good seller with the CRA coming always. So we…

Josh Bressers (22:11) That’s true. That yeah. Yeah. And you’re a European

organization, right? Which this is like, you are in the middle of it.

Mikael Barbero (22:16) Exactly.

Yeah, and we are very active regarding all those ⁓ public policies and forthcoming security regulations. So ⁓ may not be the topic for today, but we have a working group actually working with policymakers at the European Commission to discuss CRA and what can be done ⁓ with stewart by stewart for SMEs and for the open source community. But so yeah, the CRA has some requirements for stewart. So we will have to…

to have basically a security policy in place and promote the usage of this security policy. But we feel like we also have the duty or the opportunity for us to help our project reach a level where downstream users, ⁓ the industry can depend on Eclipse Foundation projects and have some kind of assurance. ⁓ How it will be done is still to be defined, but the…

some kind of assurance that the CRA compliance will be easier with project coming from the Eclipse Foundation than coming from a random GitHub repository.

Josh Bressers (23:28) Yeah, yeah, for sure. And I want to also shout out for anyone listening that does not know this. When the first versions of the CRA were being drafted, they were just completely ridiculous in terms of like the expectations from open source. The Eclipse Foundation is one of the organizations that really stepped up and put a ton of effort into helping work with the policymakers and the lawmakers and everyone involved to make them understand what’s going on. And now we have, we’ll say something that I think is doable.

I’m not going to say it’s perfect and the devil’s going to be in the details, but the CRA feels reasonable now as opposed to how kind of how it started where it would have probably killed open source.

Mikael Barbero (24:07) yeah, for

sure. sure. Mike Milinkovich the executive director of the foundation, published a couple of blog posts after the one from an NLnet and of course other organizations that understood that the CRA could be very damaging for the open source communities and the industry at large actually, because of course the industry relies on open source.

Josh Bressers (24:26) Yeah. Yeah.

Right, right, are you using open source? The answer is yes. Yes, you are.

Mikael Barbero (24:33) Yes, of course. So

that’s how we sell basically the SBOM. Again, one of the requirements from the CRA is that at release time, you need to release something without known exploitable vulnerability. So you will need to have some kind of dependency analysis and validation that those dependencies don’t have ⁓ known exploitable vulnerabilities.

So that’s one thing that we can provide once they are on boarded on this initiative. So that’s what we tell them. And the other point is that, yeah, for the next Log4Shell you probably want to know whether one of your supported version is impacted and you need to act on them.

Josh Bressers (25:21) Yeah, that’s a huge one. And I think that’s one of the examples I love to use for SBOMs is when Log4Shell happened, I suspect you and your team had a rough probably couple of days or maybe weeks, because you had to look through all of the Java everything you’ve ever released ever to find Log4j, which was of course in everything.

Mikael Barbero (25:41) Yeah.

So the team didn’t exist at that time, yeah. But yeah, that’s one of the main motivation for creating the team.

Josh Bressers (25:46) Oh really? Holy cow! Wow. Wow!

Wow,

so someone had a bad day, but it wasn’t you.

Mikael Barbero (25:57) I was part of the guys who had a bad day, but there was no formal security team at the foundation.

Josh Bressers (26:00) Wow.

Wow. That’s amazing. mean, I’m really, sad, but I’m also really impressed that you still accomplished everything you did and took care of it all with no team. Wow. Wow. But I mean, to give everyone an example, like I was in the middle of this mess as well. And what happened, like I worked for a company called Anchore We have customers that were saying, how do we find this crap? You know, they, they, have a product that does things similar to, to, you know, vulnerability tracker.

not vulnerability tracker, what’s, crap, what’s the name of dependency track? That’s it. ⁓ Similar, right? And there was a race, right, with all these companies saying, have to figure out where Log4j is in all of my infrastructure, and not even just your infrastructure, like anything I ever had, because this was a thing that existed for a decade. And anyone who had SBOMs of all their stuff, it took them literally five minutes.

Mikael Barbero (26:33) That’s about it.

Josh Bressers (26:58) and they knew where it was. The people who didn’t have SBOMs and had to scan and dig, it was, I remember I talked to someone who worked for a large company and it was one of those, we think in about a month we’ll know all the stuff we have to look at. I’m like, whoa, what? Like, ⁓ and they said like, literally, this is going to take us a year to get through our stuff. And I’m just like, I can’t even, I don’t even have say to that, but you know, mean.

It sounds so easy now, because I feel like we have this tooling and knowledge we didn’t have. But yeah, like now with dependency track, if Log4Shell happens again, it’s going to take you what? 30 seconds for the query to run. And you’re going to know exactly what you’ve got and where it is, which is cool, right?

Mikael Barbero (27:43) Yeah. And then we can take it even a step further because the Dependency Track has this tooling, but many other tools have as well to be able to express the VEX statement on those vulnerabilities. So it’s an opportunity as well for our project to be able to maintain more versions, more major version maybe, because they will be able to declare that, OK, I have this vulnerability or this vulnerability is declared on one of my components, but I’m not impacted because XYZ.

Josh Bressers (27:57) Yes.

Yes.

Mikael Barbero (28:14) So that’s

also a big plus for having SBOM is to be able to describe whether you are impacted by your vulnerability or not on previous versions.

Josh Bressers (28:23) That’s right. And what Mikhail just said is VEX, V-E-X, which is vulnerability exchange, which is a standard to, we’ll say include additional information along with your vulnerability scans about like affected, not affected, things like that. like Log4j is a good example where you were only affected if you were parsing, you know, externally generated log data. So if you were just logging like, you know, static lines or something like that, you couldn’t be exploited. So that’s an example of

We don’t have to worry about this. And what happens is when you’re in an organization, like let’s say the Eclipse Foundation, where you have 400 odd projects, you’re going to say, what are the things most affected by this problem? That’s where we’re going to put at the top of the list. And the things that aren’t exploitable, it doesn’t mean you’re not going to fix it. It just means you’ll fix it last. Because 400 projects is a lot of freaking projects if you have to do something on this scale.

Mikael Barbero (29:18) Yeah, thank you for the precision. Sometimes those acronyms, we use that too often every day and we forget that we need to elaborate on that.

Josh Bressers (29:20) Yeah.

No, I know, I know.

I know. Yes, yes. Yeah, it comes up all the time. It’s it is amusing to me that when I talk to a new security person, they just start rattling off, you VEX and CVE and CVSS and whatever. they’re like, I have no idea what you just said. It’s like, sorry. Let me start at the beginning. And then and then as you go and you explain, you feel like you’re a crazy person explaining something because some of this stuff is just like, why did we do it that way? That doesn’t make any sense. But whatever.

It is what it is. All right, all right, Mikael I don’t want to take up too much of your time. I think we’re coming to the end here. And I will certainly have you back to talk about more of the work you’re doing, because this is like amazing work. And the things you’re doing is just industry changing, which I absolutely love. But I’m going to give you the floor at the end. why don’t you, what do you want everyone to know about the Eclipse Foundation or what you’re doing or help you might need or what anyone could do? It’s like, take us home. It’s up to you.

Mikael Barbero (30:24) Thank you. And I appreciate it really, our conversation. Well, basically we want really to be the foundation for secure development of open source projects. So we want to really be the role model if you want, in terms of implementing all those best practices that come from security oriented foundations like OpenSSF, OWASP and others. They are really driving the…

the work, ⁓ leading the work in terms of developing new practices, threat modeling and so on. And we want to be the whole model in implementing those ⁓ practices. So if you have a project or want to be CRA ready and looking for stewart, you’re more than welcome to join us to become a member of the foundation or to propose a project. We will definitely be happy to have you and to help you improve your.

your security posture and I hope you enjoy your security journey.

Josh Bressers (31:24) Amazing. And I just want to add for anyone listening, when Mikael says about being the implementers, it’s a lot harder to implement this guidance than it is to make it. Because a lot of times this guidance is not coming from practitioners, so sometimes it’s not practical or reasonable. So I applaud you for all of that work. And I know you feed your feedback, like the things you learned, back into these efforts, which is awesome, because that’s exactly what’s needed.

I mean, holy cow, thank you for all the work. know, thank you and the whole Eclipse Foundation. Like you people are making such a huge difference. I love it so much.

Mikael Barbero (32:01) Thank you, appreciate it.

Josh Bressers (32:02) All right, Mikael, it has been a treat. cannot wait to have you back. Thank you so much.

Mikael Barbero (32:08) Thank you, Josh. Have a good day.