Can Open Source be Secure? The Open Mainframe EP 19

Hi everyone. Welcome to another episode of the open Mainframe. For those of you who are not familiar.

The open Mainframe is well, the open Mainframe video show is a once a month video show in Partnership between Tech strong group and our friends at the open Mainframe group part of the Linux Foundation where once a month we dive into topics that are relevant to the tomorrow audience and specifically to the members and people familiar with the open Mainframe group. My co-host is John murdick and he's going to introduce the open Mainframe group in first in one moment. But first I wanted to introduce you to our panel.

And then we'll jump into our topic. Leading off we have Alan Clark and and Alan welcome. Thank you.

I was going to let your car to tell it tell the audience a little bit about yourself. Well, I've been in the software industry for a long time which the gray hair shows and specifically doing open source. So I've done everything from create an open source project to be on governing boards both on some some of the major foundations including the Linux foundation and now currently on the open Mainframe project.

So I've done everything from contribute leadership to code in the in the communities. And I currently at Sue say in the office of the CTO investigating and looking at the future of Open Source and The Innovation that's happening with open source. That's fantastic.

And of course, there's a huge huge open source, Advocate and support and thank you and and all of the suits are Organization for that. next up I'd like to introduce you to Chris. Excuse me.

Having a tough time Kate Stewart. Thank you very much. Much pleased to be here I've been in the like Alan I've been around in the open source Community for several years like for a good long time now at this point and have been working in companies that have spent from IBM to Motorola to free scale.

Canonical and so forth and so have had a pretty broad spectrum of Open Source expertise. I'm here I believe because I didn't one that's one of the co-founders of the software package data exchange or spdx project which is now an international standard and it's also one of the recognized s-bomb formats for improving software transparency in the ecosystem. and the things I focus on at the Linux Foundation or how do we actually make open source more dependable, which is security safety reliability maintainability and all the other things that we really need and care about when we're using things in these types of critical situations.

Got it. All right. I think we had a little maybe Video issue there with Alan.

But let me introduce it. Well, first of all Kate, thanks, and thanks for the intro and background and it's pleasure to have you on let me introduce you to our third member. Of the panel today and that's Mark and Mark if I mispronounce it accurate.

Or how do you say it hacker? Yep. Very cool Mark if you wouldn't mind sharing a little bit about yourself.

And everybody so yeah, I'm Mark hackard. I've been working as a software engineer a broadcom for about the past 10 years and I've been spending the last five in open source working on the open Mainframe project Zoe and I've been using open source for much longer than that, and I'm a member of Zoe's technical steering committee systems Squad and and security engineering Squad. So I've got a lot of background and Automation and techniques that help Drive maintainability resiliency and security.

Actually Mark, if you wouldn't mind, you mentioned project Zoe and of course that it's not all the open Mainframe project does John I'll tell us about that but opens a project Zoe is actually a is a huge project with a lot of success and great Partners. Why don't if you wouldn't mind sharing with our audience a little bit about project Zoe. sure project project Zoe is a it's an initiative to bring sort of modern interfaces and and access patterns to the Mainframe to help build the next generation of Automation and systems engineering for the platform.

So everything we do is about trying to make it easier to access the Mainframe easier to work with the Mainframe easier to build automation for the Mainframe so that everybody can. You know keep building on this platform into the future. actually All right.

Thank you. And thanks for being here with us today Mark. Appreciate it.

And then last but certainly not least is my co-host for the open Mainframe project. I always throw a lot on his shoulders as we go through the panel thing. Yeah, John will mentioned that journal.

Oh, yeah, I gotta take notes really forget. Yeah, I'd happen for the best of us the one and only John verdict Ed for the open Mainframe project that Linux Foundation. Hey, John.

Hey Alan excited for this talk. You know, I know you've probably done a number of talks on security. So for many of our listeners you're thinking is this yet another one.

