Are we exposed?

On July 22, J.P. Morgan's Eye on the Market published a special issue called Patchmageddon. Eye on the Market is Michael Cembalest's commentary for investors and business owners, and it is not where most financial services security teams get their threat intelligence, which is why the security leaders I heard from about it had mostly received it the same way: forwarded, from somebody who does not report to them, with a short note attached.

The report opens with tornado warnings. The United States had none until the late 1940s, and after the Weather Bureau began issuing them publicly, tornado deaths per million fell by ninety percent, even though the average warning gives you about fifteen minutes. Cembalest's argument is that disclosed vulnerabilities and the patches that follow are the tornado warning for software, and that the warning time has collapsed. Citing the Zero Day Clock, he puts the median time between disclosure of a vulnerability and its first confirmed exploitation at a single day in 2026, down from roughly a year in 2021, and projects it reaching one minute by 2027.

I spent twenty years running engineering and security for trading systems at Citi and Mitsubishi UFJ, and Bridgewater, before I started Kusari, so my perspective comes from that side.

Shorter warning times are everyone's problem. In this industry an examiner or an allocator will ask, months later and on their own timetable, whether you were exposed to a particular vulnerability and what you did about it, and they want records rather than assurances.

That question has a cost, and most security programs have never measured it. What follows is an argument about what it costs today, why it costs that much, and what would have to be true for it to cost less.

What PCI, NYDFS, DORA, CISA and the CRA ask for

The board asks the blast radius question the week a compromise is in the news. Do we have it, and where? They want the answer now rather than in the follow-up, and a client asks the same thing before a renewal, increasingly in a format they can hold against whatever you sent them last year. Those two you can see coming.

The ones that cost you arrive on a schedule you do not set, and they are not asking about a package. They want to know what you did the last time, and whether you can show it. For a bank that is the examiner. For a registered adviser it is an SEC examination, and more often than that it is an allocator running operational due diligence, where the questionnaire lands every year, gets read line by line against last year's answers, and reaches somebody deciding whether to keep money with you.

I should be careful about what that costs, because as far as I can establish nobody has yet been penalized specifically for failing to account for what is in their software. DORA has produced supervisory letters rather than fines, NYDFS enforcement to date has centered on notification, incident response and data retention rather than on the asset inventory provision, and the Cyber Resilience Act has not started enforcing at all. Anyone selling you this on the threat of a penalty is selling you something that has not happened yet.

The cost is slower than a fine and lasts longer. An examination finding becomes a remediation commitment with a date attached, and that date owns a piece of your roadmap until it closes. An allocator does not need a regulator to act at all, and can decide on its own that this year's answers were thinner than last year's. The examiner's leverage is the finding. The allocator's is the money.

Answering the board, the client, the examiner and the allocator used to be separate exercises, run by different people against different evidence. Most programs are still built that way, and they no longer need to be. Five sets of obligations, written by different bodies for different reasons, have converged over the last two years on the same three questions:

1. What’s in your software?
2. Can it be exploited?
3. If Yes, what did you do about it?

Requirement	What it asks for	In force
PCI DSS 4.0, req 6.3.2	Inventory of bespoke and custom software, plus the third-party components incorporated into it	March 31, 2025
NYDFS Part 500.13(a)	Asset inventory policies covering owner, location, classification, support expiration and recovery time objective	Nov 1, 2025; first certification April 15, 2026
DORA Article 28	Register of Information across nine linked templates, ICT assets mapped per service, sub-outsourcing chains, deliverable on request at any time	First submission Q1 2026
CISA SBOM minimum elements	Required data fields raised from 7 to 18, with a new required practice to explicitly identify unknown information	July 29, 2026
EU Cyber Resilience Act	Enforcement begins	Sept 11, 2026

Four are already in force. The fifth, the Cyber Resilience Act, starts enforcing on September 11. You are probably in scope for more than one of them, and not always the ones you would guess, since DORA reaches past credit institutions to investment firms and fund managers operating in the EU while NYDFS Part 500 catches anything licensed under New York banking, insurance or financial services law rather than banks alone.

