How to run a three-pass security audit using Claude

A dev.to author provides a structured methodology and a specific prompt for using Claude to find common vulnerabilities, claiming to compress a multi-week audit into hours.

A typical security audit can cost upwards of $10,000 and take two to three weeks. A developer on the platform Dev.to, writing under the handle 'spyrae', claims to have compressed the initial audit phase into a few hours using a structured, three-pass methodology with Anthropic's Claude.

The author reports finding 15 distinct vulnerabilities in production code by applying this process. While the cost and time savings are unverified claims, the methodology itself is a repeatable playbook for using a large language model to perform a baseline security review. An LLM can compress the initial audit down to a few hours because it scans code for patterns rather than specific CVEs.

The three-pass audit methodology

The process is broken into three distinct stages to manage the LLM's output and reduce noise. The goal is to move from broad pattern recognition to specific, verified findings.

First is a broad scan. The entire project's codebase is fed to the LLM with a prompt designed to look for general vulnerability patterns. This pass generates a high-level list of potential issues.

Second is a deep analysis. Each potential issue identified in the first pass is examined in its specific context. This requires checking middleware, ORM configurations, and framework-specific security features that the LLM might not have fully understood.

Third is manual verification. The author states this step is critical because LLMs produce false positives. A human developer must review every finding to confirm it represents a genuine, exploitable vulnerability in the application's logic.

A prompt that structures the output

The effectiveness of the broad scan depends entirely on the initial prompt. The author provides a specific prompt engineered to force a structured, security-focused response from Claude:

Perform a security audit of this code. For each finding, include:
1. CWE ID and name
2. OWASP Top 10 category
3. Severity (Critical/High/Medium/Low)
4. The vulnerable code snippet
5. Attack vector -- exactly how an attacker would exploit this
6. Fixed code

Ignore stylistic comments. Focus on security only. Start with injection attacks, then broken access control, then the rest.

This prompt works by defining the exact output format and prioritizing the most critical vulnerability categories first. According to the post, without this structure, an LLM tends to mix severe security flaws with low-priority notes on code style or email validation regex.

A common finding: SQL injection

The most frequent vulnerability the author claims to have found was SQL injection, specifically in cases where developers bypassed an ORM for raw SQL queries. The LLM identified a common pattern where user input from a query string was directly concatenated into a SQL statement.

For example, an API endpoint for user search used req.query.search and req.query.sortBy to build a query string. This allowed an attacker to inject malicious SQL, such as '; DROP TABLE users; --, by manipulating the URL parameters. The fix involves using parameterized queries, which separates the SQL command from the user-provided data.

What We'd Change

This playbook is a powerful starting point for continuous internal review, but it is not a replacement for a professional security audit. The author correctly highlights the risk of false positives, but the risk of false negatives, where the LLM misses a subtle or novel vulnerability, is more severe. An AI does not understand business logic, a common source of access control flaws.

The entire process is also brittle. It relies on a prompt fine-tuned for a specific version of Claude. As models are updated, the prompt's effectiveness may degrade, requiring constant re-validation. This playbook works today, but it is not a static asset. Teams must treat their audit prompts like any other piece of critical infrastructure, with versioning and regression testing.

Finally, the output should be treated as a list of leads, not a definitive audit report. Each finding requires human investigation to confirm exploitability. Over-reliance on the AI's initial severity assessment could lead teams to deprioritize a genuinely critical flaw that the model miscategorized as 'Medium' or 'Low'.

Landing

Using an LLM for security reviews lowers the barrier to entry for finding common vulnerabilities listed in the OWASP Top 10. The provided three-pass method brings structure to the process, turning the model into a useful assistant rather than a noisy chatbot. It effectively democratizes the first 20% of a security audit. The remaining 80%, which requires deep contextual understanding and adversarial thinking, remains a human domain. For founders, this is a near-zero-cost way to improve code hygiene, but it does not absolve them of the need for rigorous, expert-led security verification for critical applications.

The investor read

This playbook signals the commoditization of baseline code security analysis. While not a replacement for professional penetration testing, AI-driven audits raise the security floor for bootstrapped and early-stage startups. Companies can now perform continuous, near-zero marginal cost checks, making a failure to do so a sign of poor engineering discipline. The investment opportunity lies not in replacing human auditors, but in building 'human-in-the-loop' services and developer tools that integrate this AI-first pass. These tools would use models for the initial 80% scan and provide expert human verification for the critical 20%. Traditional security consulting firms charging five figures for basic OWASP Top 10 scans are now under significant pressure from this technology.

Pull quote: “An LLM can compress the initial audit down to a few hours because it scans code for patterns rather than specific CVEs.”