July 2024

• 00:57 Brian shares his background
• 03:56 The confusing trend of downloading assets on Maven Central with known vulnerabilities
• 08:16 How this trend continues in other repos
• 11:08 Brian and CRob discuss Log4Shell
• 16:54 Brian answers CRob’s rapid-fire questions
• 18:46 Brian’s advice for up-and-coming security professionals
• 19:50 Brian’s call to action

• Brian Fox on LinkedIn
• Sonatype’s 2023 State of the Software Supply Chain Report
• Get involved with OpenSSF

Brian Fox soundbite (00:01)
The customer is not gonna accept as an excuse, like, why did you get hacked? Well, my direct dependencies were fine, it’s those indirect ones that were bad. Like, nobody cares, right? Like if you buy a pie from a bakery and you get sick, it’s not acceptable for them to go, well it was my sugar provider that did a bad job, here. 

CRob (00:18)
Hello everybody, welcome to What’s in the SOSS? I’m CRob. I do security stuff on the internet. I’m also a community leader within the Open Source Security Foundation, and I’m one of the hosts of this amazing podcast. Today I’ve got my friend Brian Fox. He’s the CTO and co-founder of Sonatype and he is an amazing open source contributor and he’s a great collaborator with us and a lot of industry efforts. So I want to say, Brian, welcome.

Brian Fox (00:49)
Yeah, thanks for having me.

CRob (00:50)
Could you maybe share a little bit about your origin story? How you got into open source and kind of the stuff you’re into today?

Brian Fox (00:57)
Oh, sure, my origin story. That’s a long one, but short version is I dabbled in open source before it was I think called open source in college actually, some PERL CGI open source stuff way, way back in the day. But I would say my first real introduction into like durable open source, let’s say — I had I dabbled with a JSP library at SourceForge. And I don’t really count that, but you can see they’re all connected in a straight line. I got involved with Apache Maven super early

in the 2.0 alpha days. I wrote some plugins. I was basically doing development management during the day, had some folks working for me, and we were trying to transform our builds from Ant to Maven and move from CVS, I guess it was, to Subversion. 

Yeah, I’m dating myself a little bit. And we were running into some issues, and so because I didn’t have much opportunity to code during the day, I was coding at night. So I would go home and start working on fixing bugs and writing plugins that the folks working for me during the day the next day would then use to move forward. And so I wrote some pretty popular plugins, the Dependency plugin and the Enforcer plugin that later came from, the Code Haas Project — Code Haas was sort of an adjacent open SourceForge, if you will, that eventually got pulled into Apache Maven proper. And I came along with it as a committer, was later a project management committee member, and for a while after we started Sonotype was even the chair of that project. 

And, and for, for historical reasons that, you know, we could have a whole podcast on, you know, the Maven central repository has always been a separate project from the Apache Maven software base. And basically, a handful of us, and then later Sonatype, have basically been the stewards of that all along. So, I know where all the bodies are buried and have lots of war stories from, from open source Java and Maven Central in general, from, for the last 20-plus years. I suppose.

CRob (03:03)
So I’m a little bit of a data nerd and I know you share that kind of passion for data and numbers. Your organization, Sonatype, puts out an annual report, well many of annual reports, but the one I’m most interested in is the State of Open Source Supply Chain Report. That’s one, I’ve referenced that many, many years. It’s pretty amazing. And I want to kind of talk about some of your findings from the most recent one. Maybe we can kind of, that’ll get us into this topic. But you know, when I was looking at the 2023 report, I noticed that you had many statements, one of which was you noted that 96% of all vulnerable downloads from Maven Central had known fixes available. What’s up with that? Why are folks still downloading known vulnerable packages when there’s a fix available?

Brian Fox (03:56)
Yeah, yeah, this has been my soapbox, as you know, for a couple of years. 2022 was the first year we published that stat. Sadly, it was unchanged in 2023. It did not get better. What does this stat mean exactly? At a point in time, when a thing that is in Maven Central, and I think off the top of my head, I’m not certain. I think around 12% of the things in central have a known vulnerability. But they’re skewed, obviously, towards more popular versions of it. So when those things are downloaded, looking at the point in time that it was downloaded, was there already a fix for that vulnerability available? So in other words, it’s not a case of this vulnerability is out there and people are using it because it’s not fixed.

After Log4Shell, which I’m sure we’ll get into a bit more, you know, we saw a lot of people talking about like open source should do a better job of fixing their stuff. And it’s like, well, when you sit where I am and you look at that and you go, well, wait a minute, when these things are being consumed from the repository, 96% of the time, the fix already is available. So what does that tell you? It tells you that the consuming organizations are not choosing to update for the fix. It shouldn’t be a 0% stat, right? There’s always going to be vulnerabilities that in certain contexts just don’t apply, and so you can continue to use the thing, or you have other mitigating controls.