I you know in my role here at the open Mainframe project, which we are a home for the open source ecosystem around Mainframe either supporting Mainframe, exclusively, or you know other open source projects support Mainframe. It's it's a really interesting because the security topic is a real real big one here in in a little bit almost of a different way than I think other ecosystems because of the dependency on the systems. For our society to function, you know, all of our financial processing happens on a Mainframe.

Our transportation Industries backbone is on a Mainframe and so many other Healthcare government what not the joke. I tell people that is from our chairperson lends into ugia he sits back and he says John You know the cloud could go away and we'd all be inconvenience for a good while but we'd move on but if the mainframes go away Society will fall into chaos. Now.

I don't know if I would be quite that of Doomsday with it. But you know, these systems are really important and the systems Engineers that have maintained these systems for decades and decades. Security is a huge thing to them like, you know, everything just from the physical security.

Like you can't you can't get near one of these mainframes in many organizations to the access security to the data security. So it's such a huge Paramount topic and every single piece of software that touches that every single line of code is extremely scrutinized to make sure that it will function on there. So I'm really interested of the level of discourse sort of we have in this talk here because it's it's coming from a slightly different angle and I think even in compared to some other domains even a more critical angle, you know as it functions so really excited for this group.

Absolutely. So, you know Kate you said something in your introduction with struck a note with me and it was something that I wanted to bring up on the show, and I think it's a great way to lead. security for security sake is fine.

But it's really the wrong way of looking at security. Security has to be synonymous with quality. security has to be synonymous with doing things the right way making the best use of our resources and codes, right?

It really is about making the best applications we can right writing the best code we can you can't if you write insecure code. It's not good code. And I've never met a developer and Mark.

I'll challenge you. You're the you're the big developer here. No developer ever raises his hand and says, I want to write crappy code.

I take a lot of pride in writing, you know, not quality code, of course, I mean, Developers are you know this generation's? You know skilled Artisans, right? It's a tiny highly skilled.

They take a tremendous amount of pride in what they do. So it pains me especially for my friends in the security company the security side of the house who say things like not developers don't care about security. No one cares about security only security people care about security nonsense.

If we think of security as quality, if we think of security as as, you know, part of a quality code of good code, of course we care about security. now not always does you know does that does that dog always hunt and there were people who, you know come back and forth. But certainly I think that's a big part of it and quite frankly that is right in line with the Mantra of the Mainframe Community.

Right what I've heard over. I'm as old as some of you on the panel. So we've all been around a long time.

Right? But what I've heard forever is bit for bit bite for mine. It's the most reliable secure effective efficient platform ever used.

ever in computers right Security's part of it Alan go ahead. Take it from there. You want me to take it?

No, it's okay. That's why no, I'm just going I agree with you, right? Yes secure well, and you know dependability is effectively maintainability reliability safety security things are in critical infrastructure.

We need that level of dependability throughout things and quite frankly. A lot of the Mainframe systems are the ones that through the standards of effectively for making sure that we were there. Um, you know quality of service is one of these things that's very important in this space and you know and service guarantees and so forth.

So you need dependability so you can do this type of work and you know, As more and more of the infrastructure moves to open source. Having a clear line of sight of exactly what is on these systems is even more important as we're emerging forward. There's a lot of change that happens in certain underlying components and having visibility into these components as to what's there what's changed is essential for this dependability we've got Things like and that's where the whole software blue materials initiatives are coming in.

So the software build materials are all about what components are running and what are the relationships and what are their dependencies between these relationships at the at the minimum elements? There's a lot more we Consider with in this space But at the minimum it's understanding exactly what's running on the system and a lot of the Mainframe organization, you know, people flying Mainframe critical infrastructures have already got this discipline in place. Absolutely.

A great Mark before we jump into open source security which is kind of the just today I wanted. Kind of gauge your feelings as it as you know, the spokesperson for the developers here. About you know your role in the security.

