 Hi, this is your host Abil Bhartia, and my next guest is Joe Bostien, Chair of Ambitose and Open Mainframe Project and Senior Technical Staff Member at IBM. Joe, it's great to have you on the show. Thank you for having me. And today we are going to talk about security, of course, from the lens of open source. In general, I mean, when we started an open source journey, one of the things was that, hey, open source is, it's not that open source is ultimately secure, it's more secure than, you know, proprietary technologies, but the fact is that we've also seen a lot of, you know, breaches there because no matter what, bugs are part of software development process, so bugs will be there, bugs can be security vulnerability, misconfiguration also there, access is also there. So let's look at, you know, when we talk about security and the use of open source in enterprise, what kind of challenges that you see where companies still face that, hey, just because open source doesn't mean it's fully secure? So there's really two ways to look at open source in terms of security. One is quality of the code base, right? A lot of times you can get into deep philosophical discussions about what's inherently more secure, open source or closed source. And there are a lot of long discussions you can have about that, but equally important to the quality of the code base is how you deploy and manage that software. And that doesn't really matter whether it's proprietary or open source. It's your best practices when you deploy and manage the software that's part of your environment. And in that sense, there is still sort of a big cultural divide between open source community and proprietary houses where the code oftentimes tends to be kept in an as needed type of an environment. If you don't have a need to access this code, you don't have access to it. And there are strengths to that method of deployment in the sense that you keep tight control over the uses of your system. However, it can give you a false sense of security in that if I come up with a configuration that's secured today, then next year it'll be just as secure when in fact that's not the case, right? People have to understand that when it comes to, when it comes to the security of an environment, that is something that is a point in time measurement and you can say, okay, I feel good about where I am today. It doesn't mean that next year it's going to be just as secure because your bad actors out there in the world can find ways around the different security measures that you take and you have to be able to adjust accordingly. That's really where the open source community is strong because that community is constantly evolving and sharing information. So what we really want to try to do is bring together the best of both worlds, right? And bring some of that common sense knowledge that people from the enterprise community and perhaps closed source proprietary environments may consider to be sort of best practices and marry that up with the technology base and all of the different types of solutions that are available in the open source community. And you tell them on some great points. First of all, the software, it's not a static. It gives you all a new pack, new updates keep coming in and those updates can also bring in, you know. What happens is that open source communities are great. Even when we hear about any vulnerability, the communities, the Russian, there are some exceptions always, which can be challenging but Russian, the patch is there. The challenge is that the patch has to be deployed also in production. I mean, I don't want to name any company but we have seen so many cases that patch was out applied, that was the big compromise were there, which also kind of brings as you talked about the cultural problem, how it's deployed, how it's running there. And it's not that, you know, it's the same thing is with the proprietary also the only difference is that you don't have to rely on a single vendor here, open source community. Anybody can come up with a patch but talk a bit about when you look at, you know, the patch is ready, but it's not being deployed. That's when we talk of personal or cultural problem. Whose problem is security? That's why you talk about DevSecOps or SREs. So what do you think from that point of view? Yeah, definitely the speed at which patches are deployed is absolutely critical to the security of your environment. I mean, how many times have you read a story about a breach at a, you know, at some particular firm even security related firms where you find out that the patch was available a year and a half ago, but just hadn't been applied. Now understanding that there are some complex dependencies between different sets of open source out in the environment that have to be managed, right? A lot of times an upgrade to one package creates a conflict with another one higher up in the stack and it takes some time to manage those so that they can be coordinated properly. Even when you account for that there are still plenty of places where a particular system administrator has been slow to upgrade for non-technical reasons that eventually results in, you know, an exposure of sensitive information that was unintended. And so I think everyone, whether they're, you know whether they have a deep open source background or they come from a proprietary enterprise background has to exercise those muscles to keep as current as is feasible from a technical standpoint because that's the only way you're gonna defeat, you know threat actors who are coming after you. Can you talk about the cultural aspect as well? Of course, we do talk about, you know the whole shift left boom when DevSecOps is there. We are also trying to break the old silos. Hey, they're not like totally different isolated security teams, you know which can sometimes slow things. We talk about, hey, security is everybody's problem. It's not a specific person's problem. How much do you see in real reality happening when we specifically look at the organizations who are embracing open source? Do they really have these, you know DevSecOps or shift left or zero trust practices in place to ensure that whatever they're deploying is secure? Yeah, well, working for a, you know a large company myself that has a lot of, you know exposure to some very complex software environments. I can tell you it's a work in progress especially with the advent of Log4J that was, you know, a problem in 2021 that really seemed to be a catalyst that got a lot of people's attention and said, hey, we know we've been sort of moving in this direction for some time now. I think that woke a lot of people up and said, hey, we really have to make this a big priority, right? We cannot stand to have the kind of exposures that are becoming more and more common all the time. We can't just sit there and say, well I'll get to it along with all of my other priorities. We really have to bump this to the top of the list. So I would say that there is a lot of work that is going on in this space. We see it through the open mainframe project, the open source security foundation and we see it in the efforts of that particular group. And I know as the head of the Ambitus project, right that kind of assessment of my own project takes place all the time where the security groups are trying to go off and assess and score rate all of the different projects that are out there and available today and say, this is a healthy community. This is one that's got a strong user base, a strong set of maintainers and they put out quality code on a regular basis or perhaps this particular group is a little bit understaffed and they can't quite keep up with what all of the evolving threat base that's moving faster than they can keep up and you maybe should watch out for what they do. So we at the Ambitus project are always looking for ways to enhance and enable users with their DevOps and with their particular pipelines to help them stay current and ahead of the threat actors that are sort of chasing them these days. Since you talk about Ambitus project, yes, these open source projects, they do ensure that their code is safe, but let's go back to the problem that we're talking about that it's being deployed also, it being your patches are deployed. So talking about Ambitus project or we can also talk about open mainframe project in general, what are you doing to kind of educate users that, hey, keep the code base latest. Also, if you keep a gap, not only security, but also when they're jumping from one version to the third release, it becomes more challenging also. You are running a separate four coffee open source. So talk about what new folks are doing to kind of also educate the user base so they keep their code base secure. There are, especially in the mainframe environment, there are lots of opportunities for users to come in and port and bring common Linux functions, for instance, to ZOS, or to bring additional functionality to Linux on Z. And there are some best practices involved in doing that. And in the process of managing all of those kinds of activities on the system, when you bump up against a system administrator who perhaps does not have a deep open source background, a lot of times, this is where you'll get your sort of cultural clash, and we have to explain that the new stuff from the open source community really does include the facilities and the frameworks necessary to be secure in the sense that a traditional mainframe environment would consider to be acceptably safe, okay? And so from the Ambitus project, we're trying to create sets of open source software for DevOps purposes where that might be beneficial to our community. And in other cases, when we find existing open source projects that can enhance the security of the environment, we'll try to support those as well. And that might mean that we would have to take on as a community a porting effort to get a certain code base to run on ZOS. We have lots of affiliated groups that we work with who are off actively porting shells that have more current behaviors and more current versions than what we have by default in the environment. And that might be one way to close a whole class of problems that have existed from a security standpoint in the past. So we're trying to enable a lot of that and we're also trying to find a home or provide a home to those who have good ideas for DevOps that enhance security as well. Being a non X86 platform, sometimes that means that we have to do some code that's unique to our platform, but perhaps has the same look and feel as you would see on X86 or in the cloud, right? So that's kind of the environment that we're trying to provide with Ambitus is to create those things that say a dynamic main framer would look at and recognize and say, oh, I understand what you're doing there. Perhaps this is with user administration. That's one area that has a lot of focus. And the Linux environment, which has a different concept of user administration. And if we can create the proper DevOps and the utilities that go along with that, then you can get someone new from the Linux environment who goes, okay, this is different than what I've seen, but I understand what you're doing. And when we can do that, then Ambitus has served its purpose well. Thanks for explaining that. The maintainers are all doing their jobs. Users are also doing their jobs, but the fact is there's no single open source community. There are open source communities. There are so many projects. There are so many libraries, not just the libraries, a lot of, you know, you go to container work or, you know, they're, they have a lot of packages. And sometimes they're different developers they create. So there may be different, not versions, but if you go and check in there, like five different MySQLs, you know, created by different maintainers. So just because it's open source once again. So talk a bit about, you know, when we look at, you know, these repositories, you know, just because open source, that doesn't mean it's all safe because it also means who is maintaining, who is managing it. When were the last batch applied? So talk a bit about that aspect also. Whenever you look at a code base, one of the, well, actually I mentioned the open source software, the open source security foundation before, or project before, one of their key metrics is how old are the packages that you have on your system, right? And they can survey a whole set of code and say, okay, you're reasonably current or you're not. That is just sort of a high level, sort of top level view of just how current you happen to be. But you have to drill down beneath that and say, well, okay, some of these code bases are more dynamic than others, right? Some will have frequent updates and you need to stay on top of those. And if others say are a year or too old, that's because they've provided a stable function for a very long time and are still secure. So these teams have to go and assess each one of these packages individually and then score the whole group and say, you're reasonably current, you're reasonably secure, or you have some very serious holes that you need to go in and plug just by upgrading to new versions of your code. And so there's a huge effort going on right now, just trying to assess what your current posture is as a group and currency is definitely one of those kinds of things. So anything that we can see that where we could create a workflow or a technique or a best practice and explain through the Ambitus project, this is the best way to go about handling this. We realize that this is complex. Here's how we figured out how to solve this problem. We're certainly gonna publish it there and make it available to everyone. Security is not a product, it's a process, it's not just one thing, it's so many things. I also wanna talk about if you can share not necessarily a playbook, but some advice. For example, let's just think about code base that has been sitting there. You use that, it's obsolete, but it's still there. That can also create vulnerability. Zombie code, as you can say, misconfiguration is also access you may have given wrong access, you don't even manage access. And of course, keeping your software fully updated. So talk a bit about if you can share some advice that, hey, how folks can ensure that their open source code base that they are using in their services or product is safe. There are lots of scanners out there of today that there's no shortage of them that scan for various kinds of things. Known problems, CDs that have been identified. There are ones that go out and scan source code and say, well, we're not looking for known problems, but we do know of best practices and we have a set of rules that form a policy and that policy needs to be adhered to in order for your code base to be deemed of sufficient security, right? I work on a product myself where we have to work with several scanners that look for all sorts of things like best practices and source codes, viral licenses, for instance, those are also in some sense a type of security concern because somebody could write any kind of a license that they want and get that widely adopted. And it can be a threat, maybe not in the same way, but it's still a threat. So there are lots and lots of different scanners out there that perform various types of functions and probably the best practice is to apply several of them in a very organized way. Perhaps they overlap a little bit to give you better coverage overall, but what you really want out of that collection of scans is a good top level view of where you stand with everything. So perhaps you pick out one that scans for CVEs, one that scans for source code policies that need to be followed. And by the way, a lot of these scanners, not only will identify problems, but also suggest a remedy, right? So they will say, if you upgrade to the version you have plus three, then you will resolve this problem. And that's very helpful, right? So it's good to not only know what the problem is, but if there's a suggested resolution, then go ahead and follow that. And that can really help your administrators a lot. So just following those scanners and there are many, you can go a long ways towards securing your environment. Joe, thank you so much for taking time out today and talk about this topic and also share your insights, some tips, how, of course, just because open source doesn't mean it's fully secure, we have to do a lot of work also. So thanks for sharing those tips and I would love to sit down and chat with you again. Thank you. Yeah, well, thank you very much. Thank you for having me.