But 96% is crazy. And the fact that it doesn’t change. And so why does that happen? There’s lots of reasons. And I’ve been recently in blog posts and articles exploring more the psychological side of things. I think there’s, humans are wired to procrastinate and hope that the future will be better. And I think there’s an element of that, that people look at it and go, well, you know, we’ve lived with these things so long, you know, I’m afraid to do an update. Dr. Wheeler and I have kind of toyed with the idea that API changes introduce a bunch of these problems, or at least the fear and the history of API breakages have caused people to be afraid to make an update. 

And so there’s lots of little reasons that cause organizations to just sit there and not update and therefore continue to consume these known vulnerable things. And so I’ll ask the obvious question because when I point this stat out, everybody turns around and asks the same question, which is, Brian, why do you make vulnerable versions available for download in Maven Central at all? Right? And so, you know, part of that is precedence in history that Maven Central is known for its stability, that we don’t allow authors to just up and decide to unpublish something. For those of you that remember left-pad and NPM years ago, it was a little bit of a tit-for-tat, and a maintainer removed a package and it broke like the internet, right? And so for reasons like that, we don’t allow things to just up and disappear. 

Most of the time, like I said, not everything is universally applicable. So I use an analogy. For some people, peanut butter can kill them. They are deathly allergic to peanut butter. I can go into the store right now, I buy peanuts, buy peanut butter, buy things with peanut butter in them. Why? Because I happen to, fortunately, not be allergic to peanut butter. I do not have that vulnerability, or at least that vulnerability does not apply to me. So like that analogy, why should we take every single component down just because it has a vulnerability and make it impossible to reproduce old things, break things that don’t need to be broken? 

And I draw a distinct line between a vulnerability and a known malicious package. A known malicious package is like saying we’re going to continue to sell salmonella-tainted  food because some people luckily don’t get affected by it. Like, no, that’s very, very different, right? So salmonella components, yeah, they’re coming out immediately. Peanut butter, they should be labeled, they should be understood so that people that have vulnerabilities can know about it, right? And so that’s why we don’t just disappear components merely because there’s a vulnerability. 

CRob (08:04)
You have a lot of observability into Maven Central. Do you feel that you know the pattern you’re seeing does that probably exist in other repositories as well? Do you think it’s similar? 

Brian Fox (08:16)
I know it does. Yeah, I know it does. How do I wanna phrase this? There are similar problems. They don’t have the same root in the origin of it. So, for example, Maven has a strong namespace in the group ID, right? So typically that would be the reverse DNS of your company, just like Java package standards. That’s where we, we didn’t invent it. We just followed the Java standard. And when, when somebody comes to Maven Central, we validate that they control that domain and that namespace, or alternatively they can use their project URL at GitHub as an example, right? And, and we do the validation and that’s so somebody can’t show up to the repository and pretend to be Eclipse and start publicizing things. You can’t pretend to be Apache and start publishing things. 

That’s an important piece of this. The other piece of it is that Maven prefers stability over auto-updates. So it prefers staying on a version number. So it’s sort of an anti-pattern in Maven land to say, just get me the latest version of this thing all the time. So that choice, that design choice, has unintentionally created the issue that I talked about, that people aren’t upgrading, right? That’s an unintended side effect of that. But now let’s look at what’s happening on ecosystems like NPM, Python, Ruby, where the tool has made the choice that we are always gonna check and fetch the latest version unless I’m told not to, right? 

That’s why you have the concept of a lock file to lock it down because if you don’t lock it, it’s going to fetch it. And also, unfortunately, those ecosystems also don’t have a strong namespace enforcement. So what happened starting around 2017, the attackers figured this out and they start publishing components into the repository that have confusingly similar names, basically a typosquat of a name. And since there’s no namespace enforcement, it’s very hard for consumers to tell the difference between am I getting the legit component or not?

And you couple that with the fact that the tool is going to auto-update these versions all the time, which means if somebody were to compromise an actual legitimate JavaScript project and put a fake component up there — and this has happened many times — the consumers will fetch it almost immediately. So you’ve created this situation where it’s easy for the attackers to put stuff in the repo and everybody will consume it almost immediately so you have a ready willing audience, which means you’re seeing on those ecosystems this massive stat we talk about, 350,000 known malicious component attacks in the last couple of years and it’s been doubling year over year. 

That’s only happening in those ecosystems. So we don’t have this problem in Maven because there’s not the auto-update and there is the namespace. But we’re having the massive attacks on these other ones because they do, right? So it’s sort of like these design decisions lead to different unintended consequences, I guess I would say.

