Securing Open Source as Critical Infrastructure with Omkhar Arasaratnam at OSS Seattle 2024

This is Textron tv. Hey, everybody, welcome back. We're good.

Uh, have some great conversations lined up for you. And another one that we're having right now is, uh, talking about the open source security foundation and open source security. Security in general.

Uh, software courses a huge topic. Right now I'm joined by omkar, who is General manager of the OSSF. That's right.

Introduce yourself. I didn't want to take a shot. It, it's late in the day.

I didn't wanna take a shot of messing up your last name. I mean, you can use it as a password if you'd like. Oh, well, Okay.

All right. My Whole name is Omkar aum. I am the general manager of the open SSF.

And it's a pleasure to be Here. Good to have you here. So, you know, we're talking here, we're talking about open source, you know, summit, and of course security is a huge part of that and big part of the discussion.

As I understand it, one of the missions of the OSSF is to help all of the open source projects create more secure software. Is that fair to say? Absolutely.

Open source is critical infrastructure. And in order for it to be a secure public good requires all of our focus. And the open SSF is a convening place for the public sector, the private sector, and the community to get together and figure out different ways that we can make open source even more secure for consumption.

Is there, um, going about that mission, how do you carry that out? That's not, that's a big charge, right? Well, May 1st makes a year, so we're all done.

Good. Mic drop. I'm Good.

Mission accomplished. Um, it is incredibly complex. Uh, joking aside, our community is incredibly heterogeneous, which also makes it an amazing community.

There's so many different ways to go at the challenges that we have, but there's no one way to help anyone maintain No silver Bullet. There's no silver bullet. So what we try and do is we try and help out on the public sector side by working with our partners in public sector, be they domestically here in the US or over the ocean in Europe, by meeting them where they're at.

Um, every kind of political organization has their own process, their own way of protecting their citizenship. And in order to meet them where they're at, we don't have a particular bias from a legal perspective that we're going at software engineers. Mm-Hmm.

Uh, we strive to help them understand technical correctness and based on the way software's developed in open source, how and where they can help. Um, when it comes to private sector companies all over the globe, uh, we help them to understand how they can not only consume software securely, but how they can contribute back to making open source software more secure Point. Right.

And a lot of organizations that were historically somewhat pensive about sharing the way that they would consume open source software, the tooling that they would use to, uh, secure open source software due to this acknowledgement that it is a, it's a public good and it's an ecosystem. They've recognized the importance of their contributions back upstream as well. And last but not least, the community.

Um, some ways that we're helping the community. A number of our projects help to improve the security properties of open source projects, be it scorecard that provides a very easy to reason over report card as to how to make either your dependencies or your own project better. Um, sig store, which allows us to provide cryptographic assertions of providence Mm-Hmm.

Throughout the, uh, all the artifacts of the project to even some of the work that we're currently doing around education. So we currently have a number of open source security education, uh, courses that are available, but we also recognize that as much as we desire to shift the security equation left in order to make sure that we have the most educated developers available, it's not always the case. And especially at open source, there's no, there's very little barrier to entry.

You can just be interested in a project in civic code. So we're amping up our education this year, starting with a survey that we've distributed throughout the community to our members, to the general public to say, Hey, where do you need more help with security education? And using that later in the year, we're going to be distributing education free to everyone Mm-Hmm.

That will help improve those areas. Um, but those are some of the areas that we've been working on recently in terms of making open source a little more secure and trying to meet everyone where they're at. Mm-Hmm.

I think that's a good way to look at it, right? I mean, people are different skills, expertise, stage of career interests of why they're participating, right? Yeah.

Wanna be involved. You know, it's, you know, I work a lot in DevSecOps and one of the things that kind of frustrates me a little bit about it is the whole idea of shift left and putting it on developer's plates. And we all know that's not realistic.

You know, you're Yep. You, you, you educating and creating more secure code is like one in actually really small part of the whole thing. Mm-Hmm.

