[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-93230":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":10,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":21,"hasPages":19,"topics":22,"createdAt":10,"pushedAt":10,"updatedAt":30,"readmeContent":31,"aiSummary":32,"trendingCount":15,"starSnapshotCount":15,"syncStatus":14,"lastSyncTime":33,"discoverSource":34},93230,"local-vuln-research-pipeline","theteatoast\u002Flocal-vuln-research-pipeline","theteatoast","Fully local vulnerability research pipeline - 14B code-specialized LLM reviews every source file exhaustively.","",null,"Python",151,20,2,0,3,48,47.27,false,"main",true,[23,24,25,26,27,28,29],"agents","ai","offensive-security","pentest","qwen","redteam","vulnerability-research","2026-07-22 04:02:08","\u003Cp align=\"center\">\n  \u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLVRP-local--first-blue?style=for-the-badge\" alt=\"LVRP\">\n\u003C\u002Fp>\n\n# LVRP - Local Vuln Research Pipeline\n\nExhaustive LLM-driven whitebox vulnerability research pipeline that finds vulnerabilities in any source code. Built on a code graph + LLM hybrid architecture that enumerates and validates all source-to-sink paths.\n\nScales from small scripts to enterprise codebases: Linux Kernel, VSCode, Microsoft Agent Framework, GitHub Desktop.\n\n---\n\n## What It Does\n\nFinds every valid vulnerability in source code through exhaustive enumeration:\n\n1. Parses every source file across 16 languages\n2. Builds a complete call graph with cross-file imports\n3. Tags every untrusted input source and dangerous operation sink\n4. Enumerates every source-to-sink path through the call graph\n5. Tracks taint through each function on each path (intra- + inter-procedural)\n6. Cross-references sanitizers against sink categories via normalized taxonomy\n7. Validates ambiguous paths with LLM for genuine exploitability\n8. Auto-classifies clear-cut cases deterministically (sanitizer match → blocked)\n9. Sweeps every file NOT covered by paths with a blind-spot code review (Project Black methodology)\n10. Injects relevant product CVEs into every LLM prompt for pattern matching\n11. Analyzes memory corruption for C\u002FC++\u002FRust codebases\n12. Synthesizes multi-step exploit chains via networkx transitive closure\n\nEvery source (untrusted input entry point) is paired with every compatible sink (dangerous operation) and all call-graph paths between them are enumerated. Nothing is sampled. The path enumeration is always exhaustive — LLM validation depth scales with your hardware (see [Exhaustive vs Smart](#exhaustive-mode-vs-smart-mode)).\n\n---\n\n## Architecture\n\n```\n[Target Repo]\n    |\nStep 0  - Fingerprint + SBOM              (deterministic, full file inventory)\nStep 1  - Classify target                 (16+ target types, dual-language detection)\nStep 2  - Dependency vuln scan            (NVD + EPSS\u002FKEV ranked)\nStep 2b - Secrets scan                    (gitleaks rules)\nStep 3  - Static analysis                 (Semgrep scan + file inventory)\nStep 3b - Code graph construction         (call graph + source\u002Fsink\u002Fsanitizer tags + memory analysis)\nStep 4  - Threat model + CVE catalog      (1 LLM pass, product-specific CVE search)\nStep 4b - Path enumeration               (exhaustive source-to-sink path discovery + inter-procedural taint)\nStep 4c - Per-path LLM analysis           (exploitability validation, one path at a time + CVE context)\nStep 4d - Blind spot coverage             (file-by-file LLM review of all uncovered source files)\nStep 5  - Memory findings extraction      (results from step 3b's memory analysis)\nStep 6  - Chain synthesis                 (networkx attack graph + transitive closure)\nStep 7  - Validation                      (confidence-based filtering)\nStep 8  - Anomaly check                   (prompt injection detection)\nStep 9  - Report + PoC                    (root cause, exploit path, remediation)\n    |\nOutput: Verified findings with proof of exhaustive coverage\n```\n\nThe code graph is built deterministically. The LLM is used only for exploitability reasoning on pre-traced paths, never for discovery.\n\n---\n\n## Supported Targets\n\n| Target | Language | Size | Status |\n|--------|----------|------|--------|\n| Linux Kernel | C | ~30M LOC | Supported via memory analysis + call graph |\n| VSCode | TypeScript | ~400K LOC | Full tree-sitter parsing + path enumeration |\n| Microsoft Agent Framework | C# \u002F .NET | Varies | Full C# sink coverage |\n| GitHub Desktop | TypeScript \u002F Electron | ~200K LOC | TypeScript + Node.js patterns |\n| React, Angular, Vue | JS\u002FTS | Varies | SSTI, XSS, prototype pollution |\n| Django, Flask, Express | Python\u002FJS | Varies | HTTP routes, ORM, auth decorators |\n| Spring Boot | Java | Varies | All Spring annotations, SpEL, deserialization |\n| Go services | Go | Varies | All Go sinks, goroutine races |\n| Rust crates | Rust | Varies | Memory safety + unsafe FFI |\n\n### Theoretical Limits\n\nWhat the system can do:\n- Exhaustively enumerate all statically resolvable source-to-sink paths\n- Find every injection vulnerability (command, SQL, path, SSRF, SSTI, etc.)\n- Find every deserialization vulnerability\n- Find every auth bypass and access control issue\n- Find every memory corruption issue in C\u002FC++\u002FRust\n- Find every hardcoded credential\n- Find every race condition and TOCTOU\n- Find every XXE, LDAP injection, XPath injection\n- Find every weak crypto and weak random usage\n\nKnown fundamental limits (inherent to static analysis):\n- Dynamic dispatch through function pointers in C: conservatively flagged, exact target unknown without runtime info\n- Virtual dispatch through vtables in C++\u002FJava\u002FC#: conservative resolution\n- Reflection-based calls: flagged as suspicious with severity based on context\n- C macros: AST parser does not expand macros\n- Assembly code: not analyzed\n- Cross-translation-unit inlining in C: call graph shows as separate functions\n\nFor these edge cases, the system reports them as uncertain via LLM analysis rather than giving false negatives.\n\n---\n\n## Hardware Requirements\n\nTested configuration:\n- GPU: RTX 4070 Ti SUPER (16GB VRAM)\n- CPU: Ryzen 7 7700 (8C\u002F16T)\n- RAM: 32GB DDR5 6000MHz\n- Model: Qwen2.5-Coder-14B-Abliterated Q4_K_M (14B dense, 8.6GB)\n- Draft model: Qwen2.5-Coder-0.5B Q4_K_M (~400MB) for speculative decoding\n- Total VRAM: ~9GB models, ~7GB free for KV cache\n- Performance: 25-35 tok\u002Fs base, 35-50 effective tok\u002Fs with speculative decoding\n- Context: 32K tokens (model training limit)\n- Server: llama.cpp with jinja, flash attention, Q4 KV cache\n\n---\n\n## Installation\n\n### 1. Install llama.cpp\n\n```powershell\nwinget install llama.cpp      # Windows\nbrew install llama.cpp         # macOS \u002F Linux\npip install -r requirements.txt\npip install huggingface_hub\n```\n\n### 2. Download Models\n\n```powershell\nhuggingface-cli download bartowski\u002FQwen2.5-Coder-14B-Instruct-abliterated-GGUF `\n  Qwen2.5-Coder-14B-Instruct-abliterated-Q4_K_M.gguf --local-dir models\u002F\n\nhuggingface-cli download bartowski\u002FQwen2.5-Coder-0.5B-Instruct-abliterated-GGUF `\n  Qwen2.5-Coder-0.5B-Instruct-abliterated-Q4_K_M.gguf --local-dir models\u002F\n```\n\n### 3. Start Model Server\n\n```powershell\npython start_server.py\n```\n\nReads model path from `config.yaml`. Use `--no-speculative` to disable speculative decoding.\n\n### 4. Get NVD API Key\n\nhttps:\u002F\u002Fnvd.nist.gov\u002Fdevelopers\u002Frequest-an-api-key (30 seconds)\n\n### 5. Download CVE Database\n\n```powershell\n$env:NVD_API_KEY=\"your-key-here\"\npython -m src.main update-cve\n```\n\nThis downloads ~45 minutes of data: 364K+ CVEs with EPSS + KEV, product-specific search.\n\n### 6. Estimate Resources (Optional)\n\n```powershell\npython -m src.main estimate \u002Fpath\u002Fto\u002Ftarget-repo\n```\n\n### 7. Run Audit\n\n```powershell\npython run_audit.py \u002Fpath\u002Fto\u002Ftarget-repo\npython run_audit.py \u002Fpath\u002Fto\u002Ftarget-repo --resume   # resume from checkpoint\n```\n\n---\n\n## Pipeline Details\n\n### Step 3b: Code Graph Construction\n\nBuilds the complete foundation for exhaustive analysis:\n- AST parsing: 9 languages via tree-sitter, 7 via regex fallback\n- Call graph: every function to every callee, direct + virtual dispatch, cross-file via import resolution\n- Call sites: arguments extracted from every call expression for inter-procedural taint\n- Source tags: every untrusted entry point annotated with source type\n- Sink tags: every dangerous operation tagged with vulnerability class\n- Sanitizer tags: every validator, encoder, auth check identified with `protected_against` categories\n- Memory analysis: 5 parallel analyzers run inline for C\u002FC++\u002FRust\n\n### Step 4b: Path Enumeration\n\nFor every source-to-sink pair that is compatible:\n1. Use the call graph to find all call paths from source to sink\n2. Trace taint through each function on the path (intra-procedural + inter-procedural accumulation)\n3. Cross-reference sanitizers against sink categories using a normalized taxonomy -- sanitizer `protected_against` values are mapped to sink categories via `SINK_TO_SANITIZER_TAXONOMY`\n4. Blocked paths still proceed to LLM analysis (sanitizer effectiveness verified, not blind-trusted)\n5. Record the complete path inventory\n\nA medium codebase (~800 files) might produce 5,000-50,000 source-to-sink paths. Large codebases (Linux kernel, VSCode) use chunked processing and path prioritization to scale to millions of paths.\n\n### Step 4c: Per-Path LLM Analysis\n\nFor each enumerated path:\n1. Paths are deduplicated by unique (source, sink, category) combination\n2. Clear-cut cases get deterministic verdicts: sanitizer-taxonomy match → auto-BLOCKED, unreachable sink → auto-BLOCKED\n3. Only ambiguous paths go to the LLM (real function chains, taint present, no matching sanitizer)\n4. **Smart prioritization** (hardware-aware — scales to any GPU):\n   - The system enumerates ALL paths but adapts LLM analysis to your hardware\n   - Default smart limit (~2000 paths, ~1 hr on RTX 4070 Ti) ensures zero missed CRITICAL\u002FHIGH vulns\n   - **Have better hardware?** Set `smart_limit_max: 0` in config.yaml to analyze literally every single path — true exhaustive coverage. A 4090 or multi-GPU setup can run 16-32 workers and chew through 100K+ paths\n   - Coverage guarantee: ≥1 path per unique sink category in the codebase — no vuln class is ever skipped\n   - Context-aware vuln class weights: Python repos boost SSTI\u002Fdeserialization; C repos boost memory corruption; Java repos boost deserialization\u002FSpEL\n   - Adaptive cap: small repos (\u003C5000 paths) automatically analyze everything regardless of limit\n5. Every LLM prompt includes relevant CVE examples matching the path's CWE + product stack\n6. `max_llm_paths: 0` enables automatic smart limit (`smart_limit_max` config key, default 2000). Set a number for exact cap\n7. **Intra-step checkpointing**: each path result saved incrementally to `path_analysis_progress.jsonl`. Interrupted? `--resume` picks up from the last completed path — zero work lost\n8. Self-consistency: uncertain\u002Flow-confidence verdicts get 3 runs at temp 0.4; majority vote breaks the tie\n\n### Step 4d: Blind Spot Coverage\n\nFile-by-file LLM sweep for every source file NOT covered by path analysis. Uses an adversarial red-team prompt: *\"You're the attacker who found a zero-day here last week. How do you break this file?\"* Single-file focus, ranked by lethality (RCE > file ops > auth bypass > info disclosure). Explicitly skips safe-but-incomplete checks and theoretical issues -- only reports concrete, exploitable findings.\n\n### Step 5: Memory Corruption + LLM Validation\n\nFive deterministic analyzers (allocation, buffer, lifetime, integer overflow, format string) flag memory issues via pattern matching on C\u002FC++\u002FRust. CRITICAL\u002FHIGH findings get LLM validation with source context around the flagged line: *\"Real vulnerability or false positive given bounds check \u002F safe API \u002F language safety?\"* Filters regex false positives before the report.\n\n### Step 6: Chain Synthesis\n\nBuilds an attack graph from all confirmed exploitable findings using networkx:\n- Findings are classified by vulnerability role (code_exec, file_access, information_theft, access_escalation, etc.)\n- Role transitions define valid chains: file_access → code_exec (LFI to RCE), information_theft → access_escalation (credential reuse), etc.\n- Computes full transitive closure via graph shortest paths -- A → C is valid if A → B → C exists\n- Chains up to 50 most confident multi-step exploits are surfaced\n\n### Steps 7-9: Validation, Anomaly, Report\n\n- Step 7: Confidence-based filtering -- CRITICAL and HIGH severity memory findings pass with >= 0.6 confidence; path analysis results are filtered by VERIFIED_EXPLOITABLE verdict\n- Step 8: Prompt injection detection via InjectionGuard statistical baseline\n- Step 9: Exhaustive report with coverage statistics, PoC ideas, and remediation\n\n---\n\n## Report Format\n\nEvery finding in the report includes:\n\n1. Summary: what the vulnerability is\n2. Root Cause: why it exists in the code\n3. Code Chain: exact data flow from source to sink\n4. PoC Steps to Reproduce: step-by-step instructions to trigger it\n5. Impact: concrete damage description\n6. Remediation: how to fix it with code examples\n7. How an Attack Can Exploit This: realistic attack scenario\n\nPlus overall Coverage Statistics showing:\n- Total source files parsed\n- Functions analyzed, call graph edges\n- Entry points identified\n- Sources, sinks, sanitizers tagged\n- Total paths enumerated\n- Paths analyzed by LLM\n- Verified exploitable, blocked, uncertain\n- Memory corruption findings\n- Exploit chains synthesized\n\n---\n\n## Vulnerability Coverage\n\n### Injection\n- Command injection (system, exec, subprocess, AddScript, PowerShell)\n- SQL injection (raw queries, ORM raw, second-order)\n- NoSQL injection (MongoDB $where, $expr, $function)\n- LDAP injection\n- XPath injection\n- SSTI (Server-Side Template Injection)\n- Header injection \u002F HTTP request smuggling\n\n### Deserialization\n- Python (pickle, marshal, yaml.load)\n- Java (ObjectInputStream, XMLDecoder, ysoserial gadgets)\n- .NET (BinaryFormatter, JavaScriptSerializer, TypeNameHandling)\n- Ruby (Marshal.load, YAML.load)\n- PHP (unserialize)\n\n### Memory Corruption (C\u002FC++\u002FUnsafe Rust)\n- Stack buffer overflow (strcpy, gets, sprintf)\n- Heap buffer overflow (memcpy with user-controlled size)\n- Use-after-free\n- Double-free\n- Null pointer dereference\n- Integer overflow leading to corruption\n- Format string vulnerability\n- Off-by-one\n- Type confusion\n\n### Path and File\n- Path traversal (directory traversal, zip slip)\n- Arbitrary file read\u002Fwrite\n- Insecure file permissions\n- TOCTOU (time-of-check time-of-use)\n- Symbolic link attacks\n\n### Network\n- SSRF (Server-Side Request Forgery)\n- HTTP request smuggling\n- Open redirect\n\n### Authentication and Authorization\n- IDOR (Insecure Direct Object Reference)\n- Missing function-level access control\n- Privilege escalation\n- JWT attacks (alg:none, no signature verification, key confusion)\n- OAuth redirect misuse\n- Hardcoded credentials\n- Weak session management\n\n### Cryptography\n- Weak algorithms (MD5, SHA1, DES, RC4)\n- Weak random (non-CSRNG for security)\n- Missing MAC\u002Fsignature\n- ECB mode\n- Static IV\u002Fnonce\n- TLS verification disabled\n\n### Business Logic\n- Parameter tampering\n- Race conditions (TOCTOU, double-spend)\n- Workflow bypass\n- Type confusion\n\n---\n\n## Time Estimates\n\nThe system auto-adapts to codebase size. LLM analysis (Step 4c) is the bottleneck — **these estimates assume an RTX 4070 Ti (8 parallel workers). Better hardware = faster, more coverage:**\n\n| GPU \u002F Workers | Paths\u002Fhr | Example (10K paths) | Example (100K paths) |\n|---------------|----------|---------------------|----------------------|\n| RTX 3060 \u002F 4 workers | ~1800 | ~5.5 hr | ~55 hr |\n| RTX 4070 Ti \u002F 8 workers | ~3600 | ~3 hr | ~30 hr |\n| RTX 4090 \u002F 16 workers | ~7200 | ~1.5 hr | ~14 hr |\n| Dual GPU \u002F 32 workers | ~14400 | ~45 min | ~7 hr |\n\nApproximate estimates with smart limit (crit+high always included):\n\n| Repo Size | Files | Source Files | Paths | Est. Time (8 workers) |\n|-----------|-------|-------------|-------|-----------------------|\n| Small (~200 files) | ~150 | ~100 | ~500 | 15-20 min |\n| Medium (~800 files) | ~600 | ~400 | ~3,000 | 45-60 min |\n| Large (~2,000 files) | ~1,400 | ~1,000 | ~15,000 | 1-2 hours |\n| Very Large (~5,000 files) | ~3,500 | ~2,500 | ~25,000 | 2-3 hours |\n| Enterprise (~30K+ files) | ~25K+ | ~8,000 | ~100,000 | 4-6 hours |\n\nNon-LLM steps (parsing, call graph, path enumeration) are deterministic and fast — ~5-20 min even for enterprise repos.\n\nPath analysis time ≈ paths × (15s \u002F workers). With 8 workers: ~2s per path.\n\n**To analyze literally every path** (true exhaustive mode): set `smart_limit_max: 0` in `config.yaml`. Time scales linearly with path count. Add more GPU workers via `parallel_analyzers` to reduce time proportionally.\n\nRun `python -m src.main estimate \u002Fpath\u002Fto\u002Frepo` for per-project estimates.\n\n### Exhaustive Mode vs Smart Mode\n\nThe system is designed to find **every** vulnerability — path enumeration is always exhaustive. The LLM analysis can be exhaustive or smart-prioritized, depending on your hardware:\n\n| Mode | Config | What it does |\n|------|--------|--------------|\n| **Exhaustive** | `smart_limit_max: 0` | LLM analyzes every single enumerated path. True 100% coverage. Requires serious hardware for large repos. |\n| **Smart (default)** | `smart_limit_max: 2000` | LLM analyzes top N paths + all CRITICAL\u002FHIGH sinks + coverage of every vuln class. Zero missed high-impact vulns. Runs comfortably on consumer GPUs. |\n\nEven in smart mode, non-LLM steps (parsing, call graph, path enumeration) are always exhaustive — every file, every function, every source-to-sink pair is enumerated. The smart limit only affects how many paths get LLM validation. If the deterministic code graph finds a sanitizer blocking a path, the verdict is instant (no LLM needed) and those paths don't count against the limit.\n\n**Scaling up**: add `parallel_analyzers: 16` (or 32) in config.yaml to double\u002Fquadruple LLM throughput. If you have access to cloud GPUs or a multi-GPU rig, set `smart_limit_max: 0` and `parallel_analyzers: 32` for true exhaustive analysis at enterprise scale.\n\n---\n\n## Scaling for Large Codebases\n\nThe system includes a dedicated scaling module (`src\u002Fanalysis\u002Fscaling.py`):\n\n### Chunking\n- Files processed in chunks of 500\n- Files larger than 10MB are skipped (likely generated)\n- Test and vendor directories are excluded\n- Per-directory processing for memory efficiency\n\n### Parallelism\n- Source, sink, sanitizer tagging parallelized across threads\n- Configurable worker count (default 16, up to 32 for enterprise)\n\n### Path Prioritization\n- Paths scored by severity, vulnerability class weight (context-aware by language\u002Fframework), function chain depth, and sanitizer presence\n- **Zero missed CRITICAL\u002FHIGH**: all CRITICAL and HIGH severity paths always analyzed, regardless of limit\n- **Coverage guarantee**: ≥1 path per unique sink category found in the codebase — no entire vuln class is ever skipped\n- **Context-aware weights**: C repos boost memory corruption; Python repos boost SSTI\u002Fdeserialization; Java repos boost serialization\u002FSpEL; JS repos boost prototype pollution\u002FNoSQL\n- Smart limit auto-activates when paths exceed `smart_limit_max` (default 2000). Set `smart_limit_max: 0` for unlimited\n- Deduplication by unique sink (file + line + category) prevents analyzing the same dangerous operation multiple times\n\n### Memory Management\n- Streaming report writer (findings written incrementally)\n- File size limits\n- Automatic config adaptation based on repo size\n\n### Adaptive Configuration\n\n| Files | Config Profile | Smart Limit | Workers |\n|-------|---------------|-------------|---------|\n| Under 100 | minimal | 200 | 4 |\n| Under 1000 | standard | 500 | 8 |\n| Under 10000 | large | 1000 | 16 |\n| 10000+ | enterprise | 2000 (adaptive) | 32 |\n\nSmart limit is a ceiling, not a quota — CRITICAL+HIGH paths are always included regardless of the limit.\n\nRun `python -m src.main estimate \u002Fpath\u002Fto\u002Frepo` to see estimated scope and time for any target.\n\n---\n\n## Checkpointing\n\nFull step-level checkpoints + intra-step incremental checkpoint for Step 4c (the longest step):\n\n```\ndata\u002Fcheckpoints\u002F\u003Chash>\u002F\n├── progress.md                     Human-readable: batch 87\u002F450, 23 candidates\n├── code_graph.json                 Complete code graph\n├── path_enum.json                  All source-to-sink paths\n├── path_analysis_progress.jsonl    [NEW] Incremental checkpoint: one line per analyzed path\n├── path_analysis.json              Final merged per-path LLM results\n├── chains.json                     Exploit chains\n├── report.md                       Final report\n```\n\n`path_analysis_progress.jsonl` is written atomically after each path is analyzed. If the process is interrupted (Ctrl+C, crash, power loss) during Step 4c, `--resume` picks up from the last completed path — zero work lost. No more restarting from scratch.\n\n---\n\n## Commands\n\n| Command | Description |\n|---------|-------------|\n| `python start_server.py` | Start server (reads model from config.yaml) |\n| `python start_server.py --no-speculative` | Start without draft model |\n| `python run_audit.py \u003Cpath>` | Full exhaustive audit |\n| `python run_audit.py \u003Cpath> --resume` | Resume from checkpoint |\n| `python -m src.main setup` | Setup instructions |\n| `python -m src.main update-cve` | Download\u002Fbuild CVE database |\n| `python -m src.main estimate \u003Cpath>` | Estimate resources for a target |\n\n---\n\n## Configuration\n\n```yaml\nmodel:\n  name: \"Qwen2.5-Coder-14B-Abliterated\"\n  file: \"models\u002FQwen2.5-Coder-14B-Instruct-abliterated-Q4_K_M.gguf\"\n\nserver:\n  context_length: 32768\n  flash_attn: true\n  speculative:\n    enabled: true\n\npipeline:\n  max_path_depth: 8\n  max_paths_per_pair: 20\n  max_llm_paths: 0               # 0 = auto smart limit, N = exact cap\n  smart_limit_max: 2000          # LLM path ceiling (0 = exhaustive — analyze ALL paths)\n  llm_temperature: 0.3\n  parallel_analyzers: 8          # LLM workers (scale with GPU: 4=3060, 8=4070Ti, 16=4090, 32=multi-GPU)\n\nscaling:\n  max_files_per_chunk: 500\n  max_file_size_bytes: 10000000\n  skip_test_directories: true\n  skip_vendor_directories: true\n  max_functions_per_chunk: 50000\n  max_paths_total: 100000\n  llm_priority_top_n: 1000\n  num_workers: 16\n  auto_adapt_to_size: true\n```\n\n---\n\n## Project Structure\n\n```\nmodels\u002F                              GGUF files (main + draft)\nsrc\u002F\n  orchestrator.py                    Master pipeline + checkpointing\n  main.py                            CLI entry point\n  pipeline\u002F\n    step0_fingerprint.py             Fingerprinting + file inventory\n    step1_classify.py                16+ target types\n    step2_deps.py                    Dependency vuln scan (NVD + EPSS\u002FKEV)\n    step2_secrets.py                 Secrets scanner (gitleaks rules)\n    step3_static.py                  Semgrep scan + file inventory\n    step3b_codegraph.py              Code graph + source\u002Fsink\u002Fsanitizer tags + memory analysis\n    step4_threat_model.py            Threat model + CVE catalog\n    step4b_path_enum.py              Exhaustive source-to-sink path enumeration\n    step4c_path_analyze.py           Per-path LLM exploitability validation\n    step4d_blindspot.py              File-by-file blind spot review (Project Black)\n    step6_chains.py                  Attack graph + transitive chain synthesis\n    step8_anomaly.py                 Prompt injection detection\n    step9_report.py                  Exhaustive report with PoCs\n  analysis\u002F\n    ast_parser.py                    Multi-language tree-sitter parser (+ regex fallback)\n    call_graph.py                    Call graph with import resolution\n    source_tag.py                    All untrusted entry points\n    sink_tag.py                      All dangerous operations\n    sanitizer_tag.py                 All sanitizers (with protected_against taxonomy)\n    intra_taint.py                   Intra-procedural taint tracking\n    inter_taint.py                   Inter-procedural taint propagation\n    path_enum.py                     Source-to-sink path enumeration + sanitizer taxonomy\n    path_analyze.py                  Per-path LLM analysis\n    attack_graph.py                  networkx-based transitive chain synthesis\n    scaling.py                       Large codebase support\n    semgrep_runner.py                External SAST integration\n    secrets_scanner.py               Entropy-filtered secrets detection\n    memory\u002F\n      orchestrator.py                Memory analysis coordinator\n      alloc_tracker.py               Allocation tracking\n      buffer_analyzer.py             Buffer overflow detection\n      lifetime.py                    Use-after-free, double-free\n      int_overflow.py                Integer overflow detection\n      format_string.py               Format string vulnerability (C\u002FC++ unsafe only)\n  knowledge\u002F\n    cve_db.py, downloader.py, importer.py, embeddings.py, epss.py, kev.py, sbom.py\n  llm\u002F\n    client.py, prompts.py, context.py, guard.py\ndata\u002F\n  cve\u002Fnvd.sqlite                     CVE database (364K+)\n  checkpoints\u002F                       Per-repo audit state\nconfig.yaml, requirements.txt\nstart_server.py, run_audit.py\n```\n\n---\n\n## Design Principles\n\n- Exhaustive coverage: every non-test source file reviewed, every source-to-sink path enumerated, nothing sampled\n- Deterministic foundation plus LLM reasoning: code graph built deterministically, LLM validates pre-traced paths\n- Short, focused prompts: per-path analysis with ~2K token prompts\n- Clean context per batch: no memory between batches\n- Sanitizer-aware taint tracking: cross-taxonomy mapping between sink categories and sanitizer `protected_against` values\n- Inter-procedural taint accumulation: tainted variables propagate across function boundaries, not overwritten\n- LLM-based validation: LLM checks sanitizer effectiveness, static tags are signals not blockers\n- Product-specific CVEs: CVSS version-tagged, targeted to actual tech stack\n- 5 parallel memory analyzers: allocation, buffer, lifetime, integer overflow, format string (with language-specific FP filtering)\n- Config-driven model: switch models by changing one line in config.yaml\n- Scales to enterprise codebases: single-pass file inventory, node-based AST reuse, adaptive config\n- Local only: no data leaves your machine, no API costs\n\n---\n\n## References\n\n- Project Black: Local AI for Penetration Testing (https:\u002F\u002Fprojectblack.io\u002Fblog\u002Flocal-ai-for-cyber-security\u002F)\n- RAPTOR: Autonomous Security Research Framework (https:\u002F\u002Fgithub.com\u002Fgadievron\u002Fraptor)\n- Qwen2.5-Coder-14B-Abliterated (https:\u002F\u002Fhuggingface.co\u002Fbartowski\u002FQwen2.5-Coder-14B-Instruct-abliterated-GGUF)\n- tree-sitter (https:\u002F\u002Ftree-sitter.github.io\u002F)\n\n---\n\n## License\n\nFor authorized security research only. Unauthorized use may violate computer fraud laws.\n","这是一个完全本地运行的源代码漏洞研究流水线，通过14B代码专用大模型对所有源文件进行穷举式白盒分析。核心功能包括：支持16种编程语言的语法解析、构建跨文件调用图、自动标记污点源与危险操作汇点、穷举所有源到汇路径并进行跨过程污点追踪、结合标准化分类体系匹配防护措施、利用LLM验证模糊路径的可利用性，并覆盖未被路径覆盖的盲区文件。适用于安全研究员在离线环境下对开源项目、企业级代码库（如Linux内核、VSCode）开展深度漏洞挖掘与攻击链合成。","2026-07-13 02:30:05","CREATED_QUERY"]