Anthropic’s announcement last week that Claude Security scans can now run on Claude Mythos 5 is a pretty big deal.
AI scanning code isn’t new. What’s different here is how much context Claude brings into the analysis: how the code works, what the developer was trying to do, and how the pieces of the application interact.
That can help uncover issues traditional scanners may miss, while also suggesting fixes developers can apply.
I don’t think this replaces traditional scanners. They’re still cheaper to run at scale, faster, and in many cases required for compliance. But it’s a strong addition on top of them.
There’s just one obvious challenge: What happens when it finds too much?
Let’s say Claude scans an application and finds 500 legitimate issues. That’s great, but now someone has to decide what to fix first. Some questions that come to mind:
- Which of those issues are in code that went to production?
- Of the ones that do, how many sit on paths that are reachable?
- And how many of those are on services exposed to the internet?
We’ve already seen this with customers who got early access to advanced AI-based scanning. They liked the findings, but quickly ran into the same problem: there were too many to act on.
The question stopped being “is this finding real?” It became:
Which one actually matters?
Better detection can still create noise; AI is getting remarkably good at finding vulnerabilities. That’s a good thing, but it also means we’re heading toward a world where security teams can find more real issues than developers can realistically fix.
And once that happens, even valid findings can start to feel like noise.
That creates developer fatigue, and it can also create a false sense of security. You might close hundreds of findings while the issue that represents the biggest real-world risk is still sitting in the backlog.
More findings don’t always mean less risk.
Code context is only one part of the picture
Claude can bring much better context about the code itself. But to prioritize properly, you also need context from the rest of the SDLC.
- Is it running in production?
- Is it internet-facing?
- What application does it belong to?
- Who owns it?
- Is the vulnerable path actually exploitable in the deployed environment?
The answers to these questions can completely change the priority.
A critical vulnerability in an unused internal repository may matter a lot less than a lower-severity issue in an internet-facing production service.
That’s the part I think becomes increasingly important as AI-based security scanning gets better.
The next problem isn’t finding vulnerabilities
The future of AppSec won’t be about finding more vulnerabilities.
We’re already getting good at that part.
The harder question is going to be: Which findings actually matter enough to fix first?
That means taking what tools like Claude Security find and layering in context from the rest of the SDLC: what’s deployed, who owns it, and how exposed it really is.
We’re going to run a virtual workshop around exactly this.
We’ll start with Claude Security, take what it finds, and run those findings through Legit Security to see what’s actually deployed, exposed, and worth fixing first.
The goal is simple:
Claude found the vulnerabilities. Which ones should you actually care about?
Join me on Tuesday, September 15 at 2 pm ET/11 am PT as we break down what Claude Security can do and where gaps exist.
Download our new whitepaper.
