 Hi, this is Oswin Bhartia and we are Headed Open Source Summit in Vancouver and today we have with us Omkar Arasarattam, General Manager of Open SSF. Omkar, it's great to have you on the show. It's a pleasure to be here. Thank you for inviting me. I want to talk about you first, talk about your own open source journey, what attracted you towards open source. Gosh, I'm going to date myself now, but probably about 25 years ago, when I first began my career, I got very deeply involved with open source and it fills me with pride as I hear from my other GMs and CTOs within the LF, several of us have worked on open source projects together in the past unbeknowingly, we've all arrived here. So I began my career, I was very interested in Linux, got into some system administration work. Then I began doing some work in the kernel as well and ended up doing some architecture maintainer roles with different distributions like Gen2 Linux. And then after that, I spent the last two decades very focused on cybersecurity. So I really view this role and I'm so excited about this role because it's the culmination of my experience and it allows me to really help with ensuring that we're providing more secure and safe software for the greater good. Since you mentioned security and cybersecurity, in today's world, when we first of all, the world literally runs on open source software stack, it doesn't matter whether... Also, the way we are consuming open source now is different than early days of SFS when everything was distributed, now nothing is being distributed, it's running, so security has also changed. Whose responsibility in security has also changed. Developers like you, it's not, hey, you developed a code, you sold it to somebody, they are managing it on their own now. Now you respond to the whole pipeline. Plus, when you look at open source, it's not just the project, they're frameworks, they're a library, there are so many dependencies. So we have to look at just like the whole supply chain, just like cars, assemblies. So I also want to hear, since you talked about all the early days of Linux kernel, how you have seen the evolution of security from those early days of traditional IT to the smart and cloud-centric, cloud-native world where there's so many moving pieces. That's a great question. And you highlighted many of the changes that we've seen because of course security doesn't exist on its own. Security exists as a component of the technology that we're building. And in the past where we had more centralized development and we were green screens to mainframes or even in the earlier or more contemporary days when we moved to client server, what I discovered is the threat landscape changed. And what I mean by that is when we think about how ubiquitous access is now versus how segmented we could make things in prior times, some of the disconnection actually led for a more controlled surface. Now everything's accessible everywhere, everything's accessible by IPv6, we have light bulbs with IP addresses, and the control surface is that much more. So the evolution that I've seen in security has been behind this kind of notion of having this hard exterior through which we will defend all the threats and leave everything relatively open on the inside to a scenario where we have to be resilient and secure by design from every angle without being able to consider that there's inherent security properties that will defend us logically and that we need to be secure by construction. We can't just hope the vulnerability scanner will pick it up. We actually have to be thoughtful as to whether we're using memory safe languages, whether we're using approaches and patterns that are secure by design rather than trying to quality control security and after the fact. You gave example of even the light bulbs, everything fridges, TVs. The irony is that when I buy a computer or a smartphone, you do know the life cycle that hey, the support will be getting, I don't even know how long my fridge will be getting software updates and there are a lot of known vulnerabilities or unknown vulnerability and my fridge and TV is plugged into my network. So that is also kind of, I'm opening a port for attackers to come and attack. So the thing is it's also become very, very complicated. In today's world, there are a lot of IoT devices, ring bells and so many things are happening. So when we just look at this, the devices and there's so many devices. The attack surface has also increased, threat factors have also increased. So when you look at security today, are you kind of getting worried that we have to actually do too much work or you're like, that's a natural protection of technologies, we are staying ahead of the curve. I don't think we're staying ahead of the curve. I think we're playing catch up right now and the analog that I use is I want to get right now, we're in a scenario where we're swatting mosquitoes. I want to be in a scenario where Citronella is ubiquitous and present and that we're warding off those kind of common attacks structurally rather than trying to do so after the fact. This kind of ubiquitous proliferation and extension of the edge is everywhere and I think a lot of the work that we're doing in the OpenSSF also seeks to try and address that. So even though we have fridges that are internet connected and light bulbs that are internet connected and cars that are internet connected and your laptop that's internet connected, the good news is many of these things are based off of open source software. And if we can ensure that we're being secure by construction in our open source foundational projects, we can help to ensure that the overall public consumption of these technologies is more secure. The challenge that we'll have and you hinted at this is the life cycle of it. And we've seen some legislation come across that proposes different methods of holding manufacturers accountable for a particular life cycle. It'll be interesting to observe how that evolves. I'm not sure that there's a proverbial silver bullet answer. And I think if it was that simple, we would have already addressed it. But I look forward to seeing how that evolves in working with our member companies and the general public to help ensure that we're providing secure software for the greater public good. So when we look at the whole security landscape, who do you think are the constituents who can play a big role when we talk about moving from the next phase of spreading mosquitoes to actually securing things? So when it comes to the constituents that help us move to the next phase, I'm an engineer. I'm an engineer that's been doing security for 20 years. So I think of things in terms of use cases. And in every use case, you have your actors that are part of the use case. So I think of four actors. The first actor are the companies producing the software, right? So many of them are on our board, companies like Microsoft, Amazon, Google. The second are actors that are primarily consuming the software. So and in this category, I identify some of my colleagues from Citibank and JP Morgan and Discover, etc. Not that they're not building software themselves, but they're primarily consuming it in order to provide business value. The third group that I think about is our friends in public sector. We have to work in partnership with our governments in order to ensure that we are helping to guide legislation, that we are helping to provide input as to where we believe we should be leaning in insecurity and where we should be letting free market forces dictate the betterment of software through demand. And last but not least is our greater open source community and security researchers. I think there's tremendous value in those constituents being able to help to influence secure outcomes in software. And we have great participation from all three or excuse me, all four actors when it comes to our use cases. And I'd like to continue to see that evolve. I think if it was just dominated by one, it would be imbalanced. The truly secure end point and the point that we get to where we have elevated software security for the greater public good is when there's a balance of these demands and we center on the ideal outcome. If you look at these four, of course, public sector long term, more engagement, a lot of legislation, a lot of their own education that is needed, open source community, we can do a good job in making sure the code base is secure. Companies you talked about, AWS, Microsoft, Google, they can also do a good job at the company. Second, the consumer, and I'm talking about enterprise consumers, and we keep hearing cases because when it comes to securing that cases, it's not just the software bug. It could be misconfigurations. We have seen access control. We have seen social engineering. So the challenges are a lot for them. Their employees in the laptop can come. I mean, we keep hearing about everyone. So we also feel that we need a culture shift also. So what role can open SSF play beyond just code to help them to kind of embrace the culture of, you know, I mean, of course, we have depths of cops and all those things. But we talk a lot about them. But then realistically, you know, what is happening and what will you folks and play there? Yeah, so a lot of the areas that we're focusing on are beyond just strictly technical contributions. It isn't just about rewriting things in memory safe languages or ensuring that some of the most popular frameworks like Python are secured by design, although that's a significant portion of what we do. In addition to that, we have end user groups within the open SSF that are focused on how this software is consumed. And if you look at the development environment of a lot of banks, they're not dissimilar to some of our colleagues in the technology center. They have their own pipelines. They have their own quality assurance. They have their own production environments that have to remain available and secure. And but they have slightly different demands. It's not often that a Google or a Amazon or a Microsoft will directly face direction or will face direction from a regulator. But a lot of our end users do. And we have to understand how they are looking to satisfy those requirements. In addition to that, education. I'm a firm believer that as an engineer, we have to build software that's secure by construction. There was the old adage about the factory where they were facing a quality control issue in the assembly of parts. So they kept adding more quality control people to the assembly line. And eventually, they're diminishing returns, and they employed more quality control people than factory personnel. But when they retooled the part, so it simply wasn't possible to put it in the wrong way, that's what we need to get to in terms of software engineering. This shouldn't require somebody that's extremely skilled in security. Should be secure by design, secure by default. And that's how we get to a stage where software can be secured for the greater public good. Can you talk about some of the initiatives that are there at OpenSSF in terms of the problem media that we talked about to help the enterprise customers to improve their security posture? Absolutely. So as I mentioned, there's the end user group that's actually chaired by some of our end user communities, end user participants, excuse me. And they are focusing on just such areas. In addition to that, when we look at some of the other work that we're doing in Alpha Omega, that looks to secure the upstream supply chain so that our end users don't have to worry about whether a particular version of a particular popular library is secure. They can rely on the fact that by construction, we've ensured that the right steps have taken place. And those are some of the areas that we've managed to get great progress in. But as always, OpenSSF, like other foundations, is member driven. And while we have an idea based on our current membership as to where to spend time and how to help, I'd also encourage anyone listening to this to consider participating. It's a wonderful way of being able to not only ensure that the work that we're doing is aligned with things that are a benefit to you, but also to help make the world a little more secure for everyone. But if you talk about security, we have to start talking about security a lot. It's not someone else's problem. Moving in, you talked about shift left. It's everybody's problem. Once again, I would like you to wrap not only with the rule OpenSSF can play, but also why companies should get involved because people are realizing that security is something they cannot compromise with. From our perspective, security is an ecosystem. We cannot be secure in isolation. We cannot be secure in a vacuum. We cannot hermetically seal and be secure. The only way to do this properly is to get participation from all of those constituents we spoke about earlier. Not only is it simply a equation of labor because it's a big effort, but it also brings different perspectives in. And as a software developer, I can make something extremely secure but unusable to an end user. Or as an end user, I can do something that is very optimized for my business but not necessarily compliant with regulation. So being able to engage all of our stakeholders to pull us to center on this so that our supply chain and our software is more secure by design for the greater public good is why we should get involved. Because even if, and I used to be in financial sector, so I'll cite banking examples, even if my online banking is secure and everything's running great, if the gas station down the road is hacked, that's going to affect me personally. And until we kind of take that challenge to really improve the basic software foundations that we run on, we're just not going to be able to get there alone. So if I was to, if there was a call to action for those watching this video, get involved, speak to your leadership about helping to invest time, donations are always helpful within the open source community and with open SSF to help make our software more secure. And then you get an example of gas station like that. You're as safe as the weakest link in the whole chain. That's right. So my question to you, last question is also, what kind of companies should get involved? Is it only the big companies? Or as I said, even the small gas station, every company, if you have a software stack, you should be. Every company needs to be involved. And part of, I think part of the reason behind this is it wasn't that we suddenly have more arduous security requirements. These are always here. It's just they're becoming apparent now. And the reason that they feel so difficult at this point is because maybe we weren't looking at what the true risk potential was before. And now that we understand, now we can be more thoughtful and now we can realize it's not just the big folks that are going to be involved. It's not just the big folks that are affected. It's this very complex ecosystem. And as we saw with log4j a few years ago, it literally affects everyone. Omkara, thank you so much for taking time out today. And of course, congratulations for joining the foundation and also share your own journey. And very, very heading with security. Thanks for all those insights. And as usual, I'd love to have you back on the show. Thank you. I'd love to. It's a pleasure. Thank you so much for having me.