Um, and we need to think about, and the entire ecosystem about we did how we created, and one of the things that got pointed out recently was with UnitedHealthcare where there was someone contributing to a project. It was the XZ project. I remember zx, I can't remember the name of it, but someone who'd been contributing for a couple of years and then introduced some, you know, malicious coding to the project.

So it's even kind of provenance or identity of people that are contributing. Not that we suspect everybody is mad, but it's another attack vector For software. We're thinking about it.

I mean, we recognize the problem. And while I think the XE problem and the, we just released a BOLO be on the lookout with open js, uh, where they had seen a very similar kind of attack, but had stopped it early enough before the threat actor managed to get maintainer status. Um, we're really talking about two things here.

One of them being trust and the other one being security. What I mean by that is, it doesn't matter if it's me or Es or Joe off the street, everybody should have the same security bar when it comes to committing code. Like you don't get to bypass static analysis.

'cause your est, I mean, he'll probably have less fails passing static analysis than I would, but that who you are shouldn't be a bypass of a security control. Everyone should have to meet the same even bar. But then in open source we have this idea about trust and the hierarchy where we have consumers contributors and maintainers means there's an implicit part of the security fabric where there is somebody that has been bestowed the honor of being a maintainer, and therefore is counted on not only to reason over is this code architecturally consistent with the direction of the project.

Mm-Hmm. Is it matching the right coding style? But is the intent of this submission secure?

Mm-Hmm. And that's where we saw in XC as you highlighted, a scenario where somebody that was incredibly patient, and whether this was somebody that was a nation state actor or an incredibly well resourced set of people that sought to do harm Mm-Hmm. Were able to manipulate not only an incredibly burned out maintainer, but the trust of the community and achieve this status.

Now rolling it back, XY was a hobby project. It wasn't, you know, a large tech company that maintained it. And if we do go with the hypothesis that maybe this was a nation state, it seems incredibly imbalanced to expect a hobby project to defend against a persistent nation state.

Yeah. A little outta balance. I'd like to figure out ways that we can solve nation state problems at the nation state level, but also provide good and sustainable ways of making sure our maintainers are taken care of.

Mm-Hmm. Yes, we can provide more tools and yes, we can provide security best practices, but at the end of the day, if we have this critical infrastructure that is being maintained by somebody that's burned out, we need, that's one of the ways that I think we need to figure out how to serve our community. The German government has done an excellent job with this program called the Sovereign Tech Fund.

Um, shout out to my friends Fiona and Adriana that run the sovereign tech fund where they find these critical open source projects and they provide funding so that those programs can continue on. Mm. Sometimes it's not just funding though.

And this is about tailoring the approach so that we're meeting the maintainer where they're at. Maybe it's resources to get back to comment I made earlier where the private sector is now realizing, hey, we can't just consume, consume, consume, contributing code back upstream. Another idea that I've been kicking around, and it hasn't, it hasn't got a lot of traction yet, but people have mentioned that it seems like a good idea is this idea of either a fellowship or a core of engineers maintainer ship where for critical infrastructure projects that may be slightly neglected, that may not be the shiniest, newest, most interesting Mm-Hmm.

That we have a backstop there because this is critical infrastructure. And the analog that I use for this is we've incentivized everybody to go build skyscrapers, which is wonderful. Lots of great skyscrapers.

This latest, greatest shiny object. Right. Who's taking care of the sewers.

Yeah. Because when the sewer backs up, we got a problem. Mm-Hmm.

And we need to figure out how to sustainably fund the sewers in scenarios where I've even seen scenarios where we have maintainers that say, Hey, look man, this was a hobby project. It's really taken off. Yeah.

It's incredible that it's in nuclear plants and satellites. I didn't sign up for that. Yeah.

I can just, that would be a little scary too. I mean, just do I want that responsibility? Exactly.

