To be clear, we are not talking about doubling the capacity of its predecessor. Mythos is several orders of magnitude better at finding Zero-day vulnerabilities. Firefox exploit benchmarks show a 90x increase compared to Opus 4.6. Mozilla Firefox found 22 security bugs with Opus 4.6, while Mythos found 271 vulnerabilities completely unsupervised. Mythos has also found bugs surviving human test and automation for over 20 years, and after finding those bugs and vulnerabilities, Mythos can automatically exploit them without major human guidance.
Mozilla has already rolled out a patch covering the 271 vulnerabilities found by Mythos. The release “Firefox 150” was mainly driven by the findings of Mythos and briefly put the Mozilla team to the test.
In this aspect, the CTO of Mozilla stated that Mythos did not find any vulnerability that a highly skilled human could not eventually find… the difference here is how fast Mythos did this.
Why does this affect manufacturers and what is Project Glasswing?
The vulnerabilities found by Mythos cover operating systems, web browsers, open-source libraries, and other embedded software infrastructures. While a regular user might never see the “FFmpeg libraries” or “JIT compilers”, those tools are used in the background by regular applications and web browsers and can be accessed through these AI tools on an automatic and large scale.
With these results, Anthropic has considered Mythos a cybersecurity threat and has delayed its public release. Instead, Project Glasswing was formed to give access to major development companies as a head start for patching major vulnerabilities. These range from stealing private browser data to even giving hackers access to system level controls outside of a browser. The companies forming Project Glasswing include Google, Microsoft, Apple, and more.
The question is not then if tools like these will find vulnerabilities within our software, the question is where and when.
What’s the impact on manufacturers, especially medtech companies?
The use of AI as a tool for identifying and exploiting vulnerabilities will create an immense backlog of required patches within all affected systems.
As a manufacturer, this creates more than one pressure point. First and most obvious, patches need to be developed, validated, tested, and released. Those patches will not happen at random and risk management processes need to be documented according to ISO 14971. This will not only cover transparency but allows developer teams to prioritize which vulnerabilities should be patched first. As consecutive patches are developed, technical documentation will need to be updated. If required changes trigger changes to the system architecture or workflows, they are most likely deemed as significant changes and the involvement of a notified body will be required.
All of this following IEC 62304 which also considers post-market surveillance activities.
What can manufacturers do to prepare?
Mythos will clearly not be the last of its kind, with Anthropic predicting the release of similar models within 6 to 18 months. The use of AI for finding and exploiting vulnerabilities is not a single event but will rather change the game into a faster cat and mouse modality. The time between a vulnerability is found and the time it can be exploited is greatly reduced. That means, the time between a vulnerability is found and the time it takes for a patch to be released also needs to be reduced. So how do we tackle this?
Manufacturers need to change their mindset:
From “we release a patch once we gather a few bugs and its worth the release effort” to “we need to do continuous security maintenance”. In order to streamline this process, QMS tools need to be defined to differentiate releases that involve significant changes to those that correspond to security patches. What documentation will be required for doing security patch releases, how much testing needs to be done, and whether a notified body needs to be involved or not.
Within MDR, impact assessment needs to be clearly defined. Does it change user interaction? Does it introduce new hazards? These are some questions that can immediately define if a change is significant or not.
Lastly, companies should proactively implement AI tools in a defensive way to do code reviews. This changes the setting from a reactive workflow into a system that constantly aims for safety improvements. Measures like this can change the notified tone of discussion from requesting approval to a notification of changes.
Lamborghini Sotelo | AI Consultant