CRob (11:08)
So let’s let’s talk about a specific example. Our friend Log4Shell that ruined many, many IT folks holidays in December a year or two back. I have an old stat: there were almost 250,000 known downloads of the malicious packages of Log4j which was about 29% of all the downloads at that time.  How is it that people are still grabbing that known malicious package? Why is that with such a widely known vulnerability?

Brian Fox (11:45)
(Laughs)  Yeah, I wish I knew, honestly. So I’m looking at the latest stats and anybody listening to the podcast, you can see them yourself. We have a resource center that’s been up since 2021. It’s at sonatype.com/log4j. So you can see those stats yourself. As we sit here right now, we’re looking at 405 million downloads since it was announced and worse the last seven-day average is 35% of those are of those non-vulnerable versions. And so it’s actually gone backwards in the last year. We were down at one point to, I think it was in October when we published the report, it was in the twenties and it took multiple years to get there, which was really disappointing, but it slid backwards for reasons that I have not been able to explain. 

And so, I also use this one sort of as the perfect bellwether for the reasons that you outlined, right? That it’s fairly easy to exploit. It’s fairly publicized. Everybody knows about it. And it was sort of one of these situations very early on that every vendor was getting asked by their customers, did you remediate this? And they would have to explain why. 

And so it created this situation that it was easier to just upgrade than it was to explain why you weren’t upgrading. So like I said before, I wouldn’t expect the uptake of every vulnerability to be 100% updates. In Log4Shell,  I think that is closer to true, and so we should expect to see the uptake here to be you know closer to, you know, 80, 90, 95% I would expect. I’ve done some research recently to look into the origin of this because you know people will often try to justify like, it’s just a few people with broken builds that are running all the time, right? Because it does seem incredulous. 

I’ve looked into the vulnerable downloads within the last month and they’re coming from millions of IPs worldwide. You can’t pin it down to, this is like a provisioning script that’s running on EC2 or something like this, right? Or some serverless configuration that might be happening in a Lambda, you know, weird things like that. No, it’s all over the map. 

And when I’ve looked at like the cohort of dependencies when I’ve taken the IP numbers that are fetching these vulnerable versions and I look at the cohort of dependencies to see like, is it one application everybody’s built building or something weird. Is it one place that’s causing this as a transit of dependency? I’ve not been able to put my finger on it. It is all over the map, which just tells me it’s kind of what I suspected in the beginning. It’s just average usage and folks for whatever reason just freaking haven’t upgraded. (Laughs) 

So it’s really disappointing because if it were any of the other things I mentioned, we could go attack that at its source and have a big impact. Instead, it’s messaging like this to get people to pay attention. And this is, it kind of intersects the SBOM area. If you can’t produce an SBOM, kind of implies you don’t know what’s inside your software. If you don’t know what’s inside your software, why should we expect that you’re doing a good job of updating it?

CRob (15:493)
So thinking about solutioning this a bit, do you have any advice for what developers or downstream consumers can do as they’re ingesting open source components to avoid this continual downloading of known vulnerable packages?

Brian Fox (15:15)
Yeah, I mean, tooling has existed for a long time to help you understand your entire transitive hull of your application. You know, Sonatype’s been providing this for, what year is it now? 14 years. (Laughs)So this is not a new thing. And you know, in the world, the regulated world, we’re seeing legislation all over the place from the US government, from European Union, PCI standards, everybody’s pushing towards, you need to be able to produce an SBOM. And this is part of the reason why, that it’s no longer acceptable to just blindly ignore what’s inside your software. And we saw for years organizations were only focused on the direct dependencies, the things their developers use, and ignored the transitive dependencies. 

But there’s more transitive dependencies than direct ones. So your odds are of pulling in something bad are even higher further down. It’s quite literally the iceberg. 70% of it is coming from these open source transitive dependencies. You need to have visibility in that because your customer is not going to accept as an excuse, like, why did you get hacked? Well, my direct dependencies were fine. It’s those indirect ones that were bad. Nobody cares. If you buy a pie from a bakery and you get sick, it’s not acceptable for them to go, well, it was my sugar provider that did a bad job here. Like I’m sorry like you know you still created this thing and sold it to me you’re still responsible. 

And I think that ultimately that’s what it’s gonna take that some form of liability reform to the point where organizations are actually responsible for the outcomes is needed to change this behavior. 

CRob (16:54)
Well, I think this is gonna be the first of an intermediary step in an ongoing conversation. And hopefully we can help raise th at awareness and get folks focused in on this unique problem. Let’s move on to the rapid fire section of the interview here. Got a couple questions and we’re gonna see what your thoughts are. First question, Brian, spicy or mild food?

Brian Fox (17:20)
Depends on the day, but let’s go with spicy today.