And for those that don't want it, we don't want to impose upon them that they have to have it, but we should, if we're gonna use this a critical infrastructure, find a way to sustainably maintain that through cooperation between private sector, public sector, and the community. Mm-Hmm. How, how do we make sure we don't just kind of played whack-a-mole with whatever's the latest thing in the press, you know?

'cause that's what gets high level, of course, you know, that's what drives news cycles. But to me, in a way, when that happens, it's our representative, this tells you how widespread this is. That's why this is important because it is critical infrastructure, or it's just broadly on a mass scale used.

The, the litmus test I have is when my dad starts calling me about something and my dad, my sorry dad, um, yeah. My dad's use of his technology is primarily to send me memes and conspiracy theories. But when my dad starts calling me and saying, Hey, I heard about this thing in the news, should, should I be worried?

Yeah. What is that? Um, is this what you work on?

Exactly. I've had those calls. Um, but to get back to your question, the way that we do this is, as risk professionals, we need to start with some kind of framework to reason over of all the bad things that could happen.

Because security is this infinite problem space, right? Mm-Hmm. You could be tooling away on one corner of security and make incredible progress and realize that you were on the wrong corner.

Um, in industry, we typically use threat models, which is to go through how you're using a particular piece of software, particular application, and start poking holes into things that could go wrong. Mm-Hmm. So we had some work that started up last year in the open SSF, um, in the security tool belt working group in which we began threat modeling.

Everything from how open source is consumed and the entire pipeline of controls we need to how people produce open source. And there's a series of, there's a series of risk based use cases that we've come up with and are then using those efforts to drive where we build controls. So I think that's a fairly well proven way of doing it, and it keeps us centered off of always chasing what's ever in the news cycle.

Right? Right. Because there's never enough time, effort, or people to put behind that Mm-Hmm.

But it's, it is a methodical way of ana doing risk assessment, which was what security profession is doing. Threat modeling is great. Yep.

Like where do we invest our capital and our human resources? And it also allows us to back test. Right?

Mm-Hmm. So, hey, we have a risk model. We thought that this wasn't going to be that frequent of an occurrence.

It occurred, oh, it occurred twice. What controls do we have in place? What does our guidance say?

Where do we need to focus? And it allows us to reason over to the XZ topic that we talked about earlier. Look, some stuff's gonna be nation state, nation state, but here's the sphere of stuff that we want to Mm-Hmm.

Address. And in fact, as we mentioned, uh, earlier this week, when the community is functioning well, when it's well resourced, when people have an eye on what's going on and they're not burned out, uh, as we saw with open js, they were able to stop this threat actor that was trying to get the maintainer bit as the person in XC had Mm-Hmm. Because they were suspicious and the community worked and it worked very well.

Mm-Hmm. You know, it, it's, yeah. We, I can also come from the security world and we've kind of learned this lesson of instead of a hundred percent defense investment invest in response.

Right. Matter of fact, maybe 51% is, you know, maybe a little more than even defense. Not that defense is important, but without it, you know, attacks, things will get compromised.

It's just a fact filling. Yep. In the software world, it seems like looking at it that way also would be healthy.

So for example, I used to think about one of the benefits of DevOps and incremental and delivering code and increasing velocity is you can improve quality. Yep. Well, actually, how, how can we create software?

So when we need to apply a, a security patch, it can roll out much more easily without dependencies that are gonna cause people to stop or not know what to do or have the software update. It seems like how we build software might also need to change. So it can be updated very easily when we think about cloud native and containers and microservices.

Not saying that's The answer to everything. Yeah. But it seems like that's part of the challenge here.

I think so essentially to me, and you know, I've been doing software engineering for a quarter of a century. Um, security is a special case of a quality problem. And if we think about this from all the things that we've learned in terms of software quality over the years, including small incremental changes go much better than big epic changes.

Um, and being able to measure the quality of those changes over time and whether it produced the results we were hoping for, we can apply the same things to security. In fact, in my previous roles, we wouldn't consider security to be a special case. Mm-Hmm.

