Over the years I have been part of many discussions around a classic debate around red team versus blue team, the value of penetration testing, and the value they each bring. I started my InfoSec career in 1996 doing pentesting (aka red teaming) a couple years before it really exploded. For nine years that was my life and it often meant working crazy hours. My final gig doing it was with BT-INS where I found myself working hours that simply weren’t sustainable. As best I know, I may still hold a record for billable hours in a week and I was told that was for “all of BT“, not just our division. Given BT’s considerable tenure that was some feat, but not many people are dumb enough to work 121 billable hours in a single week.
After that I joined Tenable to work on Nessus which is software to do vulnerability scanning. Same general idea as penetration testing but used by so many more people. That meant my work was more impactful as thousands of organizations would benefit from it instead of one per week like the prior gig. Next it was to help found Risk Based Security (RBS) where we provided vulnerability and data breach intelligence. So I never truly worked on a blue team, meaning defending systems and networks. Basically, security administrators who install patches, upgrades, configure devices to block traffic, and a whole lot more.
I think you would be hard pressed to find someone that claims red teaming is more difficult than blue teaming. There is an old adage along the lines of “blue teams have to defend against every vulnerability, hackers only need one to get in“. With the ever-increasing number of vulnerability disclosures and the time to exploit for many vulnerabilities dropping quickly, blue teams continue to have an extremely challenging job.
For years now I have been increasingly outspoken about how we need more people working on defense than offense. All these brilliant hackers / pentesters that can pop boxes left and right is great. But I can assure you based on my experience, companies don’t always patch all the vulnerabilities you report to them. There were times where we would see the same vulnerability pop up year after year at the same client, despite it being high-risk and an avenue to gain unauthorized access. So I became more supportive of blue teams in general. Vulnerabilities will be here for a long time and with the coming onslaught of so-called AI systems designed to find those flaws, it will only get worse.
Between Anthropic’s Glasswing project which uses their new Mythos model, as well as their Claude model, those alone are capable of finding vulnerabilities with increasing speed and complexity, and they are becoming more reliable. Then throw in ChatGPT, Copilot, Gemini, and however many others, things are looking grim for the future of vulnerability disclosures.
A couple weeks ago several headlines caught my attention and I thought, “I think some folks are starting to see the problem here!” and I was briefly encouraged. So it led me to propose a simple question: With all these large language models (LLMs) designed to find vulnerabilities, where are the ones designed to fix them? And there is a lot of nuance to this question too. The biggest one that comes to mind is Microsoft’s Copilot, which is integrated into GitHub and can actually perform code fixes for you during a pull request for example. But there is a nebulous grey area between e.g. Mythos and Copilot in those contexts. It isn’t simply an argument of finding versus fixing, rather, the nuance is in the approach.
If I find a vulnerability and create an exploit I have potentially contributed to helping criminals; especially if I publish that exploit code. I used to be a full proponent of the ‘full disclosure’ debate, which argues that disclosing more information on a vulnerability is more advantageous in the bigger picture than partial or no public disclosure. That is very much the oldschool ‘hacker’ mindset, where we collectively argued that by publishing such information it forced the vendor to patch rapidly. In the 1990s this became a huge, ongoing debate as researchers would attempt to work with a vendor to get a vulnerability patched only to see the vendor drag their feet and sometimes never fix it. I disclosed one simple cross-site scripting (XSS) vulnerability to HP Inc. back in the day and the forthcoming fix took four years.
Back to the headlines that gave me a little hope in our industry seeing the bigger picture. The summarized message that can be taken away is that people are scared of Mythos, rightfully so, that such tools can find vulnerabilities in minutes while blue teams can take days, weeks, or even months to protect against them. You couldn’t even call it an arms race before the rise of LLMs either. Human researchers alone could discover and churn out vulnerabilities faster than vendors could fix them. Now it is about to be an order of magnitude worse.
So my question to Anthropic especially, but it really stands for any company creating this software: why aren’t you creating these tools to find and fix the vulnerabilities earlier in the process? That would be part of the system / software development lifecycle (SDLC). Within the SDLC is the concept of “shifting left” to make security more efficient and effective rather than finding a vulnerability, reporting to the vendor, and then having to fix it across multiple code bases, release a patch, and wait for administrators to fix it? The idea is you find and fix the vulnerabilities before the software is even published. Developers that write secure code from the start mean that the entire process is not needed. Several companies including Veracode have been focused on that for a long time, by creating software that helps scan for vulnerabilities in the code, to be used by developers.
Where is the Mythos equivalent of that? I haven’t seen it and if it is out there it certainly isn’t getting as much attention and fanfare as Claude and Mythos. That means that these tools are helping, but in an inefficient and backhanded way that puts more burden. While Mythos may propose a fix for a vulnerability it finds, if that comes after discovery and writing a proof-of-concept (PoC) exploit, that isn’t even needed. Why waste all those cycles going so far to find and verify the vulnerability when it is much quicker to improve the code and move on? Many developers will fix an issue rather than diving in to determine how serious or even figure out how far back it was introduced.
As I wrote this article originally, I almost painted myself in a corner. That was due to starting the article without that nuance and context. There is a pretty fine line that separates the approach but I think Anthropic has fully stepped across that line in the sand. Mythos tests software, finds a vulnerability, and can create a working exploit. What it should be doing is scanning the code, identifying anywhere that a user can pass input, and verify it is properly sanitized. That knocks out a lot of vulnerability classes like overflows. SQL injection, XSS, and more. Then look for additional vulnerability classes like race conditions, cryptographic issues, authentication management, and more. Skip the exploits and any other complex verification of the issue and instead spit out a code-level fix that can be evaluated by a human and one-click accepted.
Why this approach? First, simple efficiency. By shifting left it reduces the time and resources required to fix issues. It also has a nice side-effect that if a system like Mythos decides it can’t create a working exploit it may move on. But that doesn’t mean it isn’t exploitable! If instead Mythos found a place of concern and proposed a patch, it may solve what actually is a vulnerability. If it isn’t, then it becomes a defense-in-depth code fix which is still beneficial.
Second, the amount of computing power and adjacent resources required to do all of this is incredible. So much so there is plenty of speculation that Mythos is limited to a dozen companies not because it is “too powerful”, rather, it is too expensive for Anthropic to offer to everyone. The computing power required means an incredible amount of electricity and water are needed which adversely hurts many communities where data centers are being installed. So why waste all those extra resources to find and exploit vulnerabilities rather than just produce a fix and move on? Other than marketing and hype of course.
Third, if Mythos is really that powerful then we should be worried. The Whitehouse is and we’ve barely seen the tip of the iceberg of Mythos’ capability. And rightfully so since we’ve already been told by Anthropic about one case of unauthorized access to the tool. If this tool is made available to more companies there is no way to guarantee one won’t use the tool to find vulnerabilities in a rival’s product either. In short, there are a lot of concerns over Mythos’ approach.
So this is my plea that will fall on deaf ears! Neuter Mythos’ ability to write exploits right now, full stop. Instead, turn it into a newer, more powerful version of software that performs code audits and recommends fixes. Use it to audit code to find those harder to locate vulnerabilities, the more complex exploit chains, and maybe even the next new class of vulnerability. But quit wasting so much of our resources for marketing and playing with fire.
Leave a Reply