Bank of America has brought in roughly 1,000 external engineers to work through code patches, according to a report from Golem, after a deployment the publication calls 'Mythos'.
The headline number is the story. A remediation effort of that size implies a backlog of fixes larger than a normal bank's security organisation can absorb on its own — the classic second-order effect of tooling that makes finding problems dramatically cheaper. Discovery is now often the fast part; reviewing, testing and shipping the fix across a large, regulated codebase is not.
The substance of the report lies in its details — the scope of the engagement, the systems involved and the timeline — and those are best read at the source.
What generalises: organisations adopting aggressive automated security review should budget for the patch wave that follows. That means capacity for review and release engineering, not just scanning; triage that ranks findings by real exploitability rather than raw count; and governance for the contractors who will do much of the work, since outside engineers touching production code carry their own supply-chain and access-management risk.
Banks face an extra constraint. Their release cycles are governed by regulators, their mainframes and COBOL-era systems resist rapid change, and every line touched must be traceable.
