Eye On The Market podcast

(DESCRIPTION)

Presentation: J.P. Morgan, Eye on the Market. Logo: J.P. Morgan. Title card: The Summer I Turned Pretty. July 2026. Michael Cembalest, in a dark suit jacket and light blue collared shirt and wearing glasses, sits at a table with a glass of water, speaking to camera against a backdrop of a city skyline through large windows. A caption reads Michael Cembalest, Chairman of Market and Investment Strategy.

(SPEECH)

MICHAEL CEMBALEST: All right. Good morning, everybody. This is the July Eye on the Market podcast. This one's called The Summer I Turned Pretty, which I'll explain. And earlier this year on my TikTok feed, I was bombarded with all sorts of clips from a TV show called The Summer I Turned Pretty, which I never saw.

But I used it for a tagline here because this is the summer that I turned pretty cautious on two pretty important topics. And that's what we're going to talk about on today's podcast.

(DESCRIPTION)

Slide: The Summer I Turned Pretty cautious. A bullet point list.

(SPEECH)

Cautious about zero-day cyber attacks resulting from the latest frontier AI models. And that's going to be the bulk of the discussion on today's podcast, and also cautious about some market technicals and some growing challenges to the frontier labs from both new open and closed weight models.

And

(DESCRIPTION)

Slide: Movies we have seen before. Two line charts pair together. The left chart, titled Communications equipment vs services, 1999-2000, plots the S&P 500 comms equipment index against the S&P 500 comms services index, with the equipment index climbing steeply to a peak around early 2000 then falling sharply while the services index declines, annotated that comm equipment stocks kept rising after rollover in comm services, sourced Bloomberg, JPMAM, July 8, 2026. The right chart, titled Philadelphia semiconductor index & hyperscalers basket, plots a total return index from June 1, 2025, with the Philadelphia semiconductor index rising well above a hyperscaler basket of GOOGL, AMZN, MSFT, META, ORCL, both climbing through mid-2026 with the semiconductor index pulling sharply ahead after April, sourced Bloomberg, JPMAM, July 9, 2026.

(SPEECH)

let's start with some of the market technical issues. And there's a bunch of people that have been writing similar things. This is some work a colleague in the investment bank, Jason Hunter, has done. If you look back to the late 1990s, there was a point at which the communications stocks flatlined, even though the infrastructure stocks kept on rising.

And as a proxy for that, think about Juniper Networks and Verizon and things like that. So you had this period on the market where the front end, which was the communication services stocks, started a flat line, but the infrastructure stocks kept going, and it was a bit of a head fake to the market.

We're having a little bit of a parallel right now because the hyperscalers, which are the front end of this AI boom, are seeing their stock prices stagnate and their free cash flow fall, even as the semiconductor and other infrastructure providers and optical networking companies are continuing to go up. So there are some parallels here that I think we need to think about because you always want the caboose going slower than the front of the engine, and that's not what's happening.

There

(DESCRIPTION)

Slide: Serious challenges to frontier labs from both closed and open weight models. A scatter plot titled Artificial Analysis Intelligence Index score vs cost per task plots a composite benchmark score across ten evaluations for math, science, coding, and reasoning on the vertical axis against cost per task in US dollars on a log scale horizontal axis. Models are plotted as points colored by lab per a ColorKey listing Anthropic, OpenAI, Google, Meta, SpaceXAI, Amazon, NVIDIA, Mistral, Z AI, DeepSeek, MiniMax, Xiaomi, Alibaba, Moonshot. High-scoring models cluster near the top including Claude Fable 5, Claude Opus 4.8, Claude Opus 4.7, GPT-5.6 Sci, Kimi K3, Grok, GPT-5.5, Gemini 3 Pro, GLM 5.2, Claude Sonnet 5, Claude Sonnet 4.6, and Grok 3.7 Max, while lower-cost open weight models like gpt-oss-120b, gpt-oss-20B, and Nova 2.0 Pro Preview sit toward the lower left. A note on the chart explains that filled circles are closed models, white fill denotes open weight models, and models at the upper left maximize intelligence score per task dollar, sourced Artificial Analysis, July 2026. A J.P.Morgan logo sits at the lower left.

(SPEECH)

are also some serious challenges to the frontier labs-- and by that I'm obviously referring to Anthropic and OpenAI-- coming from a whole bunch of new models. And for those of you consuming this in video form, you can see this really colorful chart that's become somewhat standard in discussions about these different models.

On the y-axis, you have some kind of measure of their productivity and performance. In this case, it's a benchmark focused on math and reasoning and coding tasks from this group, Artificial Analysis. And the x-axis is typically in log scale. And importantly, it's not cost per token, it's cost per task. Because models can differ on the intensity of how many tokens they use and need. So it's better to just look at net of that efficiency. What's the overall cost of a task?

And this curve used to be such that OpenAI and Anthropic frontier models were way better than everything else. Now you can slide to the left on this chart. And Meta has a new model. SpaceXAI has a new Grok model. There's a new Chinese model where all of a sudden, you're looking at models whose performance isn't that different from the best OpenAI and Anthropic models at either a third or a tenth of the cost.