CRob (17:23)
(Sound effect “Oh, that’s spicy) Nice. Being a developerologist as your background, what’s your preference? Vi or Emacs?

Brian Fox (17:34)
Oh, Vi.

CRob (17:35)
Huzzah! What’s your favorite type of whiskey?

Brian Fox (17:41)
Ooh, ooh. I don’t know. I like variety. How’s that? I like to explore new ones. I have one that they make here — actually, it’s in Vermont, just over the border — they make it from maple syrup. And that one is really unique. So I’m gonna go with that. How’s that?

CRob (17:58)
All right, that sounds like a delight. And our final,  most controversial question, tabs or spaces?

Brian Fox (18:06)
(Sighs)  Spaces.

CRob (18:09)
Spaces, very good. There are no wrong answers, but that’s interesting how that causes a lot of controversy.

Brian Fox (18:17)
Yeah, you’re not going to ask about, you know, Alman versus K&R? I mean, that that always is related to tabs and spaces.

CRob (18:24)
(Laughter) Maybe in season two.

Brian Fox (18:28)
Yeah!

CRob (18:30)
Well, thanks for playing along. (Sound effect: That’s so sweet!) As we close out, what advice do you have for  someone that’s thinking about entering this field, whether it’s being an open source developer or getting into the field of cybersecurity? What advice do you have for newcomers?

Brian Fox (18:46)
I think my advice is always the same. Pick something that you’re interested in, whether it’s robotics or build software, whatever, and go find an open source project and try to get involved. It’s a great way to learn a whole bunch of skills. I mean, to be able to learn how to write better code, but also how to navigate, you know, the inevitable politics when you have more than, you know, two humans involved. The communication skills, the politics, the collaboration. 

I think you can learn a lot from open source, especially if you’re, you know, let’s say in high school or college and you don’t necessarily have the ability to get a job here. You can go get some real-world experience through open source projects and there’s open source for basically everything. So you know if you’re into rockets or planes whatever go find something it’s out there. It’s even easier today than it was, you know, 20 years ago, right? And and that would be my advice. 

CRob (19:44)
And finally, do you have a call to action for our listeners to help kind of inspire them?

Brian Fox (19:50)
If your organization can’t immediately assess — if I were to tell you about a new vulnerability right now that you never heard of, if you can’t immediately assess — if you’re even using that component anywhere in your organization or further, you can’t quickly produce the list of applications that are using that, then you’re basically powerless to respond to this next problem, right? That situation I just described is what most of the world went through in, what, December 9th, 2021, when Log4Shell dropped on them. 

We have studies, it was in the 2022 report, and I think we probably repeated it in 23, that showed organizations that had tooling in place were mediated their portfolio of thousands of applications within days versus other organizations that spent six months doing triage. So if you can’t immediately have a system that can tell you, are you using this component anywhere, any version of it, and you can’t get to the point of saying, we are using this precise version in these applications, then you need to solve that problem immediately. If only to prepare for the inevitable next thing than to prepare for the legislations that are going to require you to have the SBOMs.

And I would add, if you have solved that, then you need to be looking at these intentionally malicious problems because those require different solutions. They’re not going to show up in SBOMS. They’re trickier because they’re attacking the developer as soon as they download them. So if you think you have your inventory under control, you need to ask yourselves, how would I know if a developer downloaded one of these typosquatted components that may have dropped a backdoor or might have had custom code that simply exfiltrated data directly in the open source? Your traditional scanners are not going to pick this up. So I guess that’s two things depending on where you sit on that spectrum.

CRob (21:39)
Well, excellent. I appreciate you have some amazing advice and those are some interesting things to think about and act on. As always, I really appreciate your partnership and your ongoing contributions to help make the whole ecosystem better, Brian. You’re an amazing partner.

Brian Fox (21:53)
Yeah. Likewise. Thanks, CRob, for inviting me.

CRob (21:55)
Cheers!

Announcer (21:56)
Thank you for listening to What’s in the SOSS? An OpenSSF podcast. Be sure to subscribe to our series of conversations on Spotify, Apple, Amazon or wherever you get your podcasts. And to keep up to date on the Open Source Security Foundation community, join us online at OpenSSF.org/get involved. We’ll talk to you next time on What’s in the SOSS?

Arun Gupta is vice president and general manager of Open Ecosystem Initiatives at Intel Corporation and the OpenSSF Governing Board Chair. Arun has been an open source strategist, advocate, and practitioner for nearly two decades. He has taken companies such as Apple, Amazon, and Sun Microsystems through systemic changes to embrace open source principles, contribute, and collaborate effectively.

On July 9-10, the OpenSSF will attend the 2024 OSPOs for Good symposium hosted by the UN. Arun and What’s in the SOSS? co-host Omkhar Arasaratnam will lead a session called “Engaging the Open Source Community.”

