You've probably already experimented with Claude or GPT-4 for code review. Maybe you've been impressed by how quickly these models spot obvious SQL injection patterns or flag hardcoded credentials. The question isn't whether to use LLMs for security work—it's how to use them without creating new blind spots in your detection coverage.
This checklist guides you in building a hybrid security workflow that combines LLM capabilities with traditional static analysis, dynamic testing, and human expertise. Each item includes specific integration points and what success looks like in practice.
What This Checklist Covers
This guide helps you establish controls around LLM use in vulnerability detection while maintaining coverage required by PCI DSS v4.0.1 Requirement 6.3.2 (security testing throughout development) and SOC 2 Type II CC7.1 (detection of security events). You'll define when to use LLMs for triage, when to escalate to specialized tools, and how to validate LLM findings before acting on them.
Prerequisites
Before implementing this checklist:
- Baseline tooling: You need at least one SAST tool (like Semgrep, CodeQL, or SonarQube) and one DAST tool already running in your pipeline.
- Access controls: Your LLM integration must comply with data classification policies—no PII or production secrets in prompts.
- Cost visibility: You can track token consumption per repository or team (critical for the ROI analysis in item #8).
- Version control: All code under review is in Git with branch protection enabled.
Checklist Items
1. Define LLM scope boundaries for your codebase size and complexity
Document which repositories qualify for LLM-assisted review based on file count and architectural complexity. Even with 200k token context windows, LLMs lose track of code connections in complex architectures.
✓ Good looks like: A written policy stating "LLMs review files <500 lines with <3 module dependencies; escalate microservice orchestration code to SAST with dataflow analysis."
2. Establish LLM triage as first-pass only, never sole verification
Configure your pipeline so LLM findings trigger traditional tool scans rather than going directly to remediation. Using LLMs for initial triage and switching to specialized tools for deep analysis gives the best ROI.
✓ Good looks like: Your CI/CD runs LLM review on PR creation, flags high-confidence issues, then automatically queues flagged files for Semgrep deep scan before merge approval.
3. Validate LLM vulnerability classifications against OWASP Top 10 2021
LLMs often misclassify severity or miss context about exploitability. Create a mapping table that translates LLM output to OWASP categories and requires human confirmation for High/Critical ratings.
✓ Good looks like: A Jira automation that tags LLM-detected "SQL injection" findings with OWASP A03:2021 and assigns them to a senior engineer for exploit validation before sprint planning.
4. Implement token budget controls per review type
Set hard limits on context size sent to LLMs. This prevents runaway costs and forces you to use LLMs strategically rather than dumping entire repositories into prompts.
✓ Good looks like: Your review script caps LLM context at 50k tokens per PR, prioritizes changed files plus direct dependencies, and logs when it hits the limit so you can identify repos needing traditional tools.
5. Create fallback procedures for LLM service outages
LLM APIs go down. Your security pipeline can't. Define which traditional tools take over when your LLM integration returns errors for >15 minutes.
✓ Good looks like: A runbook stating "If Claude API fails health check 3x, pipeline automatically switches to CodeQL-only mode and posts Slack alert to #security-tooling."
6. Require human review for all authentication and authorization code
LLMs struggle with business logic flaws in access control. Flag files containing authentication middleware, permission checks, or role assignments for mandatory human review regardless of LLM findings.
✓ Good looks like: A pre-commit hook that detects imports from your auth library and adds a "needs-security-review" label that blocks merge until a staff engineer approves.
7. Log all LLM security findings with prompt context for audit trails
SOC 2 Type II CC7.2 requires you to analyze detected security events. You need to prove what code the LLM reviewed and what it found.
✓ Good looks like: Every LLM vulnerability finding writes a JSON log entry containing file hash, prompt sent, response received, timestamp, and model version to your SIEM.
8. Measure LLM ROI monthly: findings per dollar vs. SAST findings per dollar
Track how many true positives your LLM integration produces compared to cost. If your SAST tool finds the same issues for less money, adjust your LLM scope.
✓ Good looks like: A dashboard showing "Claude found 47 valid vulnerabilities in March at $340 ($7.23/finding); Semgrep found 52 at $200 ($3.85/finding)—reduce Claude scope to new code only."
9. Establish a false positive feedback loop
When your team marks an LLM finding as false positive, that context needs to improve future prompts. LLMs don't learn from corrections unless you build the feedback mechanism.
✓ Good looks like: A /false-positive Slack command that adds the code pattern to an exclusion list referenced in your LLM system prompt, reducing duplicate noise.
10. Document which vulnerability classes require specialized tools
LLMs can't replace tools built for specific detection tasks. List which finding types must use dedicated scanners.
✓ Good looks like: A security wiki page stating "Race conditions → ThreadSanitizer; Cryptographic weaknesses → Crypto-Lint; Dependency vulnerabilities → Snyk; LLMs handle input validation and injection patterns only."
Common Mistakes
Treating LLM output as ground truth: An LLM flagging a variable as "potentially user-controlled" doesn't mean it's exploitable. Always trace dataflow with a proper taint analysis tool before filing a security ticket.
Sending entire repositories as context: You'll burn through your token budget and get worse results. LLMs perform better on focused code sections with clear review objectives.
Skipping the cost analysis: One team spent $1,200/month on LLM code review before realizing their existing SAST tool caught 80% of the same issues at no marginal cost. Measure before you scale.
No validation against compliance requirements: PCI DSS v4.0.1 Requirement 6.3.2 mandates specific testing methods. Confirm your LLM integration doesn't create gaps in required coverage.
Next Steps
Start with one repository as a pilot. Run your LLM integration in parallel with existing tools for 30 days. Compare findings, measure costs, and identify which code patterns benefit most from LLM review. Then expand scope deliberately based on data, not hype.
Your goal isn't to replace traditional security tools—it's to use LLMs where they excel (fast triage, obvious patterns, developer education) and escalate to specialized tools for deep analysis. The teams seeing real value treat LLMs as one component in a layered defense, not a silver bullet.