kind of life cycle Sure, so, you know in addition to some locate brought up with like, you know, getting tracking visibility of what you're putting on to the platform. So, you know, we're building an open source project that has dependencies with dependencies with dependencies and we have to make sure that we're aware of everything that's going on the system. You know, you said no developer takes pride in writing insecure code, but I'd also say no developer thinks they're writing in secure code.

So in addition to visibility, you know, we also need to make sure that we have proper Tooling in place to help us inspect our code and make sure that we're actually writing these secure code that we're claiming to write. So so all of this just needs to be part part of the process of building software that's destined for a platform that that has to maintain, you know system integrity at all times. a great a great let's let's turn to open source if we can.

Um, so again, I'm of an age where we used to think that open source software was more secure than let's say commercial software because it had more sets of eyes on it. Right that was always what we were saying and and of course I think over time we've found that well, it's not as many sets of eyes looking for security things as you would think or maybe I'm wrong. Maybe there still are but some fun here with you in the sense and say that open sources commercial software these days.

Yes, it is. So I was trying to think of a good word close Source versus open source. You get better right?

I got that address in both sides, right? Yeah. Yeah, but I I don't think well the bad guys are looking to exploit anything they can but I I think in today's day and age no one could sit here and say close Source open source one is inherently more insecure than the other right.

And that's really the gist of what I was getting at. But we've also seen a tremendous influx of Open Source. It is commercial software today open source is everywhere today.

right, this is Story is a great example 98 or 99% of companies today use open source software in their code. How much open source software is found its way on in the Mainframe? Right.

So it does, you know, let's talk about maybe some of the unique security challenges that open source software on the Mainframe. presents Right projects always a great example. Mark if you want to kick it off and we can all jump in from there.

You know, I think some of the challenges that we have I guess in open source is you know fighting off a little bit that sort of impression that obscurity is security when it's not really You know, sometimes hiding your code or hiding your system can be part of a security strategy, but it shouldn't be confused for actually securing the platform. of you know everything that we do in open source today is I would say equal to or Superior than a lot of what they're doing in closed Source development because we get the benefit of everybody being able to see into our code scan into our code, you know, tell us where we may have any gaps or vulnerabilities or issues we have to address. And then we can take action on that and be held accountable for it.

And I I think you know over time that yields a better product than something that's you know. You know close, you know behind behind a private Network somewhere where you you can't actually vet the quality. Of the inspections and the analysis happening against that code base.

How much how much would you say that because I know also a lot of these Mainframe systems are internet disconnected and you sort of mentioned obscurity by security and I've I've often thought that that's also kind of one of the crutches that you see and I see this in a bunch of other industries that the code is run on systems that are disconnected from the internet. How much you've seen that here in sort of what are you all doing to kind of help say, okay, just because you're disconnecting internet doesn't mean you're not subject to attack factors. So I guess my thought on that John is Which is a different initiative, but you know, we were hearing a lot about confidential Computing today.

And if you think about what confidential Computing is about is secure and it doesn't matter whether you're on the Internet or not. It's about securing processes. from Bad players right bad administrators Teed off, you know, operations folks that work for whatever reason haven't been data, right so it could be from hackers that have broken into your system through your protections and firewalls.

So traditionally we've depended on firewalls, you know, we put up the we put up the drawbridge and the moat and everything to protect everything from the outside and then suddenly today we realize Wait, we got to protect ourselves from the inside as well. So, so to me the reason we're talking about things like confidential Computing is we recognize that it's not just Bad actors out there in the world that are trying to break in. We've got to protect the processes themselves on the machines from Bad actors internally as well.

Right so doesn't matter whether you're on the Internet or not. It's got to be secure. You know and probably the other angle even to think about is just where the code is is coming from which I know something that's where you dig into a lot of Kate is a lot of that's where the that's where the biggest areas of security, you know vectors that are unaddressed tend to be is pulling on dependencies and stuff, right?

The dependencies of the dependencies of the dependencies as things rely on other. Components that are out there and you're bringing in a wide set of dependencies. That you know, something is very deep and one of the smaller dependencies is there like there's an XKCD cartoon that we all have seen at this point in time.