Following the symposium on July 11, attendees are invited to come to a secondary event, What’s Next for Open Source? It will feature a collection of curated workshops to discover how to build and gather the skills you need to move forward with open source. Omkhar is coordinating the security track and presenting opening remarks. Arun will offer closing remarks. 

• 02:13 – Arun’s general outlook on security and life
• 03:39 – Arun shares his personal background and illustrious career history
• 09:04 – Comparing the OpenSSF and the Cloud Native Computing Foundation (CNCF)
• 13:30 – Arun details his work with the United Nations
• 16:42 – Areas that a lot of security professionals are getting wrong
• 18:20 – Arun answers Omkhar’s rapid-fire questions
• 19:08 – Advice Arun would give to aspiring security professionals
• 20:40 – Arun’s call to action for listeners

• OSPOs for Good 2024
• What’s Next for Open Source event
• Arun Gupta’s LinkedIn profile
• CNCF homepage
• United Nations Sustainable Development Goals
• Get involved with OpenSSF

Announcer (00:01)
A quick programming note: On July 9th and 10th, the OpenSSF will attend the 2024 OSPOs for Good symposium hosted by the UN. What’s in the SOSS? co-host Omkhar Arasaratnam and today’s guest Arun Gupta of Intel will lead a session called “Engaging the Open Source Community.”

Following the symposium on July 11th, attendees are invited to attend a secondary event, What’s Next for Open Source? It will feature a collection of curated workshops to discover how to build and gather the skills you need to move forward with Open Source. Omkhar is coordinating the security track and presenting opening remarks. Arun will offer closing remarks. 

For more information, check out the links in this podcast’s episode description.

Arun Gupta soundbite (00:45)
Sometimes security folks focus too much on the technology. Take a step back. Have that empathy for the customer. Does the customer understand that language? Are you talking in their language? Is the intent of your dialog landing the impact on the customer who’s listening to that discussion? 

Omkhar Arasaratnam (01:03)
Welcome to What’s in the SOSS? I am your host and the general manager of the OpenSSF Omkhar Arsaratnam. And with us today, we have Arun Gupta. Arun, tell us what you do.

Arun Gupta (01:18)
Omkhar, thank you for having me here. I’m really happy and excited to be here. I am the Vice President and General Manager for Open Ecosystem Team at Intel. And that’s my day job. As part of that, I coordinate open source strategy across the entire company, whether it’s software, hardware, all through the stack, why we contribute, how we contribute, how do we bring alignment across different business units.

So that’s quite an exciting venture actually. In addition, because of Intel’s legacy, it allows me to do a lot of chop wood, carry water kind of work in the community. So I’m really fortunate and very grateful to be the chair of the OpenSSF governing board, in addition to the chair of the Cloud Native Computing Foundation governing board as well.

Omkhar Arasaratnam (02:07)
Holy cow, where do you find time to sleep? And you run as well, you’re a runner, is that right?

Arun Gupta (02:13)
I like to run. I think the running is what gives me… I was listening to a podcast this morning and it talks about self-compassion. And I think that’s something that I’m really big on. So it’s very important to be compassionate to yourself. Make sure you’re taking care of yourself so that you can do all of these other things. 

I must say I’m really blessed and fortunate in that sense that people like the way I think, like the way I operate, like the way I treat them, going back to Maya Angelou’s quote, really. So, and I think that’s what has helped me get into the leadership position. There are a lot of wonderful people in this world, but you know, making sure you are listening to people, engaging with people, taking care of them, being empathetic to them. Those are some of the traits that you really need to be in this leadership position. But it really, gives me a satisfactory feeling at the end of the day, being the governing chair of the two of the largest Linux Foundation foundations essentially, and drive them forward.

Omkhar Arasaratnam (03:15)
Your contributions to the community have been numerous and this certainly isn’t your first first day in open source. And I think your numerous contributions to the community is part of the reason why you’ve been elected to such prestigious positions within these two foundations. Can you talk to us a little bit about your history in open source? How long have you been doing it? How’d you get your start?

Arun Gupta (03:39)
Yeah, I grew up in India. I moved to the United States. I moved to the United States back in ‘98. And I was very fortunate to literally go to sun.com/jobs and apply for a job. And I was one of the original JDK team members. And gosh, over two decades ago, we started changing the culture at Sun Microsystems at that point of time. It was a very close source company, Solaris, Netscape application server, all that. 