And so I can imagine, there's a lot of CFOs-- and I've spoken to some of them already-- that are starting to think about, hey, maybe these models can work for us on certain tasks. Not all of them, but some of them are having a bit of a sticker shock on the token bills that they've been paying.

So there's two pieces to the Eye on the Market that are coming out today. One of them is on the cyber issue. The other one is on these market technical and frontier lab challenges. And all that information is in the email.

(DESCRIPTION)

Slide: Two more open weight challengers: Inkling and Kimi K3. A bullet point list.

(SPEECH)

Just two quick things. Thinking Machines, which was launched by some people that used to work at OpenAI, finally released their model. And as expected, it looks pretty good. And it's a mixture of experts model. And I wouldn't be surprised if they were a serious challenger as well.

And you're probably hearing a lot about Kimi K3 from a company called Moonshot. It's Chinese. And just to give you a sense, it costs about 30% as much in terms of input and output tokens as some of the other best models with similar performance. So again, take a look at the Eye on the Market today for that.

So

(DESCRIPTION)

Slide: Podcast co-host: Pat Opet, Global Chief Information Security Officer at JP Morgan. A bullet point list.

(SPEECH)

today is a first. So I'm having a co-host on the podcast, which I haven't done before. I should probably do that more often because some of our listeners probably are tired of hearing me drone on and on. But Pat Opet is here, and Pat is the Global Chief Information Security officer at JP Morgan. And you've been at JP Morgan for more than a decade.

PAT OPET: Yeah, 12 years. 12 years.

MICHAEL CEMBALEST:

(DESCRIPTION)

The two men sit across a dark table facing each other in conversation, the city skyline visible through large windows behind them. Pat Opet, on the left, a man with short light brown hair and a trimmed beard, wears a light blue collared shirt with the sleeves rolled up and rests one arm on the table. Michael Cembalest sits on the right. The table front has a J.P.Morgan logo.

(SPEECH)

And Pat and his various teams have worked and helped me write a piece called "Patchmageddon the race to patch software vulnerabilities before zerpo-day cyber exploitations proliferate." There's a lot of jargon involved, but Pat's here to make sure that everybody understands in layman's terms as much as we can what's going on. Thank you, and welcome to the podcast.

PAT OPET: Well, thanks for having me. I'm excited to be here.

MICHAEL CEMBALEST: I might do this again. So

(DESCRIPTION)

Slide: Even before Mythos-grade models came along, cyber vulnerability disclosure exceeded patching remediation. A line chart titled Total common vulnerabilities disclosed vs patched, 2025 plots count on the vertical axis against months from Jan-25 to Nov-25. A solid line for disclosed vulnerabilities rises steeply to 48,185 disclosed, while a dashed line for patched vulnerabilities climbs gradually to about 7,500 patched, widening the gap across the year, sourced Mitiga.io Cybersecurity, June 5, 2026.

(SPEECH)

even before Mythos came along-- because Mythos was a bit of a shock to the system earlier this year. Even before Mythos came along, the data that your team shared with me shows that the pace at which vulnerabilities in the systems that big companies use were being found and disclosed at a much faster rate than they were-- than they're patched.

PAT OPET: That's right.

MICHAEL CEMBALEST: And like, what's it like to be inside a large organization where it's raining vulnerabilities and you have to patch them?

PAT OPET: Look, it's very difficult. And obviously, a lot of automation and tooling has been built over many years to help find vulnerabilities in software. But there isn't so much automation and tooling that helps organizations fix vulnerabilities. Fixing vulnerabilities requires putting new software in production. That often means that you have to do thorough testing to ensure that the new software you're putting in production doesn't break any other features.

And for companies like ours, where continuity of operation is very important for our customers, that's a very careful process. Multiply that by the various industries and the difficulty in perhaps reaching the software that has to be put in production, think like industrial control systems that aren't easily accessible, or teams that don't have sufficiently sized technical teams, it becomes really onerous to keep up with the rate by which vulnerabilities are being found.

MICHAEL CEMBALEST:

(DESCRIPTION)

Slide: Let's talk about TTE: time to exploit. A line chart titled Attacker time-to-exploit vs organization time to remediate plots days on the vertical axis against years from 2020 to 2026E. An organization mean time to remediate line stays high, rising from about 60 days to roughly 95 by 2026E, while an attacker time-to-exploit line declines from about 30 days toward zero and below by 2025 onward. A shaded region labeled Exploited before patch exists fills the area below zero, where 0 days marks when a patch becomes publicly available, sourced Sidero Labs, May 4, 2026.

(SPEECH)

So there's-- analysis differ here. But this chart is a proxy for how long does it take for organizations to remediate things that need to be fixed. That's the gold line. And then the falling blue line is time to exploit.

PAT OPET: That's right.

MICHAEL CEMBALEST: TTE. Why is that such an important concept for people to understand? Because I've been seeing it everywhere.