I suspect that really illustrates that you know that developer in Nebraska as project is you know has to be considered we have to consider all of the aspects points, you know, it's a full dependency tree that has to be made sure that there's nothing surprising coming in when you're bringing things in and the number of components and dependencies that are you know has each open source because it's built on the pieces that others do. You're bringing in more and more dependencies each time because oh, hey, it's easier. I can just include as a developer.

I can just include this dependency and that gives me this feature. And as we take this up to scale for some of these spaces, this is where the challenges especially when all these dependencies aren't necessarily visible. The time so we're moving in that direction.

You know, I I think Kate you really are heading on here. Is this whole kind of software supply chain? Right as well and it goes to how software is built today when we say 98% of companies are using open source.

It's not that 98% of companies are using Susan Linux or Ubuntu or something like that necessarily. It's that probably 60 to 80% of the code in every application that we're using. Our open source components that have been glued in there stitched in there.

However, you want to call it. They're made up of these open source components dependencies third party code and all the open source. Development software, you know all the programming languages the main ones today are all open source.

Yeah, and so sure you compilers are part of the factor. Your bootloaders are part of the factor you're less and not just the application on top of the whole infrastructure underneath. Is you know, these are all that places that you need to make sure are secure.

Sure, let's Supply you. You know, we we've seen I guess it's almost two years now, you know this emphasis on the open source software supply chain and what we call, you know as bombs. So for a bill of materials And stuff like that, but it hasn't gone away.

It's growing and growing, you know, just last week. By the time this shows me will be two weeks ago. The White House came out with a new cybersecurity.

directive And and you know, this whole notion is is a big part of that. starting to hold providers in companies liable for their insecure code and and Supply chains and stuff like that. I wonder any of the panel feel free to jump in all of you.

Feel free to jump in What? What are you feelings on that? and if it's in critical infrastructure, it needs to be secure and safe.

period end of story I'm being able to make sure that the security is there and the safety is there safety principles are here too. I think we know just you know, we just we need to be able to do the right level analysis at scale and with the array of change in open source, we need to basically be able to automate a lot of stuff a lot of the analysis and this is a big challenge right now for us all is automating it so we can do the right level of safety analysis as well as security analysis to make sure we keep the security of the structure effective. You know John to Europe to your joke in the beginning it from the board member.

You know. Some may say Mainframe applications of sort of critical infrastructure or they there's an awful lot of critical infrastructure on these mainframes. Yes.

Yes, they're absolutely is and it's and I think decades point which is really interesting is you know, we we joke about this so much in technology and it's very true. We learned we learned so much from the work of you know, you know the Mainframe Community from the 50s and 60s and 70s and beyond that has made it into our our you know, our general knowledge around Computing, you know everywhere from virtualization to you know, share memory all these sorts of things our Technologies and things that are pioneered on the platform. But and in the same is true for the security half of things and this is something I can't be interesting for Mark's perspective.

Again so much we in security that Kate and Allen and and have been talking about is very broad across our industry regardless of the platform regardless of the industry horizontal vertical but with the Mainframe industry, it is tended to be a very close industry in terms of where the software is coming from how the systems work all those things and I know one area of friction that you know, you all have ran into is this concept of delivery of Open Source software onto these mainframes which have been a very closed ecosystem and our critical infrastructure and I think that's caused a little bit of friction kind of like tell us about that is like how you're starting to see that industry how those Mainframe systems have been maintaining systems like 50 years. Some of them are evolving. yeah, so it's definitely always a challenge to deliver software to a Mainframe both both actually getting the software onto the platform itself since it's so air gapped and then of course having you know people that are willing to try it out, you know since since you know system security and Since the the criticality of the Mainframe is so high, you know risk tolerance is really really low.

So, you know part of the you know, this is where like perceptions of Open Source came into play as you know, can it be secure or not as part of influencing. I think some users willingness to to try to install a new software. And I think what's what's happening now in the industry, generally with with s bombs coming out with um, you know, more standards like salsa for Providence establishment.