And then that’s when we started changing the culture at Sun. How do we take this closed source application server and make it an open source application server? And we realized it’s not just about putting the source code over the firewall, but it’s really bringing that people process, culture change, essentially, all of that kind of coming together, essentially. And that sort of…so over 20 years ago is when that bug got into me and I found it very exciting. It’s like, wow, you know, this is core competency of the company and you’re putting that out in the open, but yet that allows you to collaborate with your partner and be able to compete with them as well. That was quite exciting. So back in 2003, 2004 timeframe is when I started getting into that movement and it was still new at that point of time. 

But then, over the last 20 years, that’s the only way I’ve lived and operated exclusively. From Sun, I went to Red Hat, where you will see on their walls of their offices, “First they laugh at you, then they fight with you, and then you win.” And that kind of mantra kind of gets into your blood because that’s the open source philosophy, right? Then I was at CouchBase, then I was at Amazon, part of the open source strategy team, where I was on loan to multiple service teams crafting their open source strategy. 

I remember launching Amazon EKS, Amazon’s managed Kubernetes service back in 2017, and educating the service team that, hey, how do you participate in the open source community? What does it mean? There’s a concept of social dynamics, social engineering that you need to understand. You can’t just submit a pull request and expected to be accepted. So I think that’s the norm that I taught. And then I was on loan to multiple service teams. 

After Amazon, I spent a couple of years at Apple and I was fortunate enough to craft their first open source program office. So I built their first open source program office, went all the way up to the multiple executives, building that case, why Apple should contribute to open source, and a lot of fun over there.

But over the last couple of years, Greg Lavender, our CTO reached out and he says, “Arun, we would like to build open ecosystem culture back at Intel.” And so I’m very fortunate enough here. After a very long time, I feel very happy and excited that all through my management chain to Pat Gelsinger, I don’t have to explain what open ecosystem is. They are the ones that are really pushing the boundary and the entire company is built on…we believe walled gardens prohibit innovation. We believe open ecosystem creates an equitable playground for multiple players to collaborate and also increase the total addressable market so that you can do more fun things on top of that. So I think in that sense, very fortunate to be working at Intel and very fortunate and blessed to be working in this open source movement for the last couple of decades.

Omkhar Arasaratnam (07:07)
What an inspirational story. And it’s, I will second that Intel is definitely one of the examples of an organization that really gets open source. As an old kernel guy, it always used to make me smile to see that the new bits for whatever the new processor was would hit the kernel well ahead of the Silicon being released to the street. And there was a big focus on upstream as well as maintaining the ecosystem that we all enjoy. So thank you Intel and thank you for the work that you do there Arun. 

Arun Gupta (07:41)
It keeps it sustainable. The reason we contribute is because, as you said, Intel has been the largest corporate contributor to Linux kernel for 15 plus years. We contribute there because our customers, when they buy a laptop from Fry’s or Best Buy or an online retail store, they expect when they download Ubuntu or whatever operating system of their choice, it would work out of the box and be able to leverage the latest processors.

And that’s the reason, honestly, we contribute to 300 plus open source projects, whether it’s Linux kernel, PyTorch, TensorFlow, Kubernetes, OpenJDK, and a wide range of projects, because it’s a customer obsession that truly gets us there. And that’s what makes open source sustainable as well.

Omkhar Arasaratnam (08:24)
See, I know you’ve been doing this a long time because you mentioned Fry’s and they’ve been defunct for three years.

Arun Gupta (08:30)
(Laughter) I still love that place. It’s funny because in our neighborhood, Fry’s have been converted into a pickleball court now here.

Omkhar Arasaratnam (08:38)
(Laughter) No kidding. We’ll have to play pickleball the next time I see you. 

Arun Gupta (08:42)
That’s right, yeah!

Omkhar Arasaratnam (08:43)
Switching gears slightly, let’s talk a little bit about the work that you do within Linux Foundation as the board chair for both CNCF as well as the OpenSSF. These are big tasks. I’d love to understand what similarities you see between the security community at the OpenSSF and the cloud native community at CNCF.

Arun Gupta (09:04)
A lot of commonality. They are both, as at Intel we call as, BHAG. Big Hairy Audacious Goals. Both these foundations have those BHAGs essentially. I mean, if you think about CNCF is about how do we make cloud native computing ubiquitous, no matter where you are? And similarly, OSSF, Open Source Security Foundation, talks about how do we secure open source software for the greater public good? 

But there is definitely a lot of similarity between the two foundations. They’re both Linux foundation sub-foundations. They both have a governing board. There are 28 members in CNCF and 23 in OpenSSF per my count this morning. They both have a technical body like CNCF has the technical oversight committee, and OpenSSF has technical advisory council. So both have that element. Now, CNCF also has a technical advisory group, which is about security, where they dig into the details of how do you secure cloud native infrastructure? Security is the most boring thing, right? I mean, it works until it doesn’t work and then everything breaks. So I think that’s a super important element. So you could…

