No name, no score, no fix

In part 2 of this series, I laid out seven questions that decide which security findings deserve attention: has it already been fixed, is something blocking the way in, can anyone reach it, how sensitive is it, and so on. Those questions assumed something without saying it: that every finding arrives with a name. A known flaw has a public ID, a severity score, usually a fix from the vendor, and a history you can look up. The seven questions start from there.

A new kind of finding doesn’t, and that changes how much the sharing matters.

What’s new

For years, most findings came from matching. A scanner looks at what you run, compares it with a list of known flaws, and flags the matches. If nobody has found and published a flaw yet, the scanner can’t see it.

AI changed that. Models can now read source code the way a careful reviewer does, follow how data moves through it, and reason about where it could break. They can do it with both kinds of code you run: your own, with the business logic nobody else has, and the open source and other libraries your apps depend on. Some of what they find is already known. Some of it is new, what’s come to be called a novel vulnerability: a flaw nobody has written down before, in code that’s been running, potentially for years.

The name you’ve probably heard is Mythos. It’s an AI model that hasn’t been released to the public. Since April, a group of about fifty organizations has been using it to look for flaws in important software, under the name Project Glasswing. By late May they had reported more than ten thousand high or critical findings, and most of the ones handed to maintainers didn’t have a fix yet. Mythos is the headline, not the whole story. Other models can do this kind of reading too, and more are coming.

If you want more, here are two views. From the maker: Anthropic’s own update, with the numbers and how they handle disclosure. From the outside: CSO Online’s “Behind the Mythos hype”, an early, skeptical count from April that could find only one public ID clearly tied to the program. Both can be true at once, and that’s the point of this part: lots of findings, almost none of them with a name yet.

That’s good news. Finding flaws before attackers do is the whole game.

The bad news is that the same skill works for the other side. A model that can find a flaw can find it for someone who wants to use it, and that’s part of why the best-known one isn’t public yet. So it’s a race, and the head start defenders get is only worth as much as what they do with it.

And a new flaw shows up very differently from a known one.

What a new finding doesn’t have

Two things make the blanks harder than they look. The first is the missing name.

The second: while a fix is being made, the details are usually kept private on purpose, so attackers don’t get a head start.

Then there’s the copying. Code gets copied, forked and bundled. A flaw found in one library may be sitting in a dozen products that copied it years ago, under different names.

What it does to our seven questions

Here’s the part that matters for this series. A new finding knocks out the cheapest answers to the seven questions, so the rest have to carry the decision.

Question 1, has it been fixed? → Not yet, by definition. The cheapest question in part 2 has no answer.

Question 3, is anyone trying? → There’s no attack data for a flaw nobody has published. Half of question 3 goes quiet.

That leaves the questions only your own teams can answer:

None of those live with security. With a known flaw, the outside world does some of the work for you: the vendor, the public score, the attack reports. With a new one, the outside world is silent, and your own answers are all you have. If they arrive weeks late in a spreadsheet, you’re deciding blind.

So the default changes too. In part 2, “probably not” was the starting point, because most known findings turn out not to matter. A new finding on something reachable and sensitive goes to “ask first”, and it goes there fast.

Fixing it costs more

Asking first is fast and cheap. Asking for a fix isn’t.

With a known flaw, someone else already did the hard part. They found it, understood it and wrote the patch. You apply it.

With a new one, all of that lands on you. Someone has to understand the flaw, work out what it touches, and then either write a fix or ask a vendor or an open source project for a custom one. That’s unique work, with its own effort, its own testing and its own wait. Question 5, can we change it safely and how fast, was already the most expensive question to ask. For a new finding it costs more.

So qualify with prejudice, from part 2, matters even more here. Before anyone asks for a code-level fix, the finding should have earned it. Often the better answer is to address it instead of fixing it: block the way in, cut off who can reach it, or retire the thing. That goes double when the flaw sits in an old block of code that hasn’t been updated, potentially for a long time. Rewriting it may be the most expensive option on the list, and the least needed.

Trust it, but check it

AI can be wrong, and confidently so. A finding from a model is a lead, not a verdict. Before anyone changes a production system because of one, someone should reproduce it: show that the flaw is real, in your version, in the way you run it.

That’s one more answer that lives outside security, usually with the app team that knows the code.

What it means

The pile is going to grow, and from a new direction. Not just more of the same known flaws, but findings with nothing attached to them, about code everyone assumed was fine.

And it lands on a backlog that was already full. Known flaws keep coming from the scanners, and planned changes like upgrades and new features go through the same process, the same people and the same maintenance windows. Novel findings are a new source pouring into the same pile. For a sense of size: the organizations using Mythos reported more than ten thousand high or critical findings in about six weeks, by the maker’s own count.

That makes the bet from part 1 stronger, not weaker: the more security, the business and the teams that build and run things share, the faster they can decide. The teams that already share their answers early will handle these in days. The ones that pass spreadsheets will still be waiting for a vendor fix that hasn’t been written.

It also raises the question part 3 is about. A new, unfixed flaw on a sensitive system is itself sensitive information. It’s a map. So if we share more, who gets to see what, and who gets to act on it?