Malcolm: Big companies inform insiders and investors of their comings and goings through a steady stream of press releases. Written in plain language, press releases typically serve as a chronicle of the prosaic details of corporate life. If you were to scroll through the news releases from IBM from last May, you would see news of an AI collaboration, updates to the IBM consulting service, a Sports Tech Startup Challenge, a new quantum chip manufacturing facility. You get the picture. But keep scrolling until you reach May 28th, a press release that dwarfs nearly everything else.

IBM and Red Hat today announced Project Lightwell, a $5 billion commitment backed by new frontier AI capabilities and a global force of more than 20,000 engineers to help enterprises secure open source software.

IBM and Red Hat—the open-source software leader that IBM acquired in 2019—are committing $5 billion dollars and 20,000 engineers to a cyber security project. Even in an age where we have become inured to very large numbers. These are very large numbers.

Keep reading. Paragraph four. The new release then lists just some of the companies that have already agreed to collaborate as early adopters.

Bank of America, Bank of New York, Citicorp, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa and Wells Fargo.

Four of the biggest banks in the U.S. The biggest bank in Canada. Two of the biggest investment banks on Wall Street. Two of the world’s biggest credit card networks. The firm that probably holds your 401k. Just for starters.

Press releases do not normally require explanations. This one does.

I’m Malcolm Gladwell. You’re listening to Smart Talks with IBM. A podcast where we explore how AI and emerging technologies are reshaping the way businesses and industries operate. In this episode, I want to explain why one of the world’s largest technology companies felt compelled this past spring to launch one of the largest dedicated commitments to open source security to date. And why the minute they did, much of the financial services industry raised their hand and said—count me in.

Malcolm: You are the head of information security for a large, very large multinational bank.

I put the question to Munish Sharma. The Chief Information Security Officer for Wells Fargo, one of the early adopters on Lightwell.

Malcolm: Why did Wells Fargo participate?

Munish: What we’ve seen with, um, the progress in, in AI is—uh, has created an, an element of urgency about, uh, about everything from maintenance to lifecycle management to, uh, to operational stability, every aspect of it. So it’s really in the past few quarters that we have, have—we’ve started to look at things differently.

Malcolm: Anthropic released Mythos, in preview mode, just six weeks before the launch of Lightwell. A frontier AI model so powerful that Anthropic, its developer, said that it would “surpass all but the most skilled humans at finding and exploiting software vulnerabilities.”

It’s right there in the press release—paragraph three:

Anthropic recently reported that its Mythos Preview model identified nearly 3,900 high- or critical-severity vulnerabilities in open source software alone.

Thousands and thousands of critical vulnerabilities.

Malcolm: But there was a moment where you’re like, “Oh,

Munish: Yeah.

Malcolm: Give me a kind of more specific understanding of that. So when we, when you say the pace has changed, it’s gone from what to what?

Munish: Potentially from, um, days and weeks to, to minutes.

To understand the urgency behind Lightwell, you have to understand something about software most people never think about: open source. Unlike proprietary code, open source software isn’t controlled exclusively by one company or person.

Malcolm: In a hypothetical universe where there is no open source- where- uh, where code is written the way music lyrics are written. Books are written they’re owned exclusively by the person, by the creator, how does that affect the shape of the digital revolution?

Gunnar: Well, s- so actually, I’m going to correct you.

I’m talking to Gunnar Hellekson. Who runs the Lightwell Initiative for IBM and Red Hat.

Gunnar: In fact, open source only works because of copyright. Mm. So what happens is I write a piece of software, I have the copyright to it, and I use that copyright not to, not to say all rights reserved and restrict access to it. I use those same rights to then, I can now ascribe those rights to other people, right? What was most clever about open source is it kind of inverts the intent of the copyright law and It turns it into a tool for sharing as opposed to a tool for restriction. Yeah.

Malcolm: But- But, books and music are not written as tools for sharing. No, but- There’s a million books I’ve read where I’ve said, “I could make this make this better-“ “... and I’m and I’m not allowed to.