PAT OPET: Yeah. So when a vulnerability is found, it is a flaw in a piece of software that could be abused by an attacker. The exploitation process is the attacker actually abusing that software. And so typically, if you look back several years, teams had time, days between a vulnerability being discovered and an attacker weaponizing that vulnerability.

But through again, new tooling, and in particular, various AI systems, attackers can now exploit vulnerabilities much more quickly to the point where attackers are actually both discovering the vulnerabilities and exploiting the vulnerabilities before the defenders even they exist.

MICHAEL CEMBALEST: Yeah

PAT OPET: That is colloquially called a zero-day which is now dominating the headlines.

MICHAEL CEMBALEST: Yes. And in this chart in 2020, there was 30 days in between the disclosure of eligibility and its first exploitation. And those numbers have fallen basically to 0.

(DESCRIPTION)

Slide: Which industries are at risk? A lot of them, according to advisories. A horizontal bar chart titled Cybersecurity vulnerability advisories by industry plots count of advisories for 2025 across industries. Critical manufacturing leads near 300, followed by Energy and Transportation around 200 to 250, then Healthcare, Water and wastewater, Communications, Government facilities, Info tech, Food and agriculture, Chemicals, Financial services, Defense industrial base, Dams, Emergency services, and Nuclear with the fewest, sourced Forescout Technologies, February 19, 2026.

(SPEECH)

And obviously, what industries are at risk? A lot of them. And across a lot of different parts of the economy. And so it's not one particular industry is more at risk than others.

(DESCRIPTION)

Slide: Who conducts these attacks and why are so many "unknown"? A stacked bar chart titled Cyberattacks over time by threat actor type plots number of attacks from 2000 to past 2020, with bars segmented into Other/unknown, Individual hackers, Non-state group, and State/state-affiliated actor. Attack counts stay low through the 2000s, rise gradually through the 2010s, then spike sharply after 2020 to over 700, dominated by the Other/unknown and Non-state group segments, sourced ECB Financial Stability Review, May 2025.

(SPEECH)

The ECB put out this financial stability review. And I thought it was kind of spooky that the largest component of who's doing this fell into a category called unknown. Why is it so hard to know who's doing? Is it just the nature of it?

PAT OPET: Just what's called attribution and cybersecurity, associating an activity with an attacker, depends on tradecraft and tooling and patterns. And over time, state actors or criminal actors have either diversified their supply chain. So it's not just them or their team doing an action, and they depend on many different parts of the community, or they've intentionally obfuscated their actions by hiding them to make it much more difficult to attribute the action.

MICHAEL CEMBALEST: So a real attribution of this might find the state-sponsored sector much higher than what's in the chart?

PAT OPET: Yeah. Or criminals.

MICHAEL CEMBALEST: Or criminals. Gotcha.

(DESCRIPTION)

Slide: Why is this corporate attack simulation analysis from our April Eye on the Market significant as a milestone for cyber risk? A line chart titled Completed steps per spent tokens on a 32-step corporate network attack simulation plots number of steps completed on the vertical axis against cumulative tokens on a log scale horizontal axis. The vertical axis lists attack stages from M1 Initial reconnaissance up through M2 Lateral movement and credential replay, M3 Browser credential theft, M4 Wiki exploit and credential replay, M5 Web app exploit and privilege escalation, M6 C2 reverse engineering and crypto analysis, M7 Advanced persistence, M8 Infrastructure compromise, to M9 Full network takeover. Multiple model traces including Mythos Preview max and avg, GPT-5.5 max and avg, GPT-5.5-Cyber avg, Claude Opus 4.6 avg, GPT-5.4 avg, GPT-5.3-Codex avg, Claude Opus 4.5 avg, and Claude Sonnet 4.5 avg rise as cumulative tokens increase, with the Mythos Preview traces advancing furthest through the attack stages, sourced AI Security Institute, May 13, 2026.

(SPEECH)

OK. So in April, Mary sent me an email saying, hey, you better look into this Mythos thing. And I didn't what Mythos was. I thought it had something to do with the new Odyssey movie, like it was some Greek thing that was coming out. And obviously, I spent time looking into it. Your team was helpful to me at the time.

And I came across this chart, and this chart spooked me, which is why I included it in the Eye on the Market at the time. And it's from this AI Security Institute in the UK. And the purpose of this analysis was with 32 steps of across lots of different points of a system, you can execute a full system takeover.

PAT OPET: Yeah.

MICHAEL CEMBALEST: OK. At the time, the existing frontier models can only get about a third or a halfway there. And then Mythos came out and they published a big like, uh-oh, Mythos just went like all the way up the food chain and completed the 32 steps.

PAT OPET: Yeah.

MICHAEL CEMBALEST: And then a couple weeks after that, it was disclosed that GPT-- I think it was 5.5-- did the same.

PAT OPET: That's right.

MICHAEL CEMBALEST: What are these different barriers that it has to kind of get through?

PAT OPET: So it's kind of-- I think there's two important things to take away from this chart. One, cyber attacks occur in various stages, oftentimes called a kill chain. And so what's being described here is a model autonomously working through that kill chain, end to end, being able to exploit an organization without hands on keyboard, without an operator.