It's actually going to be way way easier to get users to be willing to install your software on the platform because you know, you can provably say, you know, what I'm giving you is actually secure what I'm giving you, you know passes, you know, these quality and security standards as defined by, you know, open ssf or by other by nist or other industry standards. Let me just build a little bit on what you're saying. One of the things that I found very useful or something open source projects.

I work with is the open source. best practices bad where all of the best practices and security are publicly documented from an open source project. And so this initiative started I guess about five or six years ago and and more and more projects are basically publicly documenting.

What they're doing and so getting more product even more projects things about three or four thousand of them up. Now that have been documenting what they're doing but to get to a basic level of you know, here's my practice and here's it documented and making it invisible and available. The last kernel has got the gold best practices badge as do a few other projects, but, you know, just getting to the passing stage and gaining there is a good start for a lot of these projects.

If you're going to depend on them in particular that they should be willing to be visible and document what they have available and Zoe is a project that also has the gold level badge as well. So but let's talk about that. You know John well, I don't know if it's John Mark what goes into getting that level achieving that level?

Oh off the top of my head. It is a very very long list of very strict criteria regarding best practices for Community Development for developing secure software for measuring that you're actually building secure software for making sure that you are responsive to incoming issues as well. As you have I think a cve submission and notification process so there's there's a very very long list of standards that you have to adhere to that, you know and ensure that you're doing everything in your power to build secure software and it is it is a long road to get a golden CII badge.

I could tell you those that is a very high bar to pass. And end to maintain it as well because so much of it depends on your project operations like that. The theory behind it is is if your project is operating in the best way, it doesn't mean you won't have a security vulnerability.

There's not a way to stop that like, you know, there is there's no magic. Yeah, but we are able to react to it and address it and be ahead of it and do it responsibly and have the community around it. That's where the drive is and that's where a lot of the stringency and what's also interesting of I think, you know Kate those three four thousand projects every single one of them has got a badge has had to do something in their project just a policy add something new do training things like that to achieve it.

So it's not a rubber stamp. You you have to do working your project sometimes not much sometimes quite a bit to to get that badge. It's it's not trivial at all.

Even at the passing level. I think it's a good Community. We started working on it a year or year and a half ago.

It's it's been a long road. Yeah. Sure.

Hmm. Hey Alan, I want to turn to you for a second if it's okay, you know, I remember 10 15 years ago. I did an interview with the CEO of couch face and the CEO of mongodb.

update both no SQL databases Both big open source Advocates, right and I said, hey, there's no sequel mean no security because we're seeing an awful lot of security incidents in here. Why isn't security more important or is security important? To you as at the corporate level and they both said the same thing.

They said Allen when our customers demand Security will build better security. So not that suits I'm not making Society. I was gonna say our commit our custom job ending security right apps are freaking-lutely.

But what and so what do you guys doing about it? Well, so as a company security starts all the way back at the projects, right? So all these Concepts we've been talking about the badging and so forth is very important because we've got to to look and I mean And whatever company you are, right one of the first steps you're looking at is which pieces of Open Source software am I going to pull in and provide to my customers?

And so you do an analysis about the that project or the choices of projects you look at. And you look at the Integrity of the community, right? So the badging process is one of those.

Boxes that helps us to understand the Integrity of the community. You know, what? The diversity all those all those kinds of features fall into it.

Do they have access control as the software control? What's the quality of the open source software that's being developed. What are they doing for the quality?

Right? Are they learning as John mentioned? Faults are going to happen right faults and source code are going to happen.

We're human. Um, are they learning right and adapting and growing from from the changes? How are they validating their software?

Are they monitoring their develop their are they monitoring for anomalies and not I can't even say that word. Right? All these types of features.

So we look at those and then you've got to get into the S bombs to understand and ensure what you're getting is what you're expecting to get. Right? And so you're looking do they have a single source of truth?