Gunnar: Yeah, that’s right. Yeah. That’s right. And so the, uh... So but the m- the mechanics of, the mechanics of sharing become important, um, because using the copyright law, you can actually ensure that things are shared over time and consistently. So if I write a piece of software and I give it to you, you can improve it, but the license stipulates that you then also have to share any improvements that you made, right? And so in this way, it becomes, uh- Mm ... uh, it, it kind of f- folds in on itself, right? Yeah.

Open source software often works in tandem with proprietary code. Imagine a pyramid. At the top of the pyramid is the specific, carefully tailored code that an individual company might use to solve a specific problem. That code is typically written in house. Or purchased from a software company. It’s curated. It’s controlled, systematically. Someone’s in charge of it.

But beneath that sits something much larger: billions of lines of open source code. Shared software components or “packages,” built collectively by developers all over the world over decades. Anyone can use them. Anyone can improve them. Someone fixes a bug, submits the update to the volunteer running that particular package. And the project evolves.

A famous essay in the technology world refers to these two models of software production as the “Cathedral” and the “Bazaar.”[1] The Cathedral is quiet and composed and hierarchical. The Bazaar is sprawling and noisy and chaotic. And the argument in the essay was that the Bazaar—against all expectations—was far better suited for the kind of creative work that produces innovative software. Here’s an excerpt from the essay describing the emergence of the most famous of all open source projects, Linux, started by Linus Torvalds in the early 1990’s. The operating system that would become the backbone of modern computing.

I believed that the most important software… needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

Linus Torvalds’ style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.

The fact that this bazaar style seemed to work, and work well, came as a distinct shock.

Malcolm: Could we have gotten to the level of technological sophistication… that we have today ... without open source?

Gunnar: No. No.

Here’s Gunnar again.

Gunnar: Open source is so widespread right now. Aircrafts in the sky, waterworks, electricity, roads, governments, um, they all rely on software that was largely developed by volunteers, uh, who were just scratching their own itch, right? Um, and no single firm could capture all of that work. Couldn’t afford to pay them, right? Um, and even if it could, the innovation loops that happen in all of the sharing would be confined to that one firm. It would be very, very difficult for three or four of these firms to, to share the information as easily as they can with open source.

To give you a sense of the scale of open source, GitHub—the largest archive of open source code—has over 420 million software packages in its library. 230 new repositories were created every minute in 2025. That year, software developers around the world made just under a billion commits to that archive. This year, in 2026, GitHub is seeing over 2 billion commits a month due to an explosion in AI-assisted coding… Open Source is massive.

But the very thing that makes open source so dynamic—the fact that there is no central controlling authority—is also what makes it so fragile.

So who actually worries about the security of open source code?

Gunnar: So as the software graduates and moves into commercialization, it’s real clear, right? There’s not just one, but probably several companies who are interested in making sure that that software is secure, right? So things work really well at that point. Yeah. So really what we’re talking about is the software that doesn’t quite get swept up in the commercialization process, but it’s still essential. Um, and the way I just described it makes it sound like that’s like five percent of the problem across the, all of IT. It’s about 60 to 70% of the software that we’re running falls in that chasm, uh, between it’s not actually commercially supported, and it’s not software that the, uh, company has written itself. We call them dependencies, right? Um, so these are software that we need to go write other software, right? Um, and that’s, uh... To date, we have not tended not to think very hard about the security of those dependencies.

Much of the software underneath modern life doesn’t belong to anyone in particular. Which raises an obvious question: if everyone depends on it, who’s responsible for maintaining it?

Jen: Well, this is the whole thing about open source software is it’s incredibly important, and it is maintained by a relatively small number of people. And so you can think about these enormously consequential projects that we all rely upon, basically maintained by a handful of people. And that’s been the biggest issue of it, sort of industrial use and then artisanal scale maintenance. And because of where we’re at right now with respect to, uh, infrastructure and software being under increasing threat, given these very powerful AI capabilities, there’s now been a big flashlight on, wow, we depend on this open source software, but it is maintained by, in a lot of cases, volunteers.