Omkhar Arasaratnam (10:13)
When it’s done well, it’s very boring.

Arun Gupta (10:15)
(Laughter) Right exactly. (Laughter) So I think it’s very important that security is job number one, even in cloud native computing. You can make it ubiquitous, but if it’s not secure, it’s absolutely useless in that sense. So I think that’s the way they think about it. There is a tag security where there is deep focus on how do we make sure that we are making this secure? But so far, that focus has been only on the cloud native computing. And I think that’s exactly where OpenSSF shines up. 

OpenSSF is fulfilling a gap. which is looking at a bigger, broader landscape to identify how do we secure the broader open source software? That’s where tools like OpenSSF Scorecard, Salsa, Sigstore, these are the tools. There is no need for CNCF or any other foundation to create those. That’s where OpenSSF is bringing out these tools that will plug in right there the gaps that CNCF is feeling and any other foundation is feeling.

Within OpenSSF and CNCF, of course, there is a lot of collaboration, but the tools that OpenSSF are creating are available for the broader open source community. So whether you are Apache or Eclipse or in any other community for that sake, those tools are widely available. And let’s be deliberate, let’s be conscious about what kind of interactions can be done to make the cloud native computing more secure so that it fulfills both of our joint agendas and win -win situation. 

And honestly, the way OpenSSF looks at it is as we are creating tools, we can create the tools in silo, but if those tools are not implemented or agreed upon by other communities, again, they’re going to be meaningless. So really making sure that as we are creating this OpenSSF scorecard, how they could be adopted across a wide range of CNCF projects, whatever specifications we come up with, we created secure software development guiding principles. Like, how do you make sure that your software is built using a secure covenant? Now we could come up with a covenant, but really working with CNCF saying that, okay folks, as you are building your project, here are these guiding principles that you should be following. 

So I think in that sense, there’s a very strong cohesion between, the stuff that is being done by OpenSSF and then implemented by CNCF. And again, the idea is if there are gaps identified, there is a clear communication channel, which is more important so that they can give feedback to us. There is of course a public channel, but there is a strong backend channel as well, which enables that high bandwidth communication for the leaders to communicate and share details.

Omkhar Arasaratnam (12:54)
Absolutely, and we have definitely benefited from that back channel and I think the community has definitely benefited from the cohesion, as you put it, that’s been brought together. One of the reasons that many of us get involved with open source and a lot of us are passionate about open source is due to the fact that it’s a public good. I know you’ve done a lot of work with the UN as well and would love to hear your thoughts on the intersection of open source as a public good and what the UN envisages how open source can help the globe.

Arun Gupta (13:30)
Yeah, when the United Nations created these Millennium Development Goals — what they used to call as MDGs at the turn of the millennium, smack at the beginning of the century — those goals were, again, BHAGs, you know, big hairy audacious goals. No poverty, no hunger, no crime, racial, you know, minimize racial injustice, gender equality, beautiful climate policies, you know, policies and all of really wonderful audacious goals. 

And as I’ve been involved with the UN for the last year or so, it’s been really exciting and very humbling experience, because it’s very clear, you have these goals, but the way to solve these goals, of course, is a human element. But a large part of it is a technology element. So last year, I was involved with TED AI, which is a brand new conference, which is again a section of TED, a type of a TED conference that was started in San Francisco last year. 

So last year we worked with TED and the UN to run a hackathon. And the hackathon basically had about 130 participants from all over the country, which basically took a shot at how can we solve this UN sustainable development goals using open source technologies, leveraging AI and cloud native technologies, essentially? vSo that was pretty exciting. 

A couple of months ago, we had KubeCon Paris, and that’s where we had again a very tight collaboration with the United Nations and the Office of Technology within the UN. Really, really good discussion. There were folks from the United Nations who came to the cloud native hacks, which is basically the hackathon that we did at KubeCon, where they talked about the importance and the relevance of the Sustainable Development Goals. These were started at Millennium Development Goals, but 2015 they realized it’s not just about the Millennium, it’s about the sustainability of the humankind. So the name was changed from MDGs to SDGs. 

A very beautiful, a very humbling effort. And I’m very excited to continue that partnership with the UN going forward. Looking forward, we are going to KubeCon Salt Lake City. So we’re going to have a cloud native hacks over there. Highly, highly encourage to bring more and more such places where we can bring that UN hackathon to different events and make an impact to the SDG, essentially making the world a bit more sustainable.

Omkhar Arasaratnam (15:55)
Those are definitely some big, hairy, audacious goals, but also, I think, goals that are good for humankind. And it’s very encouraging to hear this kind of collaboration. I’ve been doing security for a long time. I’ve been doing security for about 20 years. But I always self-identify as a software engineer first that happens to have been doing security for a very long time. 