And so what this has really meant to measure is the autonomy of a model being able to execute end to end an attack through each of those stages. But I think it's a little bit misleading, because if one just takes away the fact that models will be able to autonomously attack corporations, it sort of misses the point that what they're also doing is accelerating and augmenting skilled attackers.

So let's take criminal attackers versus states. State attackers have exceptional capability that's very well funded. And they are by far the most dangerous attackers when we talk about cyber actors. Criminals are very dangerous, but they may be less skilled, less well funded, or less resourced. All of a sudden, when you take these capabilities provided by the frontier models, that in one sense can autonomously execute attack, but with a skilled operator, you boost the capabilities of that skilled operator pretty precipitously.

MICHAEL CEMBALEST: It's interesting because a lot of the AI research coming out of Stanford and Harvard is-- within in an organization, it makes your lower employees better.

PAT OPET: That's right.

MICHAEL CEMBALEST: More than it makes the great employees better. So similarly, it's doing the same.

PAT OPET: Same thing applies.

MICHAEL CEMBALEST: Oh, wonderful. And

(DESCRIPTION)

Slide: The impact of the latest models: a surge in reported vulnerabilities. A line chart titled Critical & high severity cybersecurity vulnerabilities (CVEs) from 21 notable organizations plots number of CVEs from 2022 to 2026, with a High severity line and a Critical severity line. Both stay relatively flat with High fluctuating around 200 to 400 through 2025, then both spike sharply in 2026, with High surging past 1,100 and Critical rising to around 400, sourced Epoch AI, July 2, 2026.

(SPEECH)

I thought this chart was interesting too, because here you can really see the impact of the new models on the pace of critical and high severity vulnerabilities that get reported. The CVEs, a critical vulnerability, there's some kind of a central repository for this kind of thing?

PAT OPET: Yeah. There's a mechanism to disclose these, reserve a number associated with the vulnerability and then inform the market, all the consumers of the software, that they need to fix something. Obviously, criticals and highs are the most important because they're the easiest to exploit and they can create the most damage. They're often hard to find.

The really interesting part of these models is that they can compute on software in ways that allow them to either chain various flaws together, or to recognize that there are much more severe flaws in the software that we knew to exist at a scale that is significantly more than we typically deal with on an annual basis.

MICHAEL CEMBALEST: I mean, look at this thing. I mean, the number of criticals were running less than 10 consistently and are now-- and now hit 400. I mean, this is pretty asymptotic.

(DESCRIPTION)

Slide: Let's dive into it. A bullet point list.

(SPEECH)

So I don't want to go through too much detail here, but we have some stuff in the piece that talks about-- and when Mythos first came out, this first bullet point got a lot of focus, which is, oh my God, Mozilla had all of these vulnerabilities in Firefox that nobody knew about until they started using Mythos to try to figure them out.

And the third bullet point I thought was interesting. 95% of the Mythos vulnerability disclosures had no public advisory at the time they were found. Does that mean what it sounds like?

PAT OPET: Yeah, they're novel. The model is finding new flaws in software that security researchers, in some cases over decades, were unable to find in some of the most well-trodden pieces of software, like the Linux operating system. And the way in which the models are able to compute on software allows them to find these exquisite or novel weaknesses.

MICHAEL CEMBALEST: The other parallel here is last year I talked to a group at Stanford in biotech. And there's this thing called antibiotic-resistant bacteria, MRSA. And it kills like 10,000 people a year. And they used some of the same models to go through 30 million possible compounds. And they found two that might work in mice trials. So there are a lot of parallels here with the way that people are using these for good things, in terms of as opposed to the bad things.

(DESCRIPTION)

Slide: What do you make of the surge in zero day exploitations? A line chart titled Zero-day exploitation rate plots the share of exploitations occurring before or on the day of disclosure from 2018 to 2026, climbing steadily from about 19% to nearly 78%. Two text blocks at the right explain that after a vendor releases a security patch, AI can reverse-engineer it to identify the underlying vulnerability and build a working weaponized exploit in minutes, with attacks spreading worldwide within hours, and that attackers share everything through open-source exploit kits and AI tools forked and improved on GitHub, with techniques documented by thousands of contributors operating as a decentralized R&D lab, sourced Zero Day Clock, July 2026.

(SPEECH)

This chart was also kind of unnerving. It's the share of exploitations occurring before or on the day of disclosure.

PAT OPET: Yeah.

MICHAEL CEMBALEST: So it's like you come into the office and you sit down at your desk, and all of a sudden there are these-- it may not be you, but there are other companies that have suffered an exploitation.

PAT OPET: That's right.

MICHAEL CEMBALEST: And you have to deal with it.

PAT OPET: Yeah. And I think this just lends to the same point, is that as tooling has gotten better, it's enabled attackers to find vulnerabilities at a broader scale. When attackers find the vulnerabilities and not defenders, they can weaponize them right away. And so you prefer the other side. Defenders are finding the vulnerabilities first. They're then fixing those vulnerabilities and pushing disclosures. Companies are consuming it and fixing that software before attackers weaponize it. We've essentially inverted the process.