The only special case that we would have with security is if we were prioritizing a security based feature, it would've higher weighting Mm-Hmm. Than, you know, perhaps changing something that wasn't security pertinent, but everything else would have to flow through the same system. So whether we were doing unit testing, integration testing, all the test harnesses that have to fire even monitoring and production, you brought up a great point.

We are my friends and cisa call this left or right of bang. Right. And if we're not designing systems that are not only resilient to failure in build, but are resilient to recover in run Mm-Hmm.

We're doing it wrong. Mm-Hmm mm-Hmm. If the first time a bad security thing happens, it's this catastrophic event where everyone's running around with their hair on fire, that's really bad.

And there's known things that we can do to make that easier. We can make sure we're thorough in asset management, which includes SBOs when it comes to producing software. If anybody that's anybody that's run a security incident before, especially in responding to a zero day attack or a high severity CVE will tell you, Hey look, half the battle is figuring out where everything is Exactly.

And is it reachable and what's been hit. Right. Exactly.

And being able to have all the assets at build time or just a standard operating artifact that let you reason over how to triage that thing that is incredibly useful in operation. Yesterday when we had our open SSF sauce Community day, we introduced the idea of a tabletop exercise to the community from where I grew. Um, tabletop exercises were things that the regulators insisted that we have.

And it gave us a great method to practice our way through security incidents yesterday. It provided great insight to all these different parts of our ecosystem as we reasoned through a scenario that was eerily familiar to xz, even though it was designed six months ago. Mm-Hmm.

And really allowed us to think about, well, what are the issues that we have right now? And what should we focus on next? In fact, in the near future, probably later this week, perhaps early next week, we're going to announce some additional tooling and facilities put in place to help the open source community better coordinate and collaborate when exploits do occur.

Not just when vulnerabilities are announced. Mm-Hmm. It's a really good point.

I mean, there's the backlog on vulnerabilities and that's not getting smaller. Right? Yep.

And it's also, that's part of the response. It is, It is. Yeah.

I even think that may be a good use for AI at some point of being able to create simulations. But we can have all the software, you know, it can be analyzed to understand what it does and how it's interrelated. We can create a simulation of that.

Now let's do tabletops using simulators of what the response to our software would be if we did just kind of attack this vector, whatever it might be. I think that could be incredibly interesting. The way that we're currently thinking about using AI to help in open source security, we're, uh, DARPA issued a challenge called the AI Cyber Challenge.

We're challenge partners. Mm-Hmm. Uh, and what that means is we are working with the community and we will eventually be the home of the winning solution.

Mm. And DARPA's challenge is how can we use like, putting aside all the hype, right? Because we are, I'm not sure that we're at peak hype yet for ai and that scares me a little, but Is there a peak?

I'm not sure what's gonna happen, But putting aside all the hype for a minute, there's an interesting potential where we could use large language models in order to address entire classes of vulnerability. Mm-Hmm. In open source software.

Mm-Hmm. The software's available. There's certain things that current technology today could do, like static analysis or fers, things of this nature.

People Have disclosure issues. I intellectual property people want to not be public, right? Yeah.

Um, but the challenge will allow challengers to reason over how they can apply large language models to addressing vulnerabilities in open source. Uh, the open competition is open until the end of April, I believe. Mm.

Our midterm check-in will be at DEF CON in August. Our finals will be DEF CON of 2025. Um, there have been some really interesting submissions thus far.

And then as I mentioned, since this is a public good, the winning solution will be open source to the open SSF. That's exciting. Um, so we're very excited about that.

I think there's also potential, you know, a very popular topic has been the utility of memory safe languages. Mm. And look, I'm a pragmatist.

There is more lines of legacy code that I can count and there is going to be no quick fix to flipping over the actuator that's in a nuclear power plant to a memory safe language. I'll acknowledge. You mean it's not Okay.

All right. Kidding. I'm kidding.

But Interrupt you. An interesting application could be, 'cause we know there's a spatial issue. The more humans touch code, the more bugs appear.

