24 February, 2026
Everyone can now write code with Claude and get to production in a weekend. So we have solved the coding challenges. Time to fire the tech team. As of last week, Claude Code Security has also supposedly solved the application security challenges. There goes the AppSec team as well. Right?
Neither idea holds. LLMs can write code, and they can do it quite well. But they tend to amplify rather than replace. As a newcomer, you can build a nice-looking hobby project over a weekend and maybe even take it somewhere. But as the codebase grows, you will likely end up in a complex mess.
Strong engineers are gaining productivity with LLMs. Juniors can now turn a project into spaghetti at impressive speed. But let’s set the spaghetti aside. Who cares if AI manages it all, right? Not quite. The more pressing issue is security. AI is known to generate insecure code. Yet last week, Claude Code Security was presented as the pinnacle of application security, positioned to disrupt the industry.
This blog examines how much of application security Claude Code Security can realistically cover. For simplicity, I will assume it is perfect. Meaning everything Anthropic claimed last week in their news article is 100% true.
Key takeaways
- The industry performs poorly at systematic security control verification and at creating structured abuse test cases. Claude Code, combined with Claude Code Security, could significantly improve this by generating security regression test suites.
- Claude Code Security may be effective at identifying vulnerabilities across a codebase. It could challenge traditional SAST/DAST vendors and even parts of penetration testing. At the same time, established players are likely to integrate similar AI capabilities into their existing tooling.
- If properly guided, Claude Code Security might assist with certain architectural security principles. However, this does not appear to be its primary focus.
- Viewed through the OWASP SAMM lens, Claude Code Security offers limited support in governance, design, implementation, and operations.
- Application security is built on people, processes, and tools. In that order! Claude Code Security is a tool. At best, it streamlines some processes and augments certain roles. It represents incremental improvement, not a fundamental shift.
The scope of security in organizations
First, we need to position the domain of security. Doing so already makes clear why Claude Code Security can address only a small fraction of the overall challenge.
Information security is the broadest scope. Its objective is to protect information in all its forms: stored in systems, transmitted over networks, processed by servers, handled by people, or even stored and transported physically.
There are many ways to structure information security. A practical distinction is between physical and cyber domains. Cybersecurity focuses on protecting digital assets: data and information (including identities and credentials), applications and services, and the underlying infrastructure and platforms. In short, anything that lives in or depends on information technology.
Within cybersecurity, applications form a major category. This includes both purchased and internally developed software. For off-the-shelf applications, security is primarily about secure configuration and proper management. For internally developed applications, application security extends further. It encompasses strategy, policies, processes, standards, and training to ensure security is built in from the start.
At the core of application security lies the software development lifecycle (SDLC). The SDLC is the structured process used to design, build, test, deploy, and maintain high-quality software within cost and time constraints. Security is one of those quality attributes.
Application security with OWASP SAMM
The most appropriate scope, based on the previous section, is in fact the SDLC. This is where you build your code. Both Claude Code and Claude Code Security fit nicely into the SDLC. However, in most organizations, the scope of the SDLC is slightly broader and effectively includes the application security domain. The reason is simple: we want every team in the organization to follow the same set of policies, standards, and processes when building applications. Operations, on the other hand, is typically handled at the organizational level as well. This is why OWASP SAMM provides an appropriate lens through which to view your application security program.
OWASP SAMM
SAMM is a structured collection of best practices for your application security program. By implementing these practices, you reduce the risk in the applications you design, build, and operate. You can find more information about OWASP SAMM on the official project website as well as in the blogs we have published on our website.
Claude Code Security in your AppSec program
So where does Claude Code Security fit? Is it sufficient to give you all best practices of OWASP SAMM?
Claude Code Security can help us verify we did the right things right
Let us first look at security practices where Claude Code Security is a great fit. Claude Code Security fits well in many activities within the security verification business function in SAMM. You can combine Claude Code with Claude Code Security to maximize the benefit. Given clear security requirement specifications, a well defined architecture, and a concrete code implementation, Claude Code Security can help you verify that you implemented the right controls correctly.
Security testing
For security testing comparable to SAST, DAST, IAST, SCA tools, and even manual penetration testing, I expect Claude Code Security to perform very well. However, vendors that rely on traditional pattern driven vulnerability detection already integrate LLM capabilities into their tools. Claude Code Security is not the only obvious choice. In penetration testing, LLMs will clearly make testers more efficient. The market for external penetration testers may shrink. My own team found several meaningful vulnerabilities in minutes that two reputable external penetration testing teams had missed.
Requirements testing
Beyond vulnerability detection, Claude Code, more than Claude Code Security, can help you build a comprehensive set of security regression test suites and abuse scenarios. This is likely the primary area to explore when you use a powerful LLM that can generate code.
Architecture assessment
Claude Code Security does not aim to cover architecture assessment. Teams can use Claude Code to strengthen architectural security controls such as systematic input validation, output encoding, authentication, and authorization. You can also use it to verify that the architecture addresses common threat patterns. However, Claude Code Security does not replace any existing architecture review process if you already have one in place.
Claude Code (Security) might help in operations
Claude Code Security can support a small part of operations, specifically configuration hardening. Although teams usually associate configuration hardening with operations and IT, some hardening must happen at the level of software components. Teams can leverage the OWASP Cheat Sheet projects to define clear specifications for LLM based agents.
Claude Code (Security) is tangentially relevant in Governance, Design, and Implementation
To the best of my understanding, Claude Code Security does not focus on governance, design, or implementation. OWASP SAMM does not include an activity that simply states you must write code securely. That may seem odd, but secure coding is not a standalone activity. Everything around writing code matters more. You must understand risk and define risk appetite. You must create policies and standards. You must specify security requirements. You must conduct threat modeling to identify threats and derive new requirements. You must apply secure design principles and architecture. Claude Code Security does not address these areas in a meaningful way.
LLMs in general can provide strong support here. Claude and other LLMs can help draft organizational policies. They can translate policies into technology specific standards and test scripts. They can support risk analysis and threat modeling. However, people must lead these activities, and organizations must establish the underlying processes. LLMs remain tools within that structure.
Conclusion
LLMs open new doors and opportunities in application security. Tools such as Claude Code and Claude Code Security can help scale application security programs. However, these advances remain tool focused. Organizations still need strong people and well defined processes.
More importantly, LLMs have an amplifying effect. With the right people and processes in place, an AppSec program can move from crawling to flying. Without them, and if teams rely mainly on tools, they risk moving from walking back to crawling.