The DORA row is the one I'd point a board at, because of what happened when the Register of Information was collected for the first time. Roughly a third of submissions came back with invalid or missing legal entity identifiers, and blank sub-outsourcing templates for major cloud providers were among the most common errors. Those submissions came from institutions with the largest compliance functions in the industry, which is why I read that result as a measurement rather than as sloppiness. The best-resourced firms in Europe could not assemble an accurate picture of their own dependency chain on request.

Required data fields went from seven to eighteen in the July CISA change, and one of the new required practices is to explicitly identify unknown information, which moves the regime from asking what you know about your software to asking where the boundary of what you know sits. The second question is much harder to answer with tooling that was never built to distinguish between a dependency it resolved and a dependency it could not.

Why the blast radius answer still takes days

Modern applications are assembled rather than written. Between 96% and 99% percent of commercial codebases contain open source components and roughly 77% percent of the code in a commercial application is prebuilt open source libraries and frameworks, according to Harvard and Intel research cited in Patchmageddon, which also puts the mean commercial application at around 1,180 open source components. A typical JavaScript project on GitHub has ten direct dependencies and 683 indirect ones, and ninety-five percent of open source vulnerabilities live in that indirect layer.

Nobody at the firm selected those 683, and nobody is watching them. Datadog's February 2026 analysis, also cited in the report, puts the median dependency across all languages 278 days behind its latest major version, up from 215 days the year before.

Proving what you did about it is the harder half. The 2026 Verizon DBIR found vulnerability exploitation has become the top initial access vector at thirty-one percent of breaches, passing stolen credentials for the first time in nineteen years, while only twenty-six percent of vulnerabilities on the CISA KEV list were fully remediated last year, down from thirty-eight percent, and forty-five percent remain unpatched after a full year. TuxCare's 2026 Open Source Landscape Report, cited in Patchmageddon, found that sixty-one percent of reported incidents are associated with patches that were available and had not been applied.

That same TuxCare survey asked practitioners what causes the delays in their Linux patching process, and alongside downtime constraints, human error and resourcing, respondents named the inability to track whether vulnerabilities had been remediated, the inability to prioritize what needs patching, the lack of a common view of applications and assets, and reliance on email and spreadsheets to manage the process. Those four are bookkeeping problems rather than patching problems, and in my experience they're the reason an honest answer to an exposure question takes days even inside programs that are well funded and well staffed.

You cannot prove remediation across a layer you never enumerated, and the enumeration is the part I have almost never seen in place.

Operational technology teams reached this failure first, and their version of it is worth borrowing. Dragos reported in its 2026 Operational Technology Cybersecurity Year in Review that thirty percent of incident response cases in 2025 began not with a detected intrusion or a ransom note but with somebody noticing that something seemed wrong, and that in the majority of those cases the data needed to determine whether cyber was involved had never been collected. Their conclusion:

In a growing number of cases, asset owners are making public statements that incidents had nothing to do with cyber not because they determined that to be the case, but because they lacked the data to determine anything at all.

In a regulated institution, being unable to say anything defensible afterward costs more than the incident did.

What the question costs

Security is a cost center. It does not ship product. It does not generate revenue. Its entire job is risk reduction per dollar spent.

I don't say that to be deflationary about the work. I say it because it's the frame every other function in a financial institution is already evaluated in, and because in the budget cycles I sat through, the programs that couldn't express themselves that way lost those arguments. Once you accept the frame, the exposure question stops being a technical problem and becomes an allocation problem.

Consider where the money goes. The 2026 Verizon DBIR describes enterprises carrying hundreds of thousands of open findings, and the figures above say most of those findings sit in dependencies the organization never selected while a large share sit in code paths the application never calls. Teams generally have no reliable way to tell those two populations apart, so every hour spent triaging a finding whose vulnerable code path is unreachable in your environment is an hour not spent on one that is reachable. At the volumes the DBIR describes, that isn't a rounding error inside the security budget. In the programs I ran it was a large fraction of it.