That’s Jen Easterly. She has spent her career thinking about risk — first as a soldier and intelligence officer, later inside the cybersecurity establishment, and now as the head of RSAC, one of the world’s leading cybersecurity conferences and communities.

Malcolm: Talk a little bit about your own path to worrying about this problem. How did you get into this?

Jen: Uh, yeah. I mean, a, a pretty circuitous path, to be honest. Um, it sort of started out right after my 18th birthday, where I entered the gates of the United States Military Academy at West Point

Malcolm: Easterly was in the military for the fall of the Berlin Wall. She served on the ground in Haiti, Bosnia, Kosovo, Somalia. She returned to West Point, to teach economics.

Jen: And I was there during 9/11, where the world changed again, and the next decade became all about terrorism. I was at the White House working for Condi Rice as her executive assistant and then went off to the National Security Agency, of course, the world’s largest and most powerful intelligence agency, and I was there for over a decade in Iraq, in Afghanistan, and that’s where I got into cyber.

Stood up the Army’s first cyber operations battalion, went to stand up US Cyber Command, uh, and then ended up in the private sector at Morgan Stanley and then at CISA, which is America’s Cyber Defense Agency. And now, uh, I run the largest platform for cyber security. And so a very circuitous path, which all kinds of different threats, but right now a huge focus on cyber—

Malcolm: It’s the, the craziest career path I’ve ever heard.

Jen: It is a little crazy.

Malcolm: Easterly is, in the world of cybersecurity, a unique figure. She’s a soldier and a strategist, not a coder. She’s spent her career moving between the military, government, and the private sector—not growing up in Silicon Valley. And most of all, she’s someone who has spent her career looking at problems through the lens of national security and resilience: Who threatens us? Where are we vulnerable? How do we reduce risk? And how do we make the systems we depend on harder to break and faster to recover when they do? That combination has given her an unusual and influential voice on cybersecurity. And one of Easterly’s mantras is: the world does not have a cybersecurity problem. It has—and, to her mind, this distinction is crucial—a software quality problem.

Jen: So security has always been a bolt-on, right? Right, that’s arguably what’s created the multi-billion dollar cybersecurity aftermarket.

Malcolm: What she means is that cybersecurity is thought of as a layer, added to software, after the fact. Often by someone other than the original software developer. To keep the software secure. Her question is—why isn’t the security baked into the software itself? Answer: Because the incentive structure around writing software is all wrong.

Jen: Yeah, it would’ve changed everything. I mean, it comes down to, without getting too, too geeky or-

Malcolm: No, you can get geeky.

Jen: Okay. All right, brother.

Malcolm: This is IBM Smart Talks. You can be geeky as you want.

Jen: All right, we’re going to do an, a quick Econ 101.

Jen: So it all comes down to, like, basic economics, right? Goods, right? So y- you know, you have search goods where, uh, you can tell the quality of a good before you buy it: pair of shoes, nice shirt.

And then you have experience goods. You tell the quality after you buy it, like a meal in a restaurant or a nice, you know, trip, right? But, but software security is a quintessential credence good. What does that mean? It means that a person can’t actually tell the quality of a good before you purchase it or even after you purchase it.

So the average human is not going to look at a piece of software and say, “That is the most secure software. That is the best, most resilient code ever,” or, “I am definitely going to get hacked and all my money’s going to get stolen.” You, you can’t look at that, right? And so because of that, uh, consumers don’t really know what to ask for, and so the makers of the software were never incentivized to prioritize it.

They were incentivized to prioritize getting that product to market first or driving down the cost. And so you have basically a classic market failure where the market is not going to reward something that consumers don’t actually care about. And then the further problem is what happens... You know, how do you fix a market failure?

Well, the government steps in with regulation to protect consumers. But in this case, the technology vendors who make this stuff have said, “You know, at the end of the day, these flaws, these defects, these vulnerabilities, they’re just the cost of doing business. You know, we’ll tell customers that there’s a flaw and you need to patch it and just take care of it after the fact.”