Mm-Hmm. Interesting. Um, maybe we can use LLMs and understanding of where we are today.

Maybe we can use LLMs to quickly and easily transform legacy code bases to modern language code bases in a safe way. Mm-Hmm. That could be an interesting path to explore.

Mm-Hmm. Absolutely. Well talk, talk a little bit more.

I know we've been talking for a while here. Talk a little bit more about your relationship too and your work with government in the US but also international. Mm-Hmm.

Sure. uk, U eu, et cetera. Over the last little while, uh, domestically here in the US especially CSA has been incredibly focused on building better bridges with the open source community, meeting the community where they're at, understanding how they can help.

Uh, CSA recently published a open source, uh, security roadmap last year and we're in regular consultation with them. We actually recently published a guide for securing open source software repositories. Software repositories are the watering holes of our community and also a great place to affect and implement security properties in the supply chain.

Mm. If everybody comes to NPM, hey, let's hook controls and NPM or uh, in pi, PI or what have you. Mm.

Or rust crates. Um, they've been incredible partners. And a lot of that also culturally comes from, um, the politics of how government runs in the us.

Sure. As a country we tend to be quite bottoms up. We allow innovation to occur and, uh, the government sees how things evolves and steps in when they believe is necessary.

Mm-Hmm. Across the pond in Europe, they take a different approach and rather than, uh, waiting to see what comes up, they tend to legislate top down. I'm a software engineer, not a politician, either is fine by me.

Um, the e recently passed the policy portion of the Cyber Resilience Act. Mm-Hmm. Uh, we'd give an input there.

We're gonna be moving into a phase that they call standardization, where they take the legal language and they start to establish technical standards for what that means in reality. So you can have the CE mark Mm-Hmm. We're going to be actively involved in that.

Hope to have an announcement in a couple of weeks. But essentially one of the bits of feedback that we got from the policy setting side of this with the EU earlier was, Hey, multi-headed Hydra called the open source community. Y'all have a lot of opinions.

Help us out. We wanna make sure we don't miss anything. Help us coalesce those opinions so that we understand the aggregate point of view.

Mm-Hmm. So we're working, we're gonna be working with a number of other foundations to do so. And our hope is that over the three year standard setting process, not that we're going to materially change how EU passes law, not our goal, but we wanna be there to ensure technical correctness.

Mm-Hmm. And to ensure that we're advocating and speaking on behalf of our community when it comes to good, secure technical outcomes with passing of the CRA. We've also been in a number of discussions in Japan, um, and had several discussions, especially around software bill of materials there.

And, uh, we hope to engage with other public sector as their interest, uh, grows in open source security. Well that's, that's very healthy because the policies and the laws are, one thing is always the interpretation rights, the application of it. And while the lawmakers may not be the, the world's experts on that particular subject topic area we all know happens The technology, it's of the lawyers and the engineers.

Yes. Yeah. Which is all real interesting.

You know, do these things actually mix. Right. Uh, the viscosity's too different doesn't happen.

That's the right way to say it. Well, it's been a pleasure talking with you. I appreciate how long do you stay in this role has a certain length of term as the general manager, just it's so you decide to change or how, however, Until somebody decides Somebody, somebody says uncle and then you did the next thing.

I'm really enjoying my time here. Uh, when I was, I was speaking to somebody earlier today and they said, well, how did you decide that this was the thing you wanted to do? And I have this, um, I have this motivation to one, do highly improbable things and two, to do it at as wide a scale as I can.

And without being too hyperbolic, the opportunity here, if we get this right, just to genuinely make software better for 8 billion people, that's really inspiring. Mm-Hmm. And as cliche as it sounds, I think if we can make open source more secure as a public good, it genuinely benefits over it.

What, last question. What can CISO, uh, CISO CISO do to kind of better understand and follow what's happening in software? 'cause let's be honest, most of the folks in that role didn't come through the software role in their background.