(DESCRIPTION)

Slide: Let's talk about open source software. A table titled A timeline of major open source projects has columns Project, Year, and What it eventually enabled, listing PostgreSQL 1986 database-driven applications, HTML/CSS/HTTP 1990-1991 World Wide Web foundation, Linux Kernel 1991 modern computing infrastructure, R Programming 1993 statistical computing and data science, Apache HTTP Server 1995 early web explosion, JavaScript 1995 interactive web applications, OpenSSL 1998 internet security HTTPS, SQLite 2000 embedded and mobile databases, Git 2005 modern software development, and Pytorch 2016 AI/ML automation, sourced JPMAM, 2026.

(SPEECH)

MICHAEL CEMBALEST: Now, one of the things that was really eye opening to me as a layperson, I always knew that open source code was "important" quote, unquote. I had absolutely no idea that it is as pervasive and widespread in terms of building blocks as it is. And one of the things we have in here is a timeline of some of the major open source projects and what they eventually enabled. This goes back to the 1980s, some of this stuff.

PAT OPET: That's right.

MICHAEL CEMBALEST: Economists tell me this shouldn't exist. Economists theorize why would people do all this work for no compensation. And yet, it has existed for 40 years.

PAT OPET: Yeah, I mean, it's like people get to pursue mastery and they get purpose, and they can make impact despite being paid. And that's--

MICHAEL CEMBALEST: Despite not being paid.

PAT OPET: Right. Despite not being paid. Which is why open source really thrives.

MICHAEL CEMBALEST: Right. Now,

(DESCRIPTION)

Slide: The reach of open source code. A horizontal bar chart titled Understanding the reach of open source code and its army of volunteers plots three percentage measures. Share of commercial codebases with open source components reaches 99%, share of open source projects with fewer than 10 developers accounting for more than 90% of the code reaches 94%, and share of commercial code made up of prebuilt open source libraries and frameworks reaches 77%, sourced Linux, Harvard, Intel, 2026.

(SPEECH)

there's a chart in here that just summarizes a couple of things. And these were eye opening to me, so I wanted to share them with our clients. The share of commerciak code bases with open source code is in the high 90s. The share of open source projects with fewer than 10 maintainers or developers that are responsible for mosl of the code, 94%. And then the share of commercial code-- the font is too small for me-- made up of pre-built open source libraries and networks, 77%.

So even within the vendor software universe, of all the things that we buy as JP Morgan, the vendor software we're buying is highly reliant on open source code. The code that we write internally is reliant on open source code. So open source code is a much bigger foundation of everything that I had ever suspected.

PAT OPET: Yeah. And you have these sort of nested dependencies, where a piece of software may overtly use open source, but may also have a dependency on another piece of open source that isn't so overt. And so these things get built over time, and it creates complexity in the software that we use, but also for defenders complexity and understanding where all of your open source dependencies are to fix them when there isn't or where there is an issue.

MICHAEL CEMBALEST: I saw this one citation from CISA on a JavaScript thing. There were 10 direct dependencies and 680 indirect dependencies, which is kind of amazing.

(DESCRIPTION)

Slide: What are dependencies? A horizontal bar chart titled The 90% problem plots paired 2026 and 2025 percentages for codebases with components 4+ years out-of-date at 92% and 90%, codebases with components showing no development in 2+ years at 93% and 91%, codebases with components not using latest version at 93% and 91%, and codebases with components 10+ versions behind current at 92% and 90%, sourced 2026 Open Source Security & Risk Analysis Report, March 2026.

(SPEECH)

Oh yeah, here are the dependencies. The mean number of open source components per commercial application is almost 1,200. So that means that we're contracting with a certain vendor. And in order for that vendor software to work, either if we're running it remotely or in-house, we have to have a 1,200 other pieces of code to support it.

PAT OPET: Yeah, in some cases, they're built into the software package. I mean, there's probably a bit of influence of the SaaS ecosystem that has changed these numbers. So when a vendor provides a SaaS product, obviously, that's a whole suite of software, which likely includes a significant amount of open source.

MICHAEL CEMBALEST: And then who's responsible for updating that, them or us?

PAT OPET: The vendor. So the vendor-- in any vendor package, it is always going to be a vendor that's responsible for updating the software. So we have very little autonomy when it's a piece of software that we haven't written, whether it's outsourced or whether we're consuming that software, which is important part of the process of ensuring that your vendors are paying attention to the patchmageddon as well as first-party companies.

MICHAEL CEMBALEST: Look at the last bullet point here. This is from Linux Foundation. 95% of open source vulnerability reside in the transitive dependencies rather than the direct ones.

PAT OPET: That's right.

MICHAEL CEMBALEST: That's amazing. And

(DESCRIPTION)