Right? Can I guarantee that software and getting is what I'm expecting then we go through the whole press process of hardening testing signing it so that when we deliver to our customers, we can ensure that what they're getting is what we expected clear back from the beginning. Right.

So you're securing that chain all the way from point where the developer wrote the code all the way down to the user that is going to use it for the next 30 Years. And we do that across all the different architectures, right? So from the Mainframe to the x86 to the risk to whatever type of Hardware to the different environments from Cloud to on-prem and All kinds of stuff.

So there's a lot of combinatorics that go into ensuring. That that piece of code that some guy in Kansas wrote is secure. Absolutely.

Yes, there's also a lot of checks. And so one of the things that may not be part of the minimum for serve s bomb standards, but I think all the people are using good practices are already doing is putting hashing on things. So, you know, something's been tampered with yeah, nothing sorts of elements here are going to be more more important very very important.

I mean couldn't be something that simple. the starting point if you don't have it you and I say if you don't have a hash on the image here shipping, you know, we've been doing these manifests for a long time. Anyhow, yes, not even quoting it in such a way that we can you know, pass it through the supply chain and let people see been check for themselves, you know trust but verify, right that hasn't been tampered with or not.

And once you consider prove it hasn't been tampered with you feel a little bit more trust confidence in using it. And when you look at the best practices requirements so many you're kind of I mean, some of them are very like stranger but others like Kate Setter are kind of a little bit obvious in some ways if you think about it, but it's sudden things that a projects don't think about and that's a great example of it. You might not think oh, geez I should sign, you know what I should provide, you know, a gpg or an MP5 hash of you know that I should make sure you can download it over an https link and not just ATP HTTP, right?

It's it's something like that to feel a little obvious, but they're just, you know to your point of is it that simple a lot of these things are that simple and those simple little things make a huge difference? And to go back to a point to add on to that I go back to a point that Kate made earlier about automation. Right?

A lot of vulnerabilities aren't because of. Problems in the code. They actually end up being problems with the human interaction and configuring how the code is deployed and set up right and the dependencies pulled in they pull in wrong dependencies or whatever as a configuration problem.

Not as a developer wrote, you know bad code. So automation is is a key piece to this and then validation of that as well. So yes.

Yes, and yes. so You know, we only have maybe five minutes left guys. One of the things I worry about is someone who's been involved in security space for a long time 20 20 plus years is when we when we focus on open source security.

Are we doing so at the expense of closed source security? Right or security security what we're doing in one kind of translates to the other anyway. Because really I mean look the action today is an open source.

So for supply chain, and that's bombs and and you know, and and it's because security follows where the action is, right? The action is an open source today. That's where Innovation is happening and everything else.

But are we are we do we need to be careful? We're not sacrificing one for the other. So I'll just chime in here.

As well should be used to represent closed Source, too. Okay, absolutely. Absolutely.

It's whatever's on the system and all our systems that both and so we need the whole thing to be secure. I agree with God you say it's exactly right. It doesn't matter whether I'm on a closed Source team or an open source team the you know, we talked about the development practices the development practices.

That should be the same. I should have the same type of monitoring built in validation processes and developing the code. I could you know, I've done closer software with some shady folks on my team.

All right, and and we just think well because we're giving them a paycheck I can trust the guy. Well, no as we found over the years, right? So the development practices should be should be the same.

He we do got that we do go back to the advantage. You mentioned right off Alan. And that is you know, many many eyes makes bugs shallow, right?

I have much more diversity typically in open source, particularly if I pick the right projects and so I've got eyes looking at that source code that aren't getting a paycheck from for me. Right? And I think that is an advantage of Open Source.

Excellent Mark I was gonna say at the standards or the standards the techniques or the techniques. You have to be doing them everywhere open source enclosed and I think the nist ssdf and the cyber security resilience strategy. They do a lot to make sure that that's definitely going to be the case going forward.