Maybe they did, but majority of 'em come up in network and network security and Yeah. Or risk management. Or risk management.

Yep. So software can be a little bit confounding, like the multi-headed hydra. Exactly.

As well as the layers of multi-headed hierarchy. Yeah. I mean, software is such an incredibly large space.

And I'll, I'll start by saying, when asked to describe my own career, I identify as a software engineer that's been doing security for 20 years. Mm-Hmm. Um, and that is a unique point of view to have.

But what I'd encourage CISO to do is one, professional empathy. Understand where your partners in engineering are coming from. Mm.

Take their advice and counsel at surface. It may not seem like you're speaking the same language. Take the time to understand.

Um, and that can be incredibly powerful. And the reverse. I'll have a call to action for the heads of engineering.

I know the security friends have often been called the department of, no, they're not the department of No. They just need to carry the same knowledge that you have. And there's incredibly powerful things that you'd be able to learn about risk management from the security department.

So I guess the call to action for both parties would be, don't do this alone. Understand where you're coming from. Security is essentially, uh, what I'd say to the engineering leaders, security is a quality property of your software.

What I would say to the cyber leaders, the CISO risk managers, this is part of your overall operational risk and much like you would consider operational risk. If you don't understand the inherent risk, the controls you have in place and the residual risk that you have to contend with, then you're missing the equation. And if you don't have the right language on either side of that discussion to be able to draw the conclusions, then you need to partner better with those individuals and build a culture of trust.

You need to be able to trust each other that one person isn't trying to put something over on the other. But essentially by growing together, we can really help improve the security properties of software. I got sage advice.

I mean visibility, imagine error you don't have any visibility into. Right. That's a risk.

Right. Completely opaque things are really scary That security people don't like that. Mm-Hmm.

That I remind the software engineering leaders, by the way, you've been called the department of no too. So you know absolutely how to kinda overcome those kind of things. And I mean security, you allow security things to pile up.

And uh, in a previous organization that was very well steep in SRE culture and error budgets and things like that, I was in the engineering department, but I was acting as a translator of security things. Having done it for as long as I had, we came up with a security budget because security has the same property and for certain security things, they will weight more heavily. So, hey, don't go chase the new shiny before you fix the authorization layer.

You have the same budget, choose as you will. Mm-Hmm. Um, so I think some of those, again, showing that professional empathy and being able to frame things in a way that's natively understandable, if you're the CISO to the engineering team, if you're the engineering team to the CISO will ensure that everyone has that transparency.

And there's no apac. I think there's great analogies too. You know, like cloud native is a, there's a great analog, you've seen this before, security folks, it looks like network elements, you know, all talking over a network that kind of what This kind Of what essentially what this is.

Yep. So you're actually not that far apart. You know, a lot of things that, uh, you don't realize a part of that.

Yeah. One of the things that I've seen, uh, engineering leaders, especially large distributed systems and security leaders sometimes have opposing views on is fail open or fail close. Right?

Mm-Hmm. And even those kind of discussions are need to be really risk weighted. You need to honor how the distributed system acts of course.

But being able to come to a good outcome based on both parties motivations, I think can be incredibly useful. Great. I'm car.

It's be great talking with you. Thanks for your leadership and the OS OSSF and interfacing with all those folks in Washington and around the world as well as with the software community and securing folks. So It's a pleasure and I look forward to everybody working together to make open source software a secure public.

Good. Good. We look forward to some of those announcements too.

Sound like some good things in the works. Absolutely. Great, great perspective.

I think this is the conversation we need to be having a lot more with software between software community and, and folks worrying about software security, whether they're coming from security or, uh, the software world. So thanks for having me in that conversation With us. Thank you for having me.

And I'm sure we could talk for hours More. We could, matter of fact, we would need a, an adult beverage to continue that. Here we go.

Oh, hey. Oh, speak up. Hey, it's about that time.

Thanks for joining us folks. So we have another great interview coming up and thanks to you for being here. Thank you.