Slide: Companies built around open source. A table titled Most valuable companies built around open source has columns Company, Open source tech, and Business model, listing Databricks with Apache Spark, Delta Lake, MLflow, Iceberg, Unity Catalog offering a platform as a service with additional features and compute, Red Hat with Linux offering services and additional features, MongoDB with MongoDB database offering additional features via Atlas cloud service, Elastic with Elasticsearch, Kibana, Logstash offering additional features via Elastic Cloud, GitHub with Git version control ecosystem offering a platform for hosting and collaboration, GitLab with GitLab CE offering additional features in enterprise tiers, MuleSoft with Mule ESB offering additional features, HashiCorp with Terraform, Vault, Consul, Nomad offering additional features for enterprise and cloud, Confluent with Apache Kafka offering a managed Kafka service platform, Grafana Labs with Grafana, Loki, Tempo offering additional features via Grafana Cloud, and Hugging Face with Transformers library and model hub offering an AI model hosting and training platform, sourced Generative Value, Eric Flaningam, August 26, 2025.

(SPEECH)

for investors, a lot of the names that you know and love-- Red Hat, Databricks, GitHub, Hugging Face-- a lot of these are heavily reliant on if not built entirely from open source code.

PAT OPET: Yeah. And some of these companies are both the maintainer-- they're the professional entity that maintains the open source, or the ones that created it itself. And so when we talk about open source, we differentiate between community backed, which is individuals, or foundation backed or professionalized open source where you have a company that's the steward of the software.

MICHAEL CEMBALEST:

(DESCRIPTION)

Slide: Open source patching. A bullet point list.

(SPEECH)

Tell me if you're surprised at this. This was the survey they did. 61% of reported incidents are associated with unapplied but available patches because over 80% of security professionals decided not to do it because they didn't want to disrupt the workplace.

PAT OPET: I mean, look, patching is hard. And so I think that that's the first thing to recognize, is that including new software and getting it released to production without incident is a difficult thing for many companies to do. And oftentimes we bias, as a community, availability. Incidents, whether they're caused by patching process or, in some cases, adversary disruption, have the same net effect. The software isn't available to consumers.

And so in many organizations, they may bias availability over fixing. And this problem hasn't presented itself as significantly as it presenting itself now. And so the calculus on patching is going to have to change for those organizations that don't have it as a first class priority.

MICHAEL CEMBALEST: And by the way, in terms of disruption, I was having all sorts of Zoom problems recently related to a Citrix patch, and I had to roll it back in order to get my Zoom to work. I will deal with that separately.

One

(DESCRIPTION)

Slide: Let's talk about infrastructure. A horizontal bar chart titled Cybersecurity vulnerability advisories by affected asset plots count of advisories for 2025 across asset types, with Sensor monitoring devices and Operations management software leading near 100 to 125, followed by Human machine interface and supervisory systems, Industrial control systems, and a long tail down through Emergency alert system, Industrial printer, and Security software with the fewest, sourced Forescout Technologies, February 19, 2026.

(SPEECH)

of the things that you mentioned was physical infrastructure. And explain how is physical infrastructure different than cloud based digital infrastructure.

PAT OPET: Yeah. So servers or switches or firewalls all run code. And the goal is to keep those kits, the physical infrastructure kit, current. But oftentimes organizations tend to sweat their assets. They don't replace that physical infrastructure as frequently as the providers would recommend, and it may fall out of maintenance, or it may lag the current release of code.

What's going to happen now with the number of vulnerabilities that are being found is that providers are going to be forced to fix the current software first, and so they're going to prioritize, maybe explicitly, only the current software, which means that older software, especially if it's end of life or end of service, may not get patched or may not be available to patch. And so organizations now are starting to think about all of this hardware refresh that they must need to do if the patches don't come for the older end of service kit.

MICHAEL CEMBALEST: One of the things that we get into on the infrastructure side is sensors and operational switchboards and device controllers. And what are we talking about here? We're talking about the stuff behind air traffic control systems, municipal waste treatment plants, water purification systems, the grid, gas and oil pipelines, electricity networks. This is the kind of stuff. And I think I saw a lot of digital assets are often replaced three to five year cycle. This stuff can be a 10 to 12 or even longer cycle.

PAT OPET: And it may run in environments that aren't easy to access it, distributed across a pipeline instead inside of a data center. It's tend to be built for the longer periods of time. It isn't refreshed as regularly. But these vulnerabilities, especially when they occur in these devices, can be pretty dangerous to the operation.

MICHAEL CEMBALEST: Earlier

(DESCRIPTION)

Slide: Some infrastructure might not be easy to patch and will have to be replaced. A table titled Industrial networks at cost as a percentage of non-patchable has columns Layer, Patchable, Unpatchable, and No patch, listing Operational technology at 45 to 60%, 15 to 25%, 25 to 35%, On-premises at 70 to 85%, 5 to 10%, 10 to 20%, Embedded at 60 to 75%, 10 to 20%, 15 to 25%, Networks at 70 to 85%, 5 to 10%, 10 to 20%, and Total at 55 to 65%, 12 to 20%, 20 to 30%, sourced JPMorgan, company filings from Siemens, Schneider, Rockwell, ABB, Honeywell, IDC, Grandview, NIST, World Bank, BEA, Engineering BOM, 2026.