I think you know an open source. There may be innovation in terms of some of the tools that are built to the techniques, but I'm sure closed Source will catch up and regard, you know, even if they're not using the newest tool for static code analysis or the news tool for generating an s bomb. They'll still be doing those techniques and making sure that all the software they generate meets those standards.

actually Hey, John. From the open Mainframe projects from from the you know from your foundations for points. I really Foundation I guess but from the open Mainframe from Linux foundations point of view.

What do you doing? Not you personally, but what's the group doing specifically? to help with this issue Well, I mean I think on the first for front is we want to make sure all of our projects are sort of exemplars in the industry of what a great running open source project is and you know, just like the best practices badge which is a requirement as a part of the life cycle for all of our projects up from a very mature and graduated active stage project like Zoe to a very new one, you know, there's bad requirements along the way to make sure those projects are operating in such a way that they can have a good security posture.

They can you know address security issues very quickly and just sort of sort of showcases the right way to do it addition to that all of our projects. We do quarterly code scans and produce f-bombs for every single project on a quarterly basis. So that espan that you're talking that the Kate was talking about of, you know, knowing where this code comes from all of that.

Is built all of that we make very publicly available our projects go through and audit that for their own dependencies as well. All of our projects leverage the LFX security platform, which is a great tool for helping them be able to go in and see what are my dependencies what are you know the packages that I'm pulling in and what are the open security issues with them? Which ones do I need to address which ones you know, do we need to put somewhere in the pipeline to deal with they do scans in there also for you know code secret so somebody leaves a password or something else in there those get caught as well so that those can get flushed out along with inclusive language checks and things like that.

So we try to give a lot of the Tooling in there addition all of our projects take much of the LF training on secure code design. The LF training has a great series of courses that is focused on secure development. And all of our communities as part of their work, they have their developers take it maybe not every single one, but they have a good number of them that are taking it.

So they understand what secure development processes are so we try to do it from the tooling perspective the best practices but then we also help provide the educational half because you know, you you sort of need that to be embedded in and I run into a lot of projects. I think what are we start with secure Computing? Here's some classes go take them go audit them go learn from them and go build those practices and and so and so forth and I think the relationships I know Mark and some of the folks from from Zoe they participate in a number of the open ssf groups as well.

So we also get some of that cross mingling between our various communities as well and you know, the broader open source tech industry. So it's a lot of pieces we try to to help put in place, but also the culture and the connections Which is all about it because this is you know, it's it's it not to go to sleep tangent. I was listening to a podcast recently and they were talking about the airline industry and you know.

Planes are the safest way to travel by far of any transportation mechanism out there didn't always used to be but you know, if you think about today like how many people playing accidents are there? I mean, it's it's like I think last year, there's like a hundred people that died or 200 people that died, you know compared to that many die in car accidents every single day and one of the things that industry has went through is that they've got to the point where they're they collaborate on safety. You know, they don't use that as I mean, when's the last time you've seen an airline?

Say is one of its competitive differentiators is we're safer than our competitors. They don't do that anymore. They that is that is a base level expectation that that's there on time performance, you know seat Comfort all that's slightly different story, but safety is Is just there and you see all of the major airlines actually collaborate together on that and so where I would like to sort of hopefully see things go is that we as an industry, we're not having these open source or closed Source most secure.

We're all collaborating because software is a base level should be secure and software development should have secure practices and that should be just an understood. That's a base expectation and not an area of competition. God I agree with you and I think that's a great way of looking at it guys.

We're about at a time Mark Kate Allen. Thank you so much for joining us on this month's edition of the open Mainframe. John is always man.

It's great having you here. Keep up the great work. We love hearing what's going on any announcements John from open Mainframe.

Nothing really as of yet. Keep keep your eye ear to the grindstone though. We have on some exciting stuff coming down the path along with some events.

So hopefully in a couple of episodes here, we'll have some stuff more to talk about very cool. Alrighty until next time then, this is Alan Shimmel from Tech strong and John murdick from the Linux foundations open Mainframe project hoping you enjoyed this edition of the open Mainframe, and we'll see you next month. Bye.