And so there’s never been any sort of technology regulation. There’s never been any sort of a software liability. So anybody who buys software, I challenge you, whether you’re a corporation or an individual, look at that contract that you sign, and somewhere on that contract, it will say, “You buy this product entirely at your own risk.”

I guarantee you it will say that. And of course, we all check that box. But essentially, we’ve set up a world where software quality is not prized. And so that’s where developers have never been, you know, security has never been the number one thing that developers have focused on. It’s not, certainly not a malicious thing.

It’s just they’re writing code, and they are moving out products, and there’s not been this incentive, um, to write secure code.

Malcolm: With open source software, this misalignment of incentives is in some ways even more pronounced. Because you have this far flung group of developers, working independently on a single project, improving, evolving, in fits and starts. Some things just fall through the cracks. Here’s Gunnar again…

Malcolm: Why isn’t the open source innovator in the beginning, um, motivated to make the, the code as secure as possible? Are they indifferent to it, or the, do other things take priority, or what’s the kind of-

Gunnar: Yeah. Well, it’s a, it’s a combination of things. It’s, uh, uh, the... Do—Well, do you brush your teeth every day?

Malcolm: I do.

Gunnar: Oh, okay. That’s a bad example then.

Malcolm: My children…

Gunnar: So, so do they know that they need to brush their teeth every day? Yes. Will they actually brush their teeth every day? No. We’re all human. We all have reasons. And an open source project maintainer may, uh, they may not have the skills or the wherewithal to actually make the software secure. That’s very common because making software secure is a dark art, right? It’s very, it’s very complicated. Um, and it could be also that they were distracted, right?

They could be that they started a project that was very, very promising, but then they got married, uh, they got a dog, and they got distracted. They got a new job, and now that software got picked up by somebody else who didn’t go back and, and check the code. Yeah, there’s lots of reasons why.

Malcolm: Historically, that kind of messiness was manageable. The bazaar would inevitably get around to identifying and fixing the most serious of vulnerabilities. Before AI comes along, developers have an intuition about how safe a piece of software is. And what AI does is it says those intuitions tended to radically underestimate vul- number of vulnerabilities.

Gunnar: Yeah.

Malcolm: How radically?

Gunnar: Uh, quite radically. The number of vulnerabilities that, that we, we joke internally that a, a lot of the vulnerabilities that we’ve discovered are old enough to vote. Um, they have been in software for 18, 20 years.

Malcolm: people just never-

Gunnar: Yeah. Just never looked or never had an AI that had the patience to look, right? Yeah. Yeah.

Malcolm: In the world of cyber security, vulnerabilities are given a grade on the Common Vulnerability Scoring System more commonly referred to as a CVSS score. The CVSS scale measures how serious a vulnerability is.

Gunnar: So if you say that my piece of software has a critical vulnerability, cool, I’ll go fix the critical vulnerability, and then we’re good. Um, but to date, we’ve said, “Well, if you’ve got 10 low vulnerabilities,” it’s kind of like, well, I could go fix it, but it’s actually probably even more disruptive and risky to fix it than it is to just leave it alone, so we’re just gonna let it be.

And we kind of, as an industry, we kind of collectively decided over the last 25 years, like, when we get these low cr- impact vulnerabilities, let’s just leave them be. It’s riskier. It’s too risky to fix them.

Um, so any one of these things is not very important, but when you chain them, when you chain five or six of them together in a very specific way, now suddenly they become critical. That is one of the, um, that is one of the consequences of, of now that we’ve pointed AI at this problem, um, that’s one of the things that we’ve collectively come to its realization.

We’re talking about not just second order effects, but third, fourth, fifth order.

It’s like chess. This one move doesn’t appear to put me in any peril, but what I’ve done the first round, will come back to haunt me five rounds in… and by then, I’ve lost.

Malcolm: There’s a flip side to this, though. And that’s where the story turns optimistic. If AI has made it much much easier for bad actors to find vulnerabilities, it has also made it easier for the good guys to fix them. Here’s Munish Sharma again. Who has the massive responsibility of ensuring digital security for a major institution - Wells Fargo.