(SPEECH)

this year, JPMorgan on the investment banking side worked with some of the big industrial companies, ABB and Honeywell and Siemens. And they estimate that only a little more than half of all the industrial networks are patchable. And I spoke to them. And the implication from those engineers was a lot of the rest of the equipment will eventually have to be replaced.

PAT OPET: Yeah.

MICHAEL CEMBALEST: Which is expensive and I would imagine time consuming.

PAT OPET: Yep.

(DESCRIPTION)

Slide: The same tools that are used to detect and exploit vulnerabilities can also be used to propose code fixes and remediate them. A bullet point list.

(SPEECH)

MICHAEL CEMBALEST: Now, this is a controversial point, and I know that members of your team have differences of opinion, which is totally to be expected. Some people have said to me, well, Mike, no problem, because these tools that are so good at finding the vulnerabilities can-- we can fight fire with fire, and we can use these same tools, and people are using them, to both propose fixes in the case of Anthropic and actually run the fixes in the case of OpenAI.

And I'm talking here about OpenAI's GPT 5.5 Cyber. They have a Codex Security plugin. Anthropic has Claude Security and a Cyber Verification Program. What's your thought on this stuff?

PAT OPET: Yeah, I mean, it is clear that a genetic coding tools can help accelerate the process of fixing the vulnerabilities we're finding. They are, in some cases, difficult to institutionalize in enterprise. And so while the capabilities may be there, it may be difficult for an enterprise to safely adopt these and scale the tools to all of the developers that need them.

And then, separately, there are some emerging challenges around guardrails in these tools. So the cyber models are designed with less guardrails. So they allow cyber tasks, and they're typically provisioned to cybersecurity teams as part of trusted access programs or Glasswing, which was an announced program. The general models refuse to do cyber work or offensive cyber work because we don't want to create harm.

Oftentimes when you're trying to fix a vulnerability, if the guardrails aren't properly tuned, it makes it actually difficult to fix the vulnerability, because a fix for the vulnerability and a test for the fix could be the same thing as an exploit for the vulnerability. And so the guardrails and the conversation around guardrails, which is now emerging, is going to get a little bit complicated over how much do we allow offensive cyber work because of the benefit of fixing versus how much do we try and prevent these models from being able to accelerate malicious actors activity.

MICHAEL CEMBALEST: I thought it was true to brand in some ways that Anthropic would say, we're not going to do the fix. That's on you. And whereas OpenAI goes a step further, and their stuff actually will execute.

PAT OPET: I think they're all trying to get to-- I mean, clearly, all these programs are aimed at supporting defenders. And I think what they all recognize is in addition to the frontier labs in the US, which you called out in the early charts, there are open late models emerging which don't have the same guardrails and won't refuse to do cyber work.

And so, for example, Kimi K3, an emerging open weight model, will happily do offensive cyber work and is nearly as capable as some of these frontier models. And so we are entering an era of time where cyber capabilities, whether we like it or not, are going to be readily available to arbitrary individuals. And that's going to create some real challenge for organizations.

MICHAEL CEMBALEST:

(DESCRIPTION)

Michael skips slides. Slide: Ten critical action steps for business owners & governments. A bulleted list reads Run the latest software versions; when possible, move applications off third-party dependencies where you can't identify the steward; where the steward appears to be a single shingle and/or does not exhibit good maintenance practices; or where the package appears abandoned. Maintain comprehensive continuously updated inventory of hardware, software and cloud assets. Build and operate a robust vulnerability management program. Stress test incident response and resiliency plans. Know your major SaaS and outsourced dependencies. Optimize change management for speed. Aggressively filter outbound traffic from production systems. Removing standing privileges from employee entitlements. Manage remote access and segment where possible. Embed security into the AI development and deployment lifecycle.

(SPEECH)

Let's get to then-- that you guys published something that we linked to in the piece on action steps for business owners and governments. And I bolded the first one because I thought that there were some interesting things in here. Run the latest software versions when possible. Move applications off third party dependencies when you can't identify the steward, and when the steward appears to be a single shingle and/or does not exhibit good maintenance practices, or where the package appears abandoned.

PAT OPET: Yeah.

MICHAEL CEMBALEST: That sounds like a lot of work.

PAT OPET: Look, I mean, I think the simple way to think about this is, in our own experience with the open source vulnerability analysis we did, if we simply move to the most current version of open source across all of our dependencies, 50% of our high end critical issues fall away.

MICHAEL CEMBALEST: So that's a great first step for everyone.

PAT OPET: Just maintain currency. Maintaining currency, again, may be difficult, may require you to be able to release software much more frequently than you typically do. And so we recommend that organizations accelerate their software release process at this point in time so that you can put code in production at will.

And then the rest of this, frankly, it is kind of cyber hygiene and basics that we've described for many years. Our point in the blog isn't just do the basics, it's get exceptionally good at the basics. Because right now, with the risk that's being created through these models, you need to be exceptional at doing the basics.

MICHAEL CEMBALEST: Right. My guess is that you might not be able to buy insurance against not being good at this.

