Claude Code Security is code review, not penetration testing

At a glance

What this is: This analysis says Claude Code Security fits the SAST layer, not penetration testing, because it inspects source code rather than attacking a deployed system.

Why it matters: IAM and security teams need that distinction because code-side review cannot validate runtime authorization, session abuse, or the identity controls that fail only after deployment.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read MindFort's analysis of why Claude Code Security is not a penetration test

Context

Claude Code Security sits in the source-code review layer, which means it can identify risky patterns in code but cannot prove whether those patterns become exploitable in the deployed system. That distinction matters in application security because runtime context, infrastructure state, and chained attack paths often determine whether a flaw is real or merely theoretical. For IAM and NHI governance, the same limitation applies to credentials and access patterns that only fail when a system is live.

The first-order problem is not whether automated code review is useful. It is whether teams mistake static analysis for evidence of exploitability, or assume that finding a flaw in source code is equivalent to validating the control environment. In practice, application security programmes need both code-side review and runtime testing, especially where authentication, authorization, secrets, and service-to-service access intersect.

MindFort frames the boundary clearly, and that is a typical but still frequently misunderstood position in mature security teams. The gap is not whether code review exists, but whether organisations treat it as a substitute for proof at runtime.

Key questions

Q: How should security teams combine code review and penetration testing?

A: Use code review to find likely defects early, then use penetration testing to confirm whether those defects are exploitable in the deployed system. The two controls answer different questions. One identifies risk in source code, while the other validates behaviour under real runtime conditions, including configuration, trust boundaries, and chained attack paths.

Q: Why do static findings often overstate or understate real risk?

A: Static findings are disconnected from runtime state, so they can flag patterns that never become exploitable or miss flaws that only emerge after deployment. Real risk depends on configuration, service interactions, identity trust, and whether an attacker can chain the issue into impact. That is why runtime validation is essential.

Q: What do teams get wrong about AI code review and security gates?

A: Many teams assume human review can reliably catch dangerous AI output if they add it to existing workflows. In practice, fluent but insecure code can pass cursory inspection. The mistake is treating AI as a productivity layer only, rather than as a source of untrusted input that needs automated verification.

Q: When should organisations require runtime validation before sign-off?

A: Require runtime validation whenever a finding could affect authentication, authorization, secrets, session handling, or any path where identity controls determine access. Those are the cases where source code alone cannot show whether the issue is exploitable. If the control outcome matters in production, the deployed system must be tested.

Technical breakdown

Why static code review cannot prove exploitability

Static application security testing inspects source code, data flows, and known insecure patterns without executing the application. That makes it useful for finding injection risks, broken access control patterns, and authentication mistakes early, but it cannot observe runtime state, external dependencies, or the exact sequence needed to turn a defect into a working exploit. In other words, it identifies possible weakness, not confirmed exposure. Practical implication: treat code review as a prioritisation layer, then validate the highest-risk findings in a live environment.

Practical implication: use static review to triage, then confirm exposure with runtime testing before you treat a finding as material.

What penetration testing adds that code review cannot

Penetration testing evaluates the deployed system from the outside in. It can validate exploitability, chain multiple flaws, test access control in context, and surface weaknesses in configuration, deployment, and service interactions that never appear in source code. This is especially important where security depends on identity boundaries, because authentication, session handling, and authorization decisions are often distributed across services and layers. Practical implication: reserve pen testing for verifying whether a code issue survives contact with the real environment.

Practical implication: use penetration tests to prove whether a suspected flaw survives deployment, configuration, and live control enforcement.

Why identity and secret handling still need runtime assurance

Identity-related failures often look harmless in code but become high impact when credentials, tokens, or service accounts are active in production. A source scan may reveal a secret reference or an authorization defect, yet it cannot tell you whether that secret is valid, whether the access is over-scoped, or whether a downstream service trusts it too broadly. That is why runtime evidence matters for NHI and IAM controls. Practical implication: validate secrets, service accounts, and authorization paths where they actually operate, not just where they are declared.

Practical implication: test the actual identity and secret paths in production-like conditions, not only the source declarations.

NHI Mgmt Group analysis

Static review and runtime exploitation solve different governance problems. Code review tells teams where defects may exist, but only runtime testing tells them whether those defects translate into actual exposure. That is why collapsing SAST and penetration testing into one control category creates false confidence. In identity-heavy applications, the control failure often appears only when tokens, sessions, and service trust are exercised in production. Practitioners should preserve the distinction, because assurance depends on evidence, not code patterns alone.

