Source note
Leveling Up Secure Code Reviews with Claude Code
Secure Code ReviewLLM Assisted AnalysisCode IntelligenceApplication SecurityPrompt Engineering
Summary
This post argues that Claude Code helps human-led secure code review move faster on unfamiliar codebases when the prompts carry strong application context and response rules. The author uses it as a code-understanding assistant, not as an autonomous vulnerability finder, to cut false positives and produce readable security-focused walkthroughs.
Problem
- Manual secure code review is slow when the tester lands in an unfamiliar language, framework, or architecture during a penetration test.
- Generic "find vulnerabilities" prompting produces many weak findings and false positives that still need manual triage.
- Complex paths such as async worker pipelines and multi-stage request handling are hard to trace by hand, which can hide security-relevant input flows.
Approach
- The method centers on a detailed system prompt that gives Claude Code the application description, authorization model, API references, component paths, expected output format, and a security-review persona.
- The reviewer starts a fresh interactive Claude session for each investigation thread, then asks narrow questions such as enumerating daemons or tracing one HTTP endpoint end to end.
- Claude is asked to produce a digestible code-flow walkthrough with code snippets, source and sink mapping, positive security observations, control gaps to inspect, and confidence levels.
- The workflow keeps the human in charge: the reviewer accepts or rejects Claude's annotations, updates the prompt context when Claude gets facts wrong, and uses a separate
[TeachMe]mode for targeted explanations of language or framework behavior. - The post also recommends self-hosted or local deployment for private code to avoid sending client IP to public hosted models.
Results
- The post provides no formal benchmark, dataset-wide metric, or controlled comparison.
- In BloodHound Community Edition, Claude identified async daemons, grouped them by function, and reported that workers consume jobs from 3 PostgreSQL tables, which the author used to prioritize tampering analysis.
- For the
POST /api/v2/graphs/cypherpath, Claude reconstructed an end-to-end flow from router registration through parsing and query generation; the author says this exposed that submitted Cypher is tokenized with ANTLR, filtered for mutations and blocked procedures, then translated into PostgreSQL queries. - Based on that walkthrough, the author concludes the implementation "effectively negates traditional SQL injection" for that path, while still leaving room to inspect procedure-filter oversights and access-control questions.
- Claude made at least one factual error during analysis, claiming Neo4j was the database; the author corrected this by storing the fact that BloodHound uses PostgreSQL and DAWGS handles Cypher-to-PostgreSQL translation.
- On BadWindowsService, Claude judged the service intentionally vulnerable and produced a table of security-relevant features plus a follow-up proof-of-concept PowerShell script, but the author says the vulnerability list was not comprehensive.