Munish: we’ve quite literally used AI to, to sort of combat the risk of AI. And what I mean by that is we’ve developed automated capabilities using AI to be able to fix, you know, what we detect in our software.

Malcolm: Like any competitive struggle—from a sporting match to human warfare—competition involves a constant back and forth between defense and offense, with each side having a momentary advantage—and while the advantage in software is to the attacker right now, that shouldn’t always be the case.

Munish says he’s also seeing the balance shift with some of the new AI tools.

Munish: done the right way, architected the right way, I don’t think it’s easier or faster for AI to identify than to mitigate. Uh, you know, obviously there is going to be a little bit of a lag between those two, but it’s not orders of magnitude.

Meaning it’s not as if you can find things, uh, in a day and it takes you months, uh, to, to patch them or to, to mitigate them. If that’s where, uh, uh, an institution is, uh, I’d be a little concerned. So your ability to respond to things, um, has gotten a lot faster as well. // It’s not, uh, one-to-one mapping between finding and, and, and resolving. Usually it’s, you know, one to many. But, uh, using AI, you can very efficiently, uh, create, um, an architecture where you’re able to respond to those threats way, way faster. And that’s our area of focus.

Malcolm: Can you give me a kind of a, a rough sense of how much that gap has closed in recent months?

Munish: It’s, it’s it’s closing pretty, pretty, pretty fast. And it’s closing pretty fast at, at most institutions that I talk to. And let me give you an example. Uh, in terms of scale, you are now seeing not a factor of two times or three times the number of fixes, uh, to critical and high vulnerabilities. You’re seeing a magnitude of, of 10X, uh, 20X, uh, within the same window of time. So if an organization was, was mitigating, let’s say, 100 vulnerabilities, critical or high in a month, our ability to, to patch that is, is order of magnitude faster now, uh, than it was in past.

If you are someone sitting on a mountain of open source code—of uncertain integrity—all is not lost. The same technology that threatens you can also help save you. But you have to be organized. You need a strategy. And you need a partner.

Malcolm: The AI company Anthropic released a preview of Mythos—on April 7th of this year. The model was so good at finding vulnerabilities in software, Anthropic said, that it would give a select group of partners—mostly tech, cybersecurity, and critical infrastructure organizations—two months of early access, so that they could prepare themselves for Mythos’s extraordinary abilities. The same day Treasury Secretary Scott Bessent and the chair of the Federal Reserve, Jerome Powell, summoned the CEOs of the country’s top banks to a closed door meeting in Washington, to warn them that AI was posing an unprecedented threat to the banking community. Financial firms have always been high on the hacker’s list of preferred targets. As the notorious bank robber Willie Sutton famously said, in response to a question about why he robbed banks, “that’s where the money is.” The digital world isn’t any different.

Lightwell was the logical next step. IBM’s Red Hat was already in this game: their flagship business is aimed at bridging the gap between the open source software systems and corporate users.

Hellekson said that they had talked about doing a wider effort for years. But had always dismissed the idea because it seemed too ambitious: too much code to manage, too many people to hire. But, he says, “once Mythos was announced we realized the urgency of the problem and that we finally had the tools we needed to solve it.”

By the end of May Lightwell was up and running. And one by one the banks—many of whom had been at that April meeting at the Treasury Department—signed up. The problem was so large, they realized, they couldn’t tackle it on their own. This is Munish Sharma again on the scale of the task of securing open source code.

Munish: So it is, it is large. It is humongous in terms of how, um, integrated it is in, in the overall, uh, software stack. Um, in our ability to manage it, that’s where the various institutions are coming together.

Um, and, you know, we are taking a systematic stance on it, you know, instead of trying to fork off and starting to manage the packages ourselves, which is one way of doing things. Uh, another is to partner with the, with the industry and, and really come at it together. So I think there has been a lot of focus on this in the past few months and through various, uh, institutions, um, including Lightwell, where we are focused on making sure, uh, that we, uh, extensively scan and understand the, the security risks within the open source packages that have been consumed.