Claude Code Security exposes a broader governance gap: evidence from source is not evidence from the system. Security programmes increasingly automate analysis early in the SDLC, but deployment creates a second control surface with different risks. The article reinforces a named concept we see repeatedly: runtime assurance gap. When teams stop at code review, they miss exploit chaining, configuration drift, and identity abuse that only emerges after release. Practitioners should require separate control objectives for code findings and live validation.

NHI and IAM controls are especially vulnerable to this confusion because identity trust is contextual. A source-level authorization bug may look narrow until a service account, API token, or delegated identity turns it into lateral movement or data access. That makes runtime proof essential for any application where machine identities carry privileges across systems. For practitioners, the lesson is to evaluate identity control effectiveness in the deployed path, not as a static property of the codebase.

This debate is not about replacing automation with manual work, but about assigning each control to the right layer. Automated review accelerates detection, while runtime assessment establishes whether the finding matters operationally. That division aligns with mature security governance across application security, PAM, and NHI programmes. Practitioners should document which issues are code defects, which are deployment defects, and which are true exploitable conditions.

The market signal is clear: AI-assisted review will expand, but assurance expectations will not shrink. As more teams use AI to inspect code, the pressure increases to prove that findings survive in the live environment. That will drive stronger coupling between CI/CD review, dynamic testing, and identity-aware verification. Practitioners should plan for a blended assurance model, not a single automated gate.

What this signals

Static review will keep expanding as AI-assisted development accelerates, but the programme risk is unchanged: code inspection cannot prove control effectiveness in a live system. Security leaders should therefore expect stronger linkage between source review, runtime validation, and identity-aware testing, especially where service accounts and tokens carry production trust.

Runtime assurance gap: Teams that equate source findings with exploit proof create a control blind spot that is especially dangerous in identity-heavy applications. The right response is not to abandon automation, but to connect it to runtime evidence and to authoritative control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls.

For NHI and IAM programmes, the practical shift is toward validating secrets, authorization, and delegated access where they execute, not where they are declared. That will push more teams to pair CI/CD review with live testing and to use breach evidence, including the DeepSeek breach, as a reminder that exposed credentials become operational risk fast.

For practitioners

• Separate code findings from exploit findings Classify static review output as candidate risk, then require live validation before elevating a defect to a confirmed control failure.
• Add runtime checks for identity-sensitive paths Prioritise endpoints that handle tokens, service accounts, authorization decisions, or delegated access, because those controls can only be tested in execution.
• Chain SAST with DAST or pen testing Use static review to find likely flaws, then test the same paths in a deployed environment to confirm exploitability and business impact.
• Review secrets and permissions in production-like contexts Validate whether a discovered secret is active, whether the credential scope is excessive, and whether the surrounding service trust is broader than intended.

Key takeaways

• Claude Code Security is useful for source review, but it does not replace penetration testing because it cannot validate exploitability in a live system.
• The key control gap is runtime assurance, especially where identity, secrets, and authorization decide whether a code defect becomes real exposure.
• Practitioners should pair static analysis with deployed-system testing so that findings are confirmed, prioritised, and tied to actual business risk.

Key terms

• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Penetration Testing: Penetration testing is an authorised adversarial exercise that tries to exploit weaknesses the way a real attacker would. It validates whether a vulnerability, misconfiguration, or access weakness can become actual reach, escalation, or lateral movement.
• Runtime assurance: Runtime assurance is the practice of validating how an application actually behaves after deployment. It matters because configuration, identity flow, and integration state can change security outcomes in ways that source code analysis alone cannot prove.
• Identity-Sensitive Path: An identity-sensitive path is any application flow where access depends on a credential, token, session, service account, or delegated identity. These paths are high value because a defect may look minor in code but become a major exposure once the deployed system evaluates trust in context.

What's in the full article

MindFort's full blog covers the operational detail this post intentionally leaves for the source:

• How Claude Code Security is wired into a /security-review workflow and GitHub Action
• Examples of the vulnerability classes MindFort says Claude can and cannot surface in practice
• The specific runtime testing gaps that separate static review from penetration testing
• MindFort's own comparison of AI-assisted review versus deployed-system validation

👉 The full MindFort post covers the code-side limits, runtime gaps, and testing distinctions in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the broader security programme they already run.