With that perspective, I personally find there’s a lot of things that security folks just, I guess in their intent of being incredibly security-oriented, that they miss from your perspective. As a software engineer for a very long time. What are security folks getting wrong? 

Arun Gupta (16:42)
Yeah, I think when I think about a conversation, I always think in terms of empathy, that what is my end customer? What do they want? What is the problem that I’m solving for them? That’s super important. Sometimes the security folks focus too much on the technology. Take a step back. Have that empathy for the customer. Does the customer understand that language? Are you talking in their language? Is the intent of your dialogue landing the impact on the customer who’s listening to that discussion? 

The second problem, which is funny enough, is not the technology. Humans are often the weakest link in security. So as security professionals, we sometimes overlook the importance of training and awareness programs for employees. Or we underestimate the potential impact of social engineering attacks. How we could have people just maneuver their way, particularly given how prevalent open source is, how 90 to 9 % of the infrastructure is relying upon open source. For two years, somebody could just social engineer their way into it and then plant something in the software is pretty dynamic. So I think how do we understand the social engineering part of it?

And I guess the last part really is the comms part of it. We need to work very closely with other departments — IT, legal management, developers — making sure the comms are being sent out on a regular basis, the trainings are being done regularly. So focusing on these elements would only make it that much more impactful.

Omkhar Arasaratnam (18:20)
Valuable insight is always Arun. We’re gonna move into the rapid-fire section now.  Okay, spicy or mild food?

Arun Gupta (18:29)
I would say spicy. I’ve always been a spicy person. I like that.

Omkhar Arasaratnam (18:32)
All right, text editors, Vi, VS Code or Emacs?

Arun Gupta (18:36)
Vim, actually.

Omkhar Arasaratnam (18:38)
Vim is the winner! Now this is a highly controversial question. Tabs versus spaces? 

Arun Gupta (18:44)
Oh, yeah, spaces, baby spaces. 

Omkhar Arasaratnam (18:47)
Spaces, all right!

Arun Gupta (18:48)
Yeah, I’m not gonna lose a relationship over it, but spaces it is.

Omkhar Arasaratnam (18:50)
(Laughter) All right, to close us out Arun, for somebody that’s entering our field today, maybe somebody that just graduated from an undergrad in comp sci or somebody that’s making a career change to move into our field, what advice would you have for them?

Arun Gupta (19:08)
Yeah, I was talking to a friend’s son actually, you know, this kid is in high school and up until now he wanted to be a lawyer. And then one day he just comes to the house and he says, I want to be a cyber security professional. And my eyes immediately lit up. I said, “Oh, that’s fantastic! What do you want to do?” And like, I had a very interesting conversation with him. And of course I pointed him to all the training and the certifications and the courses that are offered by OpenSSF. 

My general advice is with ChatGPT with so much of internet resources available, which were not available when I was in college or when I was growing up initially, there is no lack of knowledge. Have that genuine curiosity, dig into it. Don’t be afraid of AI. Embrace it, use tools like ChatGPT to bounce your ideas, build that prompt engineering skill. 

What do you want to really do? Dig into the why of it. Look under the hood, see what’s going on and what could you do? And most importantly, if you find there is a place where you can scratch your itch, do it, contribute. And the more you contribute, the more you collaborate, the more you get your name out there, the more you build the credibility. And, remember, it’s a marathon, it’s not a sprint. So be in it for the long haul.

Omkhar Arasaratnam (20:35)
That’s great advice, Arun. What’s your call to action for our listeners? What would you have them do following this episode?

Arun Gupta (20:40)
I would really encourage them, again, seems to be self-serving, but I would really encourage them to take a look at openssf.org. Look at all the wonderful resources, training, education, certifications that we provide over there. Take a look at that. Come to an event. Go to your local meetup. And the last one, which is very important that I’ve seen particularly people who are graduating out of college don’t have that imposter syndrome. You know, I was there exactly where you are right now 25, 30 years ago, and all it takes is perseverance, grit, and resilience. So just have that in you and roll with it.

Omkhar Arasaratnam (21:22)
Thank you so much, Arun. It’s been a pleasure having you and hope to speak to you again very soon.

Arun (20:21:26)
Thank you so much.

Announcer (22:27)
Once again, for more information about OpenSSF’s activities at the OSPOs for Good symposium and the follow-up event, What’s Next for Open Source, check out the links in the episode description of this podcast. And be sure to catch every episode of What’s in the SOSS by subscribing to the podcast on Spotify, Apple, Amazon or wherever you get your podcasts. And to learn more about the OpenSSF community, visit openssf.org/getinvolved. We’ll talk to you next time on What’s in the SOSS?