Traditional SAST Scanners Are About to Die

Disclaimer: This post isn’t generated by AI. All thoughts are my own. However, I use AI to fix some grammar mistakes and improve sentences.

I remember the first time I bought a BlackBerry phone. It had a QWERTY keyboard. My Nokia didn’t have that. It had an email client. You could check your emails on the go. That’s great! But there were a lot of drawbacks too. GPS navigation was painful. Browsing websites wasn’t straightforward. You needed a computer most of the time. But since we didn’t have anything better, we had to use it.

When I bought my iPhone 4, I quickly realized BlackBerry’s time had ended forever. It was a whole new experience. You couldn’t even compare the two. It was very clear that no one will ever miss my BlackBerry again.

When I got my first job as a security engineer, I had the chance to use a commercial SAST scanner (a tool that finds vulnerabilities in code). I amazed at first. But soon I realized it was not very reliable. It could find obvious vulnerabilities that match exact rules, but it missed slightly more complex ones. It also produced lots of false positives. However, since we didn’t have a better option, we had to keep using it.

Later in my career, I used different SAST products. They all felt like a new version of BlackBerry with the same core problems.

Also, I realized that those products cost a fortune. A well-known SAST provider asked for a license fee around one million dollars. One million dollars for a product that barely works? Yes, because there was nothing better.

But after using Claude Code to find vulnerabilities inside codebases, I had my iPhone 4 moment again.

Since Claude has solid reasoning capabilities, it can detect vulnerabilities like authorization issues, business logic issues, price manipulation issues, and complex injection issues. These are fundamentally not achievable by SAST tools with hardcoded rules.

The problem with any LLM is that their context window fills up quickly and they start producing false positives. But I found a workaround. I created separate SKILL prompts for each vulnerability category and split the work across subagents. And each subagent splits the work into two sub-subagents. This way, I can keep the context window small and the false positives low.

I shared all the skill files in this repository: https://github.com/utkusen/sast-skills

They work best with Claude Code. But they work with any AI-based IDE. Load them into Cursor, OpenCode, Codex, whatever. That’s it. You now have a better vulnerability scanner than a million dollar SAST product.

Traditional SAST scanners are outdated now. They probably know this and will try to adapt. But I wonder if they can still charge companies those crazy license fees. Probably not.

Imagine a company purchases Claude Code licenses for all developers and security engineers. Developers can add security-related prompts to their project’s CLAUDE.md file so the AI generates code with security in mind from the start.

When developers push code to GitHub, a Claude agent checks their pull requests for vulnerabilities.

When security engineers do a thorough assessment, they use skills to find vulnerabilities inside the code base and verify them.

Where does a traditional SAST scanner fit in this organization? Nowhere. If it’s free, maybe it’s worth using just in case. But if you want to charge a million dollars per year, sorry, I’ll pass. I’m already paying for LLM providers anyway.

Companies will buy AI as a package. They won’t buy a separate SAST solution from a different vendor anymore.