TL;DR: A static code-review layer can flag vulnerabilities and suggest patches, but it cannot attack a live application, prove exploitability, or chain findings into account takeover, according to MindFort. That boundary still matters because runtime validation remains the only way to confirm whether code defects become real security exposure.
At a glance
What this is: MindFort argues that Claude Code Security is a static code-review tool, not a penetration test, because it can inspect source and suggest fixes but cannot exploit a live system or validate real-world attack paths.
Why it matters: For IAM and security teams, the boundary matters because code-level findings do not prove business risk, runtime exposure, or whether deployed controls actually withstand attack.
Context
Claude Code Security sits in the review layer, where the question is whether source code contains patterns that could become vulnerabilities. Penetration testing sits in the validation layer, where the question is whether those weaknesses can be exploited in a deployed environment. The governance gap is assuming these are interchangeable assurance methods when they answer different security questions.
In identity-heavy systems, that distinction matters because authentication, authorisation, and session logic often look safe in code but fail when combined with configuration, runtime state, and chained workflows. Static review can surface suspicious access-control logic, but only runtime testing can show whether the control actually protects the application under attack. That boundary is typical, not an edge case.
Key questions
Q: When does static code review fail as a security control?
A: Static code review fails when teams treat suspicious code as proof of exploitability. It can identify likely flaws, but it cannot show whether the deployed application, configuration, or identity flow actually allows an attacker to succeed. Runtime validation is needed whenever the decision depends on real-world behaviour rather than code patterns alone.
Q: Why do identity and access flaws often require runtime testing?
A: Because the control that matters is enforced in the live application, not in the source tree. Authentication state, sessions, tokens, upstream services, and authorization decisions all affect whether a weakness can be exploited. Static review can suggest a problem exists, but runtime testing shows whether the access boundary actually fails in production.
Q: What do security teams get wrong about code quality tools?
A: They often treat code quality tools as development hygiene instead of risk controls. In regulated environments, these tools should detect secrets, vulnerabilities, and maintainability defects early enough to prevent rework and exposure. The mistake is allowing them to remain advisory when they need to be policy enforcing.
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.
Technical breakdown
Static code review versus runtime exploitation
Static application security testing examines source code, syntax, and patterns that resemble known weaknesses. It can identify risky flows, insecure comparison logic, or missing guardrails before release. Penetration testing starts from a running target and attempts to trigger the weakness in context, which means it can validate exploitability, environmental preconditions, and chained outcomes. The two methods produce different evidence. One tells you where the code looks weak. The other tells you whether the deployed system can actually be attacked. That difference is critical when security teams need assurance rather than suspicion.
Practical implication: Treat code review as a discovery control and penetration testing as a validation control, not as substitutes.
Why identity and access flaws need live testing
Access control and authentication flaws are especially sensitive to runtime context because source code rarely captures all the conditions that govern real enforcement. A code path may look correct while a token scope, session state, downstream API, or deployment setting changes the outcome. This is why a static checker can spot broken access-control patterns, yet still miss whether a user can move from one role to another, reuse a session, or chain a partial flaw into account takeover. Identity logic is distributed across code, configuration, and infrastructure, so proof requires execution, not inspection alone.
Practical implication: Validate access-control and authentication assumptions in the running environment, especially where identity state is distributed.
Why chained vulnerability paths are outside code review
A vulnerability chain is not just a list of defects. It is an attack path that combines multiple weaknesses into a meaningful outcome such as privilege gain, data exposure, or account takeover. Static tools can surface components of the chain, but they cannot reliably simulate the sequence of requests, branching behaviour, and environmental dependencies needed to prove the final impact. That is why the article draws a hard line between patch suggestions and exploit proof. The same limitation applies to infrastructure and deployment issues, which may never be visible in source control at all.
Practical implication: Use dynamic testing to confirm whether individual findings combine into a real attack path before accepting risk closure.
Threat narrative
Attacker objective: The attacker wants to turn a code-level weakness into a verified live compromise that produces real access, data exposure, or control bypass.
- Entry occurs through code paths that appear vulnerable during static review, but the weakness is not yet proven in a live environment.
- Credential or access control weaknesses only become meaningful if a runtime test can show that the application actually accepts the malicious flow.
- Escalation happens when multiple findings are chained into a broader compromise such as unauthorised access or account takeover.
- Impact is confirmed only when the deployed system is shown to leak data, bypass controls, or execute attacker-controlled actions.
Breaches seen in the wild
- Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static review and runtime validation solve different governance problems: one identifies suspicious code, the other proves whether the deployed control actually fails. Security programmes get into trouble when they treat code inspection as evidence of exploit resistance. The practical conclusion is that assurance must be staged, with static analysis feeding dynamic verification.
Identity logic is the boundary where static tools most often overstate confidence: authentication, authorisation, and session behaviour depend on state outside the code file. That means a clean review result does not guarantee that access control survives deployment, integration, or chaining. Practitioners should treat runtime proof as mandatory for access-sensitive paths.
Code review cannot substitute for attack-path validation: a list of plausible flaws is not the same as a demonstrated compromise path. The central governance question is whether the organisation can show exploitability, not whether a model can infer it. That shifts security sign-off from pattern recognition to evidence-based testing.
Exploitability is the named concept teams should watch: a finding only becomes operational risk when an attacker can make it work against the live system. Claude Code Security can narrow review time, but it cannot establish exploitability on its own. Programmes should use this distinction to separate developer remediation from formal security assurance.
Runtime evidence remains the decisive control signal for security decisions: source-code findings help prioritise work, but release gates, risk acceptance, and control attestation should depend on verified behaviour in the deployed environment. The practitioner conclusion is simple: review early, test live, and do not collapse the two.
What this signals
Exploitability proof is the missing control boundary: teams that merge static review and pen testing into one assurance story lose the ability to say what was actually verified. That weakens sign-off for authentication, authorisation, and chained attack paths because the evidence no longer distinguishes suspicious code from confirmed compromise.
Claude Code Security can improve developer workflow, but the governance task is to keep review outputs from being mistaken for security assurance. In practice, that means security teams should route code findings into remediation, then require live-system validation before accepting residual risk.
For practitioners
- Separate review from validation Use Claude Code Security only for source-code review and reserve penetration testing for proving behaviour in the running application and deployed infrastructure.
- Gate high-risk identity logic with runtime tests Require dynamic checks for authentication, authorisation, session handling, and privilege transitions before you treat a code finding as closed.
- Test chained exploit paths Verify whether multiple low-severity findings combine into account takeover, data exposure, or privilege escalation instead of closing them as isolated issues.
- Keep CI review and security assurance distinct Use code review in the pull-request workflow, but make release decisions on evidence from live-system exploitation and retesting.
Key takeaways
- Claude Code Security can improve source-code review, but it does not replace dynamic testing because exploitability, runtime state, and deployed configuration change the security outcome.
- The practical gap is not finding defects, but proving whether those defects can be turned into access, data exposure, or control bypass in a live system.
- Security programmes should use static review for early detection and penetration testing for evidence-based assurance, especially on identity and access logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | The article centres on where static review cannot validate authentication behaviour in a live system. |
| V8 — Authorization | The core boundary is whether authorisation defects are exploitable at runtime, not merely present in code. | |
| V16 — Security Logging and Error Handling | Runtime validation depends on observable evidence from the deployed application, not static inference alone. | |
| Recommendation — Use V6 to test authentication behaviour in the running application, not just the source code. Apply V8 to verify that authorisation enforcement holds across deployed flows and chained requests. Use V16 to confirm logging and error handling expose real attack behaviour during live testing. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's concern is whether code-side flaws can become real attack paths leading to access and movement. |
| Recommendation — Map confirmed exploit paths to TA0006 and TA0008 so the team tests how a flaw becomes access or movement. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on whether access controls work as designed once code is deployed. |
| Recommendation — Validate PR.AA-05 in live environments before you accept static review as evidence of control effectiveness. | ||
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.
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
- Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a fit for teams that need stronger identity governance across modern security programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org