Over his roughly three decades in the open-source software industry, including the last two at Red Hat, Chris Wright has watched the sector evolve from a once niche technical field to a mainstream building block of enterprise infrastructure. As Red Hat’s chief technology officer, Wright now oversees engineering across the company, from emerging-technology research to product development and ongoing support of products already in the market. In a recent conversation with McKinsey Senior Partner Martin Harrysson and Associate Partner Shilpa Khatana, Wright discussed how a recent wave of AI-driven discoveries of code vulnerabilities is reshaping trust in the software industry and why he believes the industry will emerge from this moment more secure.
This interview has been edited for length and clarity.
Martin Harrysson: You’ve been at Red Hat for more than two decades, and in the open-source community, including early years involved with Linux, for around three. What strikes you about where open source finds itself today?
Chris Wright: It’s a fascinating time for open source. Over 30 years, it went from a fringe, hobbyist activity to something pervasive across every industry—consumer, enterprise, small business, data centers, devices. Open source is foundational to the global economy today. The vast majority of enterprise codebases—well over 80 percent, typically over 90 percent—contain open-source components. Every hyperscaler and every large consumer platform runs on open-source infrastructure. It’s entrenched, and it’s fundamental to our future.
Now it’s back at the center of the conversation, this time because of cybersecurity concerns and AI’s role in scanning code and even building models with open weights. There’s a full-circle aspect to it: Many of the same debates we had decades ago about trusting open source are resurfacing in a new technology era.
One of open source’s greatest strengths is also what’s driving today’s concerns: It’s open. Anyone can access the code, learn from it, and build with it; that’s real democratization of technology. Now that AI models have been trained on the internet, including a huge amount of open-source code, they’ve become remarkably capable at understanding, writing, documenting, and finding issues in code.
Martin Harrysson: Given those real concerns, how do you see AI reshaping open source’s role and importance?
Chris Wright: Starting around the middle of this year, a new class of cybersecurity-focused models—beginning with Mythos and the Glasswing project, and followed by efforts like Daybreak—began uncovering vulnerabilities that had been sitting latent in source code for years, in some cases upward of two decades. Some are individually exploitable; others are chains of smaller vulnerabilities that together give attackers a path to escalate privileges or break into systems. Because open-source code is visible and accessible, it has been the natural target for this kind of scanning.
That’s produced a narrative that open source is somehow uniquely insecure. I think that’s the wrong conclusion. Open source has always made a virtue of transparency—sunlight is a disinfectant. You can see exactly how a cryptographic algorithm is implemented rather than being told to just trust a vendor’s word for it. And the community development model brings a much broader set of eyes to any given piece of code than a small proprietary team ever could. That means faster discovery and faster remediation—there’s no hiding behind security through obscurity.
Martin Harrysson: So you see this having a positive overall impact?
Chris Wright: What’s happening now is that AI has made it dramatically cheaper to scan all of that code at once, so we’re seeing a concentrated burst of vulnerability discovery. It’s a genuinely uncomfortable moment: Customers are worried, and rightly so, because open source is so pervasive that they often lack full visibility into what’s actually deployed, especially when it arrives bundled inside third-party or commercial software. But I’m optimistic about where this ends. We’ll come out the other side having raised the bar for security across the board—more scanning, faster patching, and security testing built directly into project pipelines. Efforts like Daybreak, which has talked about “patching the planet,” are genuinely global in scope in a way that would be much harder to achieve if we were only securing smaller, more fragmented, proprietary codebases. And this is exactly what Red Hat and IBM are doing with our Lightwell initiative: making open source safer for enterprises.
Martin Harrysson: In the near term, what should a CIO, CTO, or CEO be doing about this?
Chris Wright: I’d point to three priorities—two are basic hygiene, and the third is more about where this is all heading.
First: Know what software you have and where it’s running. If you can’t produce something like a software bill of materials or a dependency graph across your enterprise, you have no real way to assess your risk. That visibility also helps you prioritize—not every system carries the same value or the same exposure. A database full of sensitive information behind several layers of firewalls is a very different risk profile than a public-facing service.
Second: Build the automation to actually act on what you find. Imagine every vulnerability in your environment has already been discovered. Now you need to patch potentially hundreds of thousands of dependencies across your infrastructure. If your patching process still involves months of manual review and a spreadsheet, you will never catch up—the backlog will always outrun your capacity. Mature CI/CD and DevSecOps practices, which the industry has been building toward for years but hasn’t fully adopted everywhere, are what make addressing that kind of scale possible.
Third, and this is more forward-looking: The industry needs to keep building the tools such as scanning, exploit research, and mitigation techniques that let defenders keep pace with attackers. Right now, I think attackers have the upper hand. We’re going to discover entirely new classes of vulnerabilities, not just new instances of existing ones, and each new class will trigger a fresh wave of activity. I think we’re heading toward a world where both attack and defense increasingly happen at machine speed—agents defending against agents, rather than relying on human-speed response.
Shilpa Khatana: Who should own this? In most enterprises, we see engineering taking on more responsibility for security, but there’s also a dedicated cybersecurity function, risk, governance, and now often an AI council. How should those groups divide the work?
Chris Wright: It’s a shared responsibility, but with real specialization by role.
This builds on the shift we made with DevOps and then DevSecOps—bringing security earlier into the development process, on the theory that a vulnerability caught early is far cheaper to fix than one caught in production. But developers aren’t security specialists, so DevSecOps also means building automation and gates into the pipeline that give developers visibility into security issues without requiring them to become experts themselves.
The application development team owns what’s deployed and where—they’re best positioned to know what dependencies went into their software. One thing I don’t think is well understood: When you write code, you take responsibility for it, but the moment you pull in a dependency from the internet, you’ve taken on responsibility for that code as well, even a small, stable utility you’ve never had reason to question.
At the same time, other teams need to specialize in things individual developers shouldn’t be expected to do alone: “red-teaming” at a systems level, setting compliance requirements as a CISO function, and translating policy into automated checks embedded in the pipeline. So you end up with a CISO setting requirements, teams turning that into policy as code, and development teams having responsibility for what they build and what they pull in. It’s shared, but each group brings a different kind of expertise.
Software development: Leading the AI revolution
Martin Harrysson: The rise of agentic AI adds another layer to this—agents are now writing code and can themselves introduce dependencies, sometimes through subagents. Doesn’t that complicate accountability?
Chris Wright: You’re still ultimately accountable if you initiated the work—that doesn’t change. But I agree these layers of abstraction can obscure what’s actually happening. We’ll likely see more issues introduced by people who weren’t being careless, just less aware of what an agent a few steps removed did on their behalf.
At Red Hat, we see a real spectrum in how teams approach AI-assisted development—similar to the broader industry. At one extreme, some teams genuinely don’t look at the code an agent produces. At the other, everything is handcrafted and reviewed by humans. Most teams land somewhere in the middle.
What gives the most AI-forward teams confidence that they’re not building something that will collapse under its own weight is that they’ve built a serious harness around the entire development and deployment process, effectively a system of checks at every stage. You define what “good” looks like for your codebase, simple principles like preferring simplicity over complexity or refactoring instead of letting the same rough code multiply. Then you build an adversarial reviewer (agent) that checks new code against those standards and sends it back with feedback until it passes. That point-counterpoint dynamic repeats at every stage of the pipeline: security scanning, penetration testing, active searches for exploitable code paths.
That adversarial structure is, I think, how we avoid trading one set of risks for another. It’s also why those leading teams aren’t spending all their time on manual code review—they’re spending it building and refining the systems that do that review for them.
Shilpa Khatana: Going back to your point about the risk of code quality degrading when teams don’t actively refactor or simplify: Have you seen AI accelerate the pace at which vulnerabilities, or technical debt more broadly, get created, simply because code is now so much easier to generate?
Chris Wright: I’d argue technical debt and security vulnerabilities are often two symptoms of the same root cause: code that was written quickly, without enough thought given to how it fits into the broader system. Humans have always introduced both by taking shortcuts under time pressure, just as AI can introduce sloppy or buggy code that’s harder to maintain and easier to exploit. We’ve built institutional processes over time to identify where we’re accumulating debt and to schedule work to pay it down. The task now is to take that same judgment, which used to live only in people’s heads, and encode it into the specifications, skills, and context we give agents.
There is one real difference worth flagging: Models are extremely good at optimizing for exactly the goal you give them, sometimes too literally. It’s the same failure mode you see when an agent “cheats” on a test because its only instruction was to pass it, and nobody told it not to cheat. We have to be explicit about what good architecture looks like, what it means to secure codebase, what constitutes technical debt, and how to avoid introducing it in the first place. And that needs to be built into the guidance we give development agents—alongside instructions to favor simplicity and avoid unnecessary layers of abstraction.
Shilpa Khatana: How optimistic are you that that can be managed effectively?
Chris Wright: What gives me confidence that this is manageable is that we’ve looked at how much code gets rewritten over time on real projects. Over a three-year window during a high-growth phase, a project like Kubernetes saw roughly 70 to 80 percent of its code rewritten. Even a mature, three-decade-old project like the Linux kernel saw about 25 to 30 percent of its code rewritten over that same three-year period. Code gets revisited and improved continuously, with or without AI. While it looks different with agents in the loop, I don’t see anything intrinsic to AI that makes technical debt a fundamentally bigger problem. It changes how precisely you need to specify what “good” means, not whether the problem is more or less solvable.
Martin Harrysson: What do you think is underappreciated in this area right now? Is there something you wish more executives were focused on?
Chris Wright: Some of it we’ve already touched on—understanding where you’re introducing risk through the software you build and the dependencies you rely on. Once you ship software, you’ve effectively become a vendor of your own product, with all the hygiene obligations that come with that—knowing what you’ve deployed, where, and how you’ll update it. This isn’t a new topic, but it tends to go in and out of fashion, and I think it deserves to stay in the foreground permanently.
I’ve spent a lot of my career in security, and one thing I’d urge leaders to do is get ahead of the narrative that open source is somehow inherently insecure. It’s not; it’s core infrastructure, and it’s something we can improve collectively faster than most alternatives.
The other area I’d point to is open models. The code underlying most AI infrastructure—agent frameworks, training libraries, harnesses—is reasonably well understood and often open-source itself, through projects like PyTorch. But we haven’t figured out the right collaborative model for open-weight models themselves: how we build them together and, more importantly, how we review a model’s content for efficacy, safety, and security once it’s built. We have decent guardrails, but the internals of how weights interact inside a large stochastic system aren’t well understood industry-wide. I’d like to see the same collaborative, transparent approach we’ve applied to open-source software—not just open weights, but open training data and training recipes, so the work is genuinely reproducible—extended to models themselves. That’s where I think the state of the art still needs to catch up.
Related Articles