PAT OPET: Yeah, insurance providers are certainly going to scrutinize these attributes.

MICHAEL CEMBALEST:

(DESCRIPTION)

Slide: What the US government could/should be doing. A numbered list of four points reads: 1. CISA liability, antitrust and FOIA protections that were part of the Cybersecurity Act of 2015 help firms share threat indicators, defensive measures and incident information with less legal uncertainty; they need to be extended. 2. The clearinghouse, established by Executive Order 14409 and launched as the Gold Eagle Initiative on July 14 2026, is designed to stage the release of open source patches to qualified parties before public disclosure in order to mitigate the risk of exploitation. Gold Eagle should be permanent and not temporary, and should be applied to lifeline sectors (communications, energy, water, transportation, banks and cloud service providers) given the new threat environment. 3. Create a dedicated, government-hosted domestic cyber-defense strike force capability with clearer authority to support lifeline sectors before and during serious incidents. 4. Help the weak links. Policy options include federal financing, targeted rip-and-replace incentives where obsolete systems create national-level risk (a cash for clunkers program for infrastructure instead of internal combustion engine vehicles), expanded CISA technical assistance and state and local cyber corps, and trusted-access programs to put defensive models within reach of designated, under-resourced operators.

(SPEECH)

So let's close. In some of the calls that we did a couple of weeks ago, members of-- we have policy people here. JPMorgan has lots of policy people, and they felt pretty strongly about certain things.

I want to focus on number 3, because that's the one that jumped out to me the most, that the US government should create a government-hosted domestic cyber defense strike force capability with clear authority to support lifeline sectors-- health care, finance, electricity, and stuff like that-- both before and during serious incidents. You want to just do a thought experiment about what that means and how it would work?

PAT OPET: Yeah. I mean, look, the government's obviously a close partner with cyber teams across the country, especially those in critical infrastructure, and has been so through DHS and CISA for many years, as well as the US intelligence community.

But when you think about the challenges that may be coming, undeterrable actors, individuals, criminals, activists, or terrorists with potential state-grade capabilities as delivered through these models, we would argue that it's appropriate for us to consider a more fulsome homeland defense organization that can actually operate against these actors within US networks, not different than how we generally think of maybe the Department of Homeland Security or the law enforcement measures that we have that would counter criminals.

Today, private sector entities are left to defend themselves against state actors, sophisticated criminals, and individuals. I would argue, when you look at some of the data, we're not winning. The nation at large is suffering cyber attacks regularly. Ransomware is a thriving ecosystem. Fraud is well funded through attacks. I think, given the capabilities that are here today and coming, we need to think about new ways to solve this problem. And it can't simply rely on every organization to just, quote, "do better."

MICHAEL CEMBALEST: And so you'd be able to raise your hand as an organization and say, I need someone to airlift in and help me out here because I'm--

PAT OPET: Either that because the country may get outstripped of the professionals who respond to incidents if incidents occur more frequently, or we may need to start to proactively disrupt operators when they're hosting infrastructure in our cloud providers or hosting links through our search engines or other things like that. We may need to take more active measures to ensure that they can't operate freely within the US.

MICHAEL CEMBALEST: One of the policy options I thought was interesting is I remember a few years ago, there was a cash for clunkers program for people to trade in their old internal combustion engine cars for electric vehicles. And one of your people mentioned to me a targeted rip and replace incentive system for obsolete systems that create national level risk. So I'm assuming water treatment plants and things like the FAA. And--

PAT OPET: If you look just simply at the last 12 months, the primary vector that bad actors have gained access to organizations is through exploiting what's called perimeter devices. So think security devices that are on the edge of your network, or remote access devices that are on the edge of the network that are designed to defend against these adversaries. They're often old. They have vulnerabilities. They have poor trust architecture. And those devices have been the primary gateway for the actors.

We would propose that across the 16 critical infrastructure sectors, we should scan for all of those vulnerable devices and just replace them. If you limit the actors' what's called initial access, by just taking that vector away can make this problem significantly harder, even though there are these great AI capabilities for attackers.

MICHAEL CEMBALEST: Similarly, just updating to the latest software open source libraries can dramatically reduce your risk as well. And so, Pat, it was great to have you on. And this was a great discussion. I think why did we do this? We're doing this because we think that a lot of our clients who run large and small and midsize companies may be facing a bit of a tsunami here that they're not expecting.

PAT OPET: Yeah.

MICHAEL CEMBALEST: And they need to start to focus on this. And I think it's important for organizations like JP Morgan to take what we're learning from Project Glasswing and share some of those insights.

PAT OPET: That's right. I really appreciate being here. And as you said, this is an important moment in time for many organizations to recognize the challenge that is now on our doorstep and to start to take those proactive measures to more fulsomely defend the organizations from disruption.

MICHAEL CEMBALEST: All right. Thank you very much. Good to see everybody. We'll see you again in August. So long.

(DESCRIPTION)

Presentation: J.P. Morgan, Eye on the Market. Logo: J.P. Morgan.