Malcolm: You talked about partnerships, what are you looking for in a partner? What is it you need when you look outside your own organization?

Munish: So first and foremost, uh, it’s the first thing I’d look at is their ability to scale. Uh, and followed by a mindset that is security first. So this, this, this has to be a sustainable at scale solution. It’s not—We’re not talking dozens of packages. We’re not talking hundreds of packages. We’re talking tens of thousands of packages.

Malcolm: So. Lightwell. 20,000 people and $5 billion. Big. Because it has to be big. It offers a repository or network of fixes and components.

Gunnar: Lightwell is a clearing house for open source vulnerabilities. Uh, companies join the clearing house. They submit their vulnerabilities to Lightwell. Lightwell fixes those vulnerabilities and then delivers them back to the customers and to the open source communities they came from.

Malcolm: And you said you... Do you have 20,000 people or you want to have 20,000 people?

Gunnar: The aspiration is, uh, 20,000 people dedicated to the effort of securing open source software.

Malcolm: It’s an ... astonishing number.

Gunnar: It’s an astonishing number, yeah.

Malcolm: And are all these people going to be in one place or scattered throughout?

Gunnar: No, necessarily they have to be scattered.

Malcolm: How busy has it, have you been?

Gunnar: Extraordinarily... I’ve been at Red Hat for 20 years, um, and I was talking to another, uh, old head at, uh, at Red Hat, and, uh, he, he and I had the same impression.

It’s like, this is what it, this is what Linux felt like when we were first, when we first caught the wave of Linux adoption 20, 25 years ago. This is what it felt like. Um, everyone understood what needed to happen. Everybody was, uh, nobody really knew how it was supposed to work in its entirety, um, but everyone was kind of rushing in to figure it out, and that’s, it feels very much the same.

For Easterly, the moment we are in reminds her of the early days of the Cold War. A super weapon arrived, posing an existential threat. But what happened? The world responded. Built institutions. Learned how to protect itself. She’s an optimist, by nature.

Jen: And so we’ve actually created an environment where defenders are at a massive disadvantage because of the way that technology was created with these flaws and defects. Now, the great news is, what we can see with these AI tools as they become increasingly powerful, they can actually shift the advantage to defenders by creating much more secure and much more resilient code than we’ve ever had before, and importantly, helping us to transform and refactor a lot of the insecure legacy code that we’ve been dealing with for decades and decades.

And so I wrote a piece last year that was called “The End of Cybersecurity: An Optimist’s Guide to,” you know, “Improving Software Quality,” and it was all about how we can look at AI as a cure for insecure code. So I do believe in the next couple years, we can actually see a significant reduction in cyber risk, a significant improvement in software quality.

But the path to get from here to there I think is going to be pretty rocky, because in the short term, attackers will have an advantage by using these AI tools to more rapidly find those flaws, those defects, those vulnerabilities, and potentially weaponize them. So in the short term, the advantage goes to attackers.

In the long term, it goes to the defenders.

Malcolm: In the end, maybe that’s why this press release felt different. It wasn’t simply announcing a new product or partnership. It was announcing a recognition: that some of the most important infrastructure in the modern world is shared infrastructure. And shared infrastructure requires shared defense.

Before you go, we’re trying something new. If you have a question you’d like to ask an IBM technical expert, submit it at ibm.com/smarttalks. We’re exploring ways to bring your questions directly to the experts and we’d love to hear what’s on your mind.

Smart Talks with IBM is produced by Matt Romano, Amy Gaines McQuade, Trina Mannino, and Jake Harper.

Engineering by Nina Bird Lawrence. Mastering by Sarah Bruguiere. Music by Gramoscope. Strategy by Kassidy Meyer and Elina Choi.

Smart Talks with IBM is a production of Pushkin Industries and Ruby Studio at iHeartMedia.

To find more Pushkin podcasts, listen on the iHeartRadio app, Apple Podcasts, or wherever you listen to podcasts.

I’m Malcolm Gladwell.

This is a paid advertisement from IBM. The conversations on this podcast don’t necessarily represent IBM’s positions, strategies or opinions.