AppSec is dead, long live AI security

“AppSec is Dead, Long Live AI Security” is the kind of statement designed to provoke a reaction. It is bold, dramatic, and easy to remember. It also captures a growing belief in the market that AI will soon make traditional application security obsolete.

That belief is understandable. It is also wrong.

AI is already changing how software is built, and tools such as Claude Code Security are starting to change how parts of software security are performed. Finding vulnerabilities, suggesting fixes, and generating useful regression tests can now be done faster than before. That is real progress. It may even radically change parts of the AppSec market as we know it today.

However, application security is far bigger than scanning code for flaws. It is part of the full software development lifecycle and depends on decisions made long before testing begins. Teams still need to understand risk, set policies, define standards, write security requirements, perform threat modeling, and make sound architectural choices. LLMs can support many of these activities, but Claude Code Security does not replace them, and it does not meaningfully cover them today.

That is where the slogan breaks down.

Where Claude Code Security fits in an AppSec program

So, where does Claude Code Security fit? Is it sufficient to give you all best practices of OWASP SAMM?

Viewed through the OWASP SAMM lens, Claude Code Security is best understood as a strong fit for verification, not as a replacement for a full application security program. That is the key distinction. The tool can help teams verify that they implemented the right controls correctly, but it does not give them the full set of practices needed to run mature AppSec across the software development lifecycle.

Its clearest value is in security testing. In practice, that means support for activities comparable to SAST, DAST, IAST, SCA, and even parts of manual penetration testing. Claude Code, used alongside Claude Code Security, can also help teams generate structured abuse cases and build security regression test suites, which is especially important because many organisations still struggle to test security controls systematically. That makes verification the area where the tool can most clearly improve speed, coverage, and consistency.

The fit is more limited outside verification. For architecture assessment, Claude Code Security is not positioned as a replacement for an existing review process. Teams may use Claude Code to support architectural security principles such as input validation, output encoding, authentication, and authorisation, but that is not the primary focus of Claude Code Security itself.

There is also a smaller role in operations. Claude Code Security may help with configuration hardening, especially where security settings must be enforced at the level of software components rather than only in infrastructure. Even here, its usefulness depends on clear specifications and guidance, for example, from sources such as OWASP Cheat Sheets.

Where the tool is weakest today is in governance, design, and implementation. It does not define risk appetite, create policy, write meaningful security requirements, perform threat modeling, or ensure secure design decisions are made early enough in the lifecycle. Those remain people and process-driven disciplines. So the answer is no, Claude Code Security is not sufficient to give you all the best practices of OWASP SAMM. It strengthens one important part of AppSec, but it does not replace the wider system.

That matters because verification is still a weak spot in many organizations. Security controls are often never tested, either manually or automatically. Abuse cases are not systematically defined. Regression testing for security is inconsistent. Claude Code Security, especially when paired with Claude Code, is likely to create clear value here.

But that still does not mean AppSec is dead. It means one part of AppSec is getting stronger.

Why AppSec still matters

A capable tool does not create a mature security program on its own. It cannot define risk appetite. It cannot build accountability into engineering teams. It cannot make sure secure design practices are applied early enough to stop avoidable problems before they are built into a product. It cannot replace leadership, ownership, or process.

Put simply, Claude Code Security can help teams do some things better and faster, but it does not remove the need for human judgment or structured security work.

That is why frameworks such as OWASP SAMM still matter. Strong application security programs are built across governance, design, implementation, verification, and operations. Claude Code Security can support parts of that system, especially verification, and in some cases, limited operational work. More broadly, LLMs can support many SAMM practices over time. But they do not replace the system. They work inside it.

What happens next for AppSec

That matters for business leaders as much as for security teams.

AI is not a shortcut to application security maturity. Used well, it can help strong teams test faster, improve consistency, and extend coverage. Used badly, it can simply help organizations create risk faster.

So, is AppSec dead?

No.

What is fading is the idea that application security can still rely on slower, more manual verification methods and keep pace with modern software delivery. Tools like Claude Code Security are raising the bar for verification, increasing expectations for security tooling, and reducing manual effort in some testing tasks.

That is a major shift, but not the end of AppSec. It is the next phase of it.

The future is not traditional application security versus AI. It is people, processes, and AI-enabled tools working together.

AppSec still matters. It’s just that one part of it is simply getting stronger.

Aram Hovsepyan

Dr. Aram Hovsepyan has spent over 15 years working in application security as a researcher, industry expert, and core contributor to the OWASP SAMM project, and is a founding board member of OWASP EU. He holds a PhD in application security from DistriNet KU Leuven, and his work on refining the LINDDUN privacy engineering methodology has been incorporated into both ISO and NIST standards.