Bank of America Put 1,000 Contractors on Mythos Patching. Most Teams Can’t Do That.

Bank of America brought on 1,000 contractors in the second quarter to patch software flaws exposed by AI models like Anthropic’s Mythos. They are still there today, working alongside the 3,000 people already doing that work. CEO Brian Moynihan described the effort to CNBC on October 14. The work covers the bank’s own code and vendor code. In the third quarter, the bank spent roughly $200 million or more on software remediation and anti-money laundering compliance combined. CNBC notes it is one of the first times a major US company has put numbers on what Mythos-era patching takes.
‍

A team of 3,000 still needed 1,000 more

Bank of America’s patching group was already large. The volume of fixes still pushed the bank to add a third more people on top of it.

Few security teams can do that. Most have a fixed number of people and a queue that grows every week. Organizations already see about 40,000 new CVEs a year, and Anthropic’s guidance on preparing for AI-accelerated offense tells security teams to plan for an order-of-magnitude increase in the volume of vulnerability findings.
‍

What to do when you can’t grow the team by a third

Without the option of adding a third more people, the list has to get shorter. The way to shorten it is to focus on exploitable risk.

Three facts decide whether a flaw is exploitable in your environment. The vulnerable software has to be running, it has to be reachable from the internet, and your firewall or EDR must not already block the path to it. A critical severity score says nothing about any of those.

Zafran correlates runtime presence, internet exposure, active threat intelligence, and your compensating controls for each finding. With that context applied, 99% of critical vulnerabilities turn out not to be exploitable in a given environment. The remaining few are the ones to fix first.
‍

CISA’s BOD 26-04 already ranks fixes by exploitability

On June 10, CISA issued Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk.” For federal civilian agencies, it replaces CVSS-based patch deadlines with four factors drawn from the SSVC methodology:

• Asset exposure: whether the asset is publicly exposed to the internet
• KEV status: whether the CVE is on CISA’s Known Exploited Vulnerabilities catalog
• Exploit automation: whether an attacker can automate every step of the exploit
• Technical impact: whether exploitation gives partial or total control of the asset

The answers set the deadline. The three-day tier, which also requires a forensic check, is for vulnerabilities that are already being exploited, give total control, and are either internet-facing or automatable. Most of the rest get 14 or 60 days, and a vulnerability that is not exposed, not on the KEV list, and not automatable can wait for the next scheduled upgrade.

Mitigation counts too. If you take a system off the internet, its exposure changes from yes to no and the deadline relaxes. For the three-day tier, CISA accepts a mitigation action in place of a finished patch. Few teams can test and roll out a patch across a fleet in 72 hours, but a change to a firewall, WAF, or endpoint control can happen in minutes.

The directive applies to federal agencies, and it gives every security team a reference point for what to fix first and what can wait. CISA’s last major directive, BOD 22-01, created the KEV catalog and became a standard across the private sector. We expect boards and auditors to treat BOD 26-04 the same way. Zafran computes the SSVC decision for every CVE finding and maps it to the BOD timelines as ACT, ATTEND, TRACK, or DEFER. Our full post on the directive covers the details.
‍

FS-ISAC and JPMorgan gave banks this playbook in April

Bank of America’s disclosure lands in the same conversation as two financial-sector documents from April that cover how to decide what to fix first. FS-ISAC’s sector risk advisory told members to assume every vulnerability will be exploited, to give extra weight to externally facing ones, and to move beyond CVSS-only scoring. We covered the advisory in Assume Every Vulnerability Will Be Exploited.

The same month, JPMorgan’s Global Technology Leadership Team published ten actions for AI-ready cyber resilience, which we broke down in JPMorgan’s Mythos Memo Is the One You Should Actually Read. The letter says to combine vulnerability data with asset criticality, reachability, threat intelligence, and exploit availability. It also says to use perimeter controls such as web application firewalls to block attacks while vulnerable software is being fixed.

Both documents put reachability at the center of prioritization. FS-ISAC starts from the assumption that any vulnerability can be exploited, then asks you to weight internet exposure heavily. JPMorgan says to rank by reachability and exploit availability, and to put perimeter controls in front of vulnerable software while fixes are underway. Contractors speed up patching. Prioritizing by reachability shrinks the amount that has to be patched urgently in the first place.

How Zafran helps

Bank of America answered the volume of AI-found vulnerabilities by adding 1,000 people. Zafran gives your team a shorter list to work from.

Zafran pulls in findings from the scanners, EDR, and firewalls you already run, removes duplicates, and adds runtime presence, internet exposure, active threat intelligence, and compensating control coverage to each one. The Exposure Graph uses that context to show which vulnerabilities are exploitable in your environment, so analysts spend their time on the findings that carry real risk. Zafran is agentless and connects through APIs, so most customers can get connected and see results within a day or two.

Compensating controls matter most when a patch is not available yet. Bank of America’s work covers vendor software as well as its own code. With vendor software, only the vendor can write the fix, and you still have to test and deploy it once it ships. Until then, a control you already own can block the path to the vulnerable software, such as a firewall rule, a WAF policy, or an endpoint setting. Zafran maps every exposure to the controls you already have and shows which assets are protected and where gaps remain. Zafran pushes mitigations through your existing EDR, WAF, and firewall tooling with your approval, while you wait for the window to patch.

Whatever remains after mitigation goes to the people who can fix it. Zafran routes those fixes to the right owners through Jira and ServiceNow. When a new vulnerability is disclosed, the New CVEs Exposure Agent validates whether it can be exploited in your environment, using runtime state, architecture, OS version, and package version. Agent actions run with human approval on sensitive workflows. That removes the busywork of manual triage and owner-chasing, so the same team can handle more as vulnerability volume grows.
‍

Where to start this week

Bank of America has about 4,000 people on this work. Most teams have far fewer. Pull a list of your internet-facing assets that run software with a known exploit, then check which ones your firewall or EDR already covers. Whatever is left is the list to patch first.