So the problem isn't that teams are missing findings. In our conversations with security leaders, almost nobody describes a shortage of findings. What they describe is a backlog growing faster than the team does, and no defensible basis for choosing which part of it to work on, which means the money is going out, the risk reduction it buys is unmeasured, and when the examiner asks why this vulnerability was deprioritized over that one, nobody can reconstruct it.

Ranking findings is the easy part. Defending the ranking is the hard part, and in our conversations with security leaders, that is usually what is missing.

Credit where it is due

Every institution I've worked in ran scanners, and I want to be precise about what they do well, because the argument I'm making is not that the tools are bad.

Advisory-fed scanning against a declared manifest was the correct architecture for the world it was built in. Vulnerabilities were disclosed through a coordinated process that gave defenders a window, advisories arrived ahead of exploitation more often than not, and a manifest was a reasonable proxy for what shipped. Software composition analysis tools built on those assumptions have found an enormous number of real vulnerabilities and prevented an enormous amount of harm, and the open source ones in particular have done more for the state of the practice than most commercial products have.

The problem is underneath them, in two assumptions that stopped holding at different times and for different reasons.

The first assumption is that the manifest describes the software. A manifest is a declaration of what the software is supposed to contain, and the scanner takes its word for it. That was close enough to true when dependency trees were shallow, and it becomes a weaker approximation as the indirect layer grows, as pinned commits and vendored code enter the tree without announcing themselves, and as build processes pull in artifacts no declaration ever mentioned. A tool reading the manifest is not looking at your software. It is looking at a description of your software, written by the same people whose work you are trying to verify.

The second assumption is that advisories exist, and this is the one that broke recently. Patchmageddon reports that ninety-five percent of the vulnerability disclosures produced by Anthropic's Mythos model had no public advisory at the time of the research snapshot, meaning nothing in the Common Vulnerabilities and Exposures database, nothing in the National Vulnerability Database, and nothing in the GitHub advisory feeds. That is a different ninety-five percent from the transitive-dependency figure I cited earlier, and the two get conflated often enough that it's worth separating them: one is where open source vulnerabilities live, and this one is how many of the new ones are never published anywhere.

The disclosure funnel the report reproduces from Anthropic makes the scale concrete. Of 23,019 candidate findings, 1,596 were reported to maintainers, 1,451 were acknowledged, ninety-seven were patched upstream, and eighty-eight resulted in a published advisory.

Every scanner deployed across this industry runs on the far right of that funnel. An advisory-fed program isn't slow when the great majority of new findings never reach an advisory feed. It's looking at a different world than the one attackers are working in.

What an answer you can defend requires

Set products aside for a moment, mine included. If an institution wants to answer the exposure question in minutes with evidence that survives an examiner, four things have to be true, and the order matters.

One. The picture has to be built from source rather than read back from a declaration. You cannot verify a claim by using the claim as your input. Every other part of a financial institution already operates on this principle. Nobody runs a balance sheet on what the ledger is assumed to say. Nobody accepts a counterparty's description of a position as evidence of the position. Software is the last place in a regulated institution where a declaration is still treated as a record.

Two. The tooling has to state the boundary of what it knows. A dependency tree the tool could not fully resolve should come back marked incomplete, with the evidence for what it did resolve attached. Most tools do not do this, and the omission is easy to miss, because a partial answer and a complete answer look identical when neither one carries a confidence marker. Since July this has been a regulatory question as well as a technical one, given that explicitly identifying unknown information became a required practice under the CISA minimum elements. I'd note that meeting that one practice is not the same as conforming to the eighteen-field standard, which is a checklist no vendor should claim against casually, including us.

Three. Whatever narrows the list has to leave a reason behind. Reachability analysis is the mechanism that makes the volume problem tractable, since a finding whose vulnerable code path your application never calls is not exposure and removing it from the queue is correct. Removing it is only defensible if the removal carries a stated reason that somebody who wasn't in the room can read, evaluate and repeat, because a ranking that can't be reconstructed will be treated as a preference the first time it's challenged.

Four. Remediation has to be checked before it reaches you. This one comes last on purpose. Automated remediation is the part of this category that has burned people, and every security leader I raise it with describes the same pattern: a tool proposes a fix, the fix is generated from the same advisory data that produced the finding, and it breaks the build or bumps a major version nobody was ready for. A proposed change that hasn't been built against your environment, run through your continuous integration, and re-examined for what the change itself introduced is a guess with a diff attached. And a pull request is not a fix until somebody reviews it and merges it, which is a distinction the industry has been careless with.

Three of those four are about evidence and only the fourth is about action. A remediation capability layered on top of a picture you can't defend produces changes to production code justified by reasoning you can't reconstruct, and that's worse than the backlog.

From capability to operating model

Somebody has already written this down as an operating model rather than a list of properties, and for this audience the source matters as much as the content.

In April 2026 the J.P. Morgan Global Technology Leadership Team published Fortifying the enterprise: 10 actions to take now for AI-ready cyber resilience, which Cembalest reproduces in Patchmageddon. Several of the ten are the argument above stated as instructions:

• 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 a comprehensive continuously updated inventory of all 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

Those are the first six of the ten, quoted in the order the list gives them.

That list is worth more to a security leader in this industry than any vendor framework, mine included, because it was written by the technology leadership of a bank rather than by the security industry, and because it's the list a board member is most likely to have already seen. The part it doesn't address is how a continuously updated inventory gets assembled, and an inventory assembled from declarations is a continuously updated set of claims.

Separately, a coalition that includes the Cloud Security Alliance, SANS and OWASP Gen AI has published a security program briefing calling for a permanent Vulnerability Operations function, staffed and automated the way DevOps was, on the argument that the volume is now structural rather than episodic. I think they're right, and I'd add the economic case to the operational one, because a permanent function is how risk reduction per dollar stops being an annual argument in a budget meeting and becomes a number somebody owns.

What this looks like in practice

This is the part where I tell you what we built, so treat the rest of this section accordingly.

Kusari builds the dependency graph from source rather than reading it back from a manifest. It resolves the parts of the tree the manifest never declares, including transitive packages, pinned commits and vendored code, and it carries provenance for each artifact back to the source that produced it. The graph is maintained as a version-pinned time series, so "what did we look like in March" has an answer, which matters more in an examination than it does in an incident.

Findings are ranked by the Kusari Score, which weighs the technical severity of a vulnerability against how widely the affected component is used across your estate, then adjusts for whether anyone is exploiting it. A listing in CISA's Known Exploited Vulnerabilities catalog sets the score no lower than nine out of ten. Without a KEV listing, EPSS sets the floor instead. Reachability analysis or a customer-supplied VEX document removes an application from the calculation entirely when the vulnerable code path can't be reached, and the reason stays attached to the removal. At the national health insurer in our published case study, a 6,000-employee organization, reachability analysis took about ninety percent of vulnerability findings off the active list, and their team can answer a zero-day exposure question in seconds rather than days.

On the second requirement above, the honest answer is that this is newer work. Waybill, our SBOM generator, declares whether its dependency tree data is complete or incomplete with confidence-level evidence on the relationships it found, which most tools do not do. It's in alpha, it's open source, and you can look at it before you believe me about it.

I should be straight about why the case study is a health insurer rather than a bank or a fund. Our first approved financial services case study is in progress and isn't published yet, so what I can offer today is the closest available analogue: a regulated, examiner-facing institution carrying regulated data, audited on the same evidentiary logic, that had the same gap in transitive and indirect dependencies I hear described across banks and funds alike. Their security leader put it this way:

We invest heavily in application security, but we had a real gap in transitive and indirect dependencies. The last thing we want is another Shai-Hulud without Kusari in place.

On remediation, the part that matters is what happens between deciding a finding is worth acting on and handing you something safe to merge. Kusari traces the finding to its root cause across the transitive chain and works out the smallest change that resolves it, rather than bumping everything and hoping, and the pull request it generates covers code, config and lockfile together. Then it checks its own work: continuous integration runs against the change, and a separate inspection agent re-scans the result for anything the fix introduced, whether that's a new vulnerability, a typosquatted package or a dependency nobody asked for. Anything it isn't confident about gets escalated rather than shipped, and existing pull requests get updated rather than duplicated.

Nothing merges itself. You review, and you decide.

