How JPMC tackles software ‘trust debt’

JPMorgan Chase chief information security officer Patrick Opet made headlines 11 months ago when the company posted his open letter to third-party suppliers. In it, Opet called out JPMC’s suppliers’ practice of prioritizing features development over software security and demanded a higher commitment to the latter. 

The headlines may have had an effect. In the months since Opet’s blog post was published, JPMC has seen a sharp drop in the time its suppliers take to remediate software security issues, Opet told an audience at the RSAC Conference in San Francisco last week. 

In an interview with RSAC Conference executive chairman Hugh Thompson on Wednesday, Opet said that JPMC’s data suggests that its suppliers are addressing the software security issues it raises 45 to 90 days faster than the industry average. 

Here’s how JPMC rewrote the rules on third-party software by moving beyond a reliance on trust — and why it matters.

[ See webinar: Modern TPRM — How to Securely Onboard Vendor Software ]

The call to action heard ’round the world

Thompson, a managing partner at Crosspoint Capital, said Opet’s blog post, in which he called out the growing dominance of software-as-a-service applications and the lax security principles that many SaaS providers use when deploying their software, sent shockwaves through the industry. 

Many SaaS models rely on implicit trust of the provider while dismantling traditional security boundaries that had kept organizations protected from attacks and using authentication protocols such as OAuth that enable direct links between external, third-party services and sensitive internal resources, Opet noted in his post.  

But there are risks. For example, around the time that Opet’s blog post was published, researchers at Oasis Security revealed that OAuth permissions tied to a Microsoft OneDrive feature allowed third-party web applications to access the entire contents in OneDrive users’ storage.

The problem is much bigger than enterprise SaaS deployments, said Saša Zdjelar, chief trust officer at ReversingLabs (RL).

“What Pat is describing is the unwinding of decades of trust debt. The industry defaulted to implicit trust in vendors because verifying was hard and expensive. JPMorgan is proving that when you actually inspect what’s inside the software you’re buying — the components, the dependencies, the threat models — vendors respond.”
—Saša Zdjelar

JPMC flexes its spending power

Speaking at the RSAC Conference in San Francisco’s Moscone Center, Opet said JPMC had shifted its focus, from managing supply chain risk to managing the suppliers. “As a large buyer of security or technology in general, we have an opportunity to … use our purchasing power to change the outcome,” Opet said. 

But threatening to send noncompliant firms packing was only part of the program. JPMC also boosted its ability to assess the risks in its software supply chain, using deep, third-party security assessments of suppliers’ software, threat intelligence to enable proactive vendor risk detection, and business context-focused risk analyses that assess the sensitivity of data and operational impacts associated with specific applications. 

“We essentially explicitly trust that party … what we need to do is reason on the nature of that connection.”
—Patrick Opet

Zdelar said the results prove something RL has seen for years: Vendors build more secure software when buyers demand evidence, not blanket promises. “Forty-five to ninety days’ faster remediation isn’t a courtesy — it’s what happens when a $4 trillion bank tells you your contract depends on it,” he said.

Threat models: The new requirement

In recent months, JPMC has started requiring SaaS vendors to share their corporate “threat model” with the company so it can assess the suppliers’ plans to assess and address known risks to infrastructure and applications. Opet said this is an attempt by JPMC to get suppliers’ assurance that a breach at one vendor won’t cascade into a breach of JPMC. But vendors’ response is often, “What threat model?”  

JPMC is also experimenting with ways to reduce its implicit trust in third parties and regain control over data and execution environments. It is using tokenization to limit data exposure, implementing “confidential computing” models that greatly reduce SaaS vendors’ access to sensitive data, and testing a “bring your own cloud” model, in which SaaS vendors operate from infrastructure deployed within the bank’s protected environment. 

Risk management in the AI coding age

Opet said systems that scale with generative AI can give technologists “a great way to make the business much more effective,” but human-assisted AI tools such as AI coding agents present a challenge. They can greatly increase worker productivity, but their effectiveness depends on their access to employee data. That creates severe cybersecurity and data privacy risks. 

“AI dev platforms on the desktop that the employee uses puts these very powerful AI tools in the same context as the employee’s email, their sensitive files, their identity, and the systems that can get a path to the internet.”
—Patrick Opet

Opet said JPMC is creating a new architecture for AI-powered agents to run on that will limit their access to sensitive information and IT assets. In effect, he said, this separates the employee desktop from the agent desktop.

“Ideally we would want these agents to run an ecosystem where they [have] an identity but no entitlements,” Opet said. That could be a virtual machine or container. When AI-powered tools need access to a resource outside that controlled environment, IT administrators need to understand the need for that access, who that agent is working on behalf of, and what events led to the request for access.

Such a controlled architecture gives JPMC the confidence to scale AI coding assistance and other AI-powered desktop tools because unintended consequences such as identity theft and abuse are greatly curbed.

JPMC’s position on supply chain risk is forward-thinking, said Zdelar, and other firms should be considering the same strategy.

“The question every CISO should be asking now isn’t whether they can afford to do what JPMC is doing. It’s whether they can afford not to.”
—Saša Zdjelar