Finding Vulnerabilities Got Cheap. Fixing Them Still Takes People

On 14 October, Bank of America's chief executive, Brian Moynihan, said the bank had brought in about 1,000 outside contractors to patch software flaws exposed by AI models, Anthropic's Mythos among them.

If you sell software to banks with a team of 20 or 40 people, you probably do not have this model. A handful of the largest banks were among the first to get it this spring, and what they find does not stay inside the bank. Our read is that part of it will land in their vendors' vulnerability remediation backlogs, with a deadline.

He spoke about it twice that day. In an interview with CNBC after the third quarter results, he said the bank put on 1,000 contractors for the patching work in the second quarter, and that "those people remain here today", on top of the 3,000 people the bank has in that area. According to CNBC, Moynihan said the work covered both the bank's internal code and its vendors' code.

On the earnings call earlier that day, he said the 1,000 were brought in as consultants, "not in the headcount", and that he expects the Mythos remediation costs to run down.

Both were covered by TNW, which notes that it has not verified the numbers independently. Neither can we, so this is Moynihan's account as reported.

When Anthropic announced Project Glasswing in April, it said AI had sharply cut the cost and expertise needed to find and exploit software vulnerabilities. By June its partners had found more than 10,000 high or critical severity flaws, and Anthropic wrote that the bottleneck had moved to verifying and patching what these models surface.

A finding is a line in a report, and turning it into a fix means changing a system your customers are using right now. Somebody has to decide whether the finding is real in your context, which takes knowing why the code looks the way it does. Then the fix needs tests, a regression run, a review and a release that does not disturb a live product.

A model can draft the patch, and Anthropic says many Glasswing partners now use it that way. Knowing whether your largest customer relies on the behavior you are about to remove is still a person's job, and so is owning the release if something goes wrong.

Mythos went first to the Glasswing partners and about 40 more organizations, and Reuters reported that a handful of the largest US banks, Bank of America included, had access. Anthropic extended Glasswing to about 150 more organizations in June, and since 6 October security teams can apply for Mythos access, so you may get a version of the tool yourself. The banks still have a head start of several months, and what they found is already moving down the chain.

Reuters documented one step of that chain in May. The largest US banks were helping inform smaller banks with no direct access to the tool, and sharing data on their findings. A source familiar with the findings told Reuters the model was turning up several hundred to thousands of vulnerabilities ranked low to moderate, and that in some cases banks were patching in days what they might previously have waited weeks to patch.

Reuters describes banks informing other banks. We have seen no report of a bank sending findings to its software vendors with a deadline, so the next step is our read. Moynihan told CNBC that vendor code was in scope at Bank of America, and we expect banks running these scans to send what they find in vendor code back to the vendor with a date next to it. At a company of 30 people, that goes into the same backlog as the roadmap.

In the EU, the contracts already point that way. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Financial entities must keep a register of all their contracts for ICT services from third party providers. Where your service supports a critical or important function, the contract must give the bank and its regulator unrestricted rights of access, inspection and audit, and the bank must have an exit strategy in case it needs to replace you.

If your product falls under the CRA, Regulation (EU) 2024/2847, there is a second clock. Since 11 September 2026, an actively exploited vulnerability needs an early warning within 24 hours of the manufacturer becoming aware of it, a notification within 72 hours and a final report within 14 days after a fix is available. Skadden reads the scope as covering connected software such as mobile apps, plus the back end or cloud services those products need to work. The regulation's own recitals put cloud services such as SaaS under the NIS2 directive instead, and bring a remote service under the CRA only where a product needs it to perform its functions. Check where yours sits.

The usual answer we hear from founders is that they have a team and hire for themselves. For steady product work that is the right call.

A vulnerability remediation backlog behaves differently. It arrives with someone else's deadline and shrinks once the queue is worked through. A bank with about 3,000 people already on the work still added about 1,000 contractors, kept them out of the headcount, and expects the cost to run down as the backlog clears.

A permanent hire made for the spike stays on payroll after the queue is empty. Pulling your existing engineers onto it stalls the roadmap your customers pay for. If the spike lasts a quarter or two, neither is a good trade.

This is the case our model is built for. Engineers are contracted and paid through us for the length of the engagement, and they work inside your codebase, reviews and release process. You interview the engineer before anything is signed, the engagement runs month to month, and the rate does not change while the contract runs. When the queue is back to normal, you end the engagement. The rest of our terms are on the questions and answers page, and we compared staff augmentation, outsourcing and dedicated teams separately.

We do not have Mythos access, and none of this work involved it. These are the closest cases we have.

Our client MyComplianceOffice has around 30 compliance products on a single system, used by 1,500+ client firms across 125+ countries, and banks and asset managers run their compliance on it. We embedded a full stack engineer working in Java and Spring, Angular and the database, shipping features, tuning queries and fixing issues across their microservices without disrupting live compliance operations.

We also work with Security Journey, which sells application security training. There we did ongoing production bug fixing and feature delivery in Rails and React, shipped without disrupting learners. It was product engineering on a security company's platform, and a patch queue asks for the same habit of fixing a live product without breaking its releases.

Our work for BEQUANT, a regulated European prime broker in digital assets, was product design, a rebuilt design system for its trading product, so we count it as experience in the domain and nothing more.

Some of this queue will be automated, and soon. Narrow bug classes with well known fixes, such as an outdated dependency or a missing input check, are changes a model can propose and a pipeline can test. Our own engineers use AI tools in their daily work, and we expect the automated part of this work to grow.

What stays with people is code whose correctness depends on what the business means, such as who may see which account and how a payment is retried or reversed. A model can point at a gap in that logic. Deciding what the rule should have been takes your product owner, and often your bank customer, in the same conversation.

Questions worth asking before the first list arrives:

If a bank customer sent you a list of findings next week, who would triage it, and what would that person stop working on?

Who on the team still knows why the oldest parts of the code are written the way they are?

Can you ship a security fix with tests and a regression run without holding a release?

What do your contracts with bank customers say about audits, incidents and exit plans, and has anyone on the engineering side read them?

If your product falls under the CRA, who sends the 24 hour early warning, and do they know it is their job?

Our engineers join your team and work in your codebase, inside your review and release process, for as long as the queue needs them. 70,000+ hours of work, clients in 6 countries, 50+ specialists.

You interview before signing, terms are monthly, and if the fit is wrong in the first 7 days we replace the engineer at no cost.

We work mainly in Ruby on Rails, React, Next.js, JavaScript, Java, Golang, iOS, Flutter and Rust.

Talk to us about a senior engineer