Kusari sits above the scanners you already run rather than replacing them, ingesting their findings alongside every repository, dependency and SBOM into one graph. The tools you own keep running and become inputs. That is what makes the blast radius question answerable: when something drops, do we have it and where becomes a query against one graph rather than a week spent reconciling four tools that disagree.

What this does not solve

You will not resolve everything in a C or C++ estate. There is no manifest to read, so dependencies arrive as vendored source somebody copied in four years ago, submodules pinned to a commit, and system packages resolved at build time on whatever machine happened to run it. What you get in those estates is a documented boundary between what is confirmed and what is not, which is what an auditor accepts and is a good deal less than a complete answer.

Building the graph from source needs access to your continuous integration, so this starts with a conversation with whoever owns your pipelines rather than with a procurement form. Most teams go repository by repository rather than all at once, which makes it a smaller ask than it sounds, and it is still an ask.

Reachability analysis narrows the queue without emptying it, and the residue is still real work for real people.

A pull request is not a fix. It is a proposal, it requires review by somebody who owns the code, and the merge decision carries all the risk it always did. Automation moves the bottleneck from authoring to reviewing, which is a real improvement and is not the same as removing it.

And none of this touches the other structural problem Patchmageddon raises, which is maintainer economics. More than eighteen million open source packages, fifty-five percent of the total on npm, list exactly one maintainer. Of the top fifty open source projects the Linux Foundation and Harvard analyzed in 2022, ninety-four percent had fewer than ten developers writing more than ninety percent of the code. Recent filings put Python Software Foundation revenue at four million dollars against two hundred and twenty million for the Linux Foundation.

Anthropic reported 530 high and critical findings to maintainers and seventy-five were patched, and Tuskira Research found the rate of Mythos vulnerability discovery outpacing the rate of patching by 16.5 times even though maintainers acknowledged ninety percent of what they received. A high or critical open source bug found by Mythos Preview takes about two weeks to patch on average, and no amount of tooling inside your institution pays for those two weeks in a library your money path depends on. Knowing precisely which of those libraries you depend on is worth a great deal. It is not the same as the problem being solved.

I'd add that Cembalest ranks this second. His view is that dependency management and sprawl may be the bigger challenge, which is the problem I've spent this document on, and I mention it because I'd rather you heard his ordering from me than find it on page thirteen.

What I think happens next

The policy movement is worth watching on two fronts. The Cybersecurity Information Sharing Act of 2015 sunsets on September 30, 2026, and if its liability, antitrust and FOIA protections lapse, firms are likely to get more cautious about sharing threat information at exactly the moment the exploitation timeline makes faster sharing more valuable. The Gold Eagle Initiative, launched in July under Executive Order 14409 to stage the release of open source patches to qualified parties ahead of public disclosure, is the other one, and which institutions qualify as critical infrastructure for its purposes is still being worked out. Cembalest argues it should be permanent and should cover banks.

Underneath the policy, the standard is shifting. For twenty years the question a regulated institution had to answer was whether it scanned. Within two years, from examiners, from allocators, from enterprise clients and from the next incident, the question will be whether you can prove what is in every artifact you run and whether it is reachable. Answering the second one takes different machinery than answering the first.

I'd rather be wrong about the timeline than the direction. If you think I have the direction wrong, I'd like to hear it, and particularly from anyone who has taken a Register of Information submission through a first collection, because that experience is more instructive than anything I can write.

If you want to see what your own dependency tree looks like resolved from source, we run a thirty-minute session on a public repository of your choosing at kusari.dev/start, and you keep whatever comes out of it.

Kusari was founded by a team that co-created GUAC, now an OpenSSF incubating project, and co-created SLSA, and that maintains in-toto attestations.

Figures attributed to Patchmageddon are from J.P. Morgan Eye on the Market, "Patchmageddon," Michael Cembalest, July 22, 2026, and the sources cited within it. Eye on the Market is J.P. Morgan Asset Management commentary and does not constitute J.P. Morgan Research. Kusari is not referenced in that report, and no endorsement or recommendation by J.P. Morgan is implied or exists. Views here are the author's.