Ask one question and VoidAccess searches 12+ Tor search engines, GitHub and security feeds in parallel, then returns actors, wallets, leaked credentials and IOCs ready for STIX, MISP or Sigma. Open so
Air-gapped security assessment, from source code to the finished report
CPG-based taint analysis · LLM triage · audit deliverables generated for you — a desktop tool that never phones home
CPGuard = CPG (Code Property Graph) + Guard — it guards your code with a property graph, not a pattern list. That graph is why the logo is three connected nodes.
CPGuard = CPG (Code Property Graph) + Guard — it guards your code with a property graph, not a pattern list. That graph is why the logo is three connected nodes.
Pattern-matching scanners drown you in false positives. CPGuard goes deeper —
tree-sitter parsing → language-neutral IR → CPG (AST · CFG · def-use · call) → interprocedural taint with function summaries → LLM triage —
then hands the result to a three-pane review screen where a human confirms the verdict.
Data-flow visualization — the Source→Sink step graph stays in sync with the code viewer.
AI analysis panel — asks about the selected issue with its rule, flow and surrounding code attached automatically.
Verdicts (confirmed / false positive / fixed / deferred) with auditor notes, rows tinted by verdict, an audit-state filter, and new/resolved comparison between scans.
A verdict moves the numbers immediately — marking a finding a false positive, deferred or fixed drops the open count and the severity badges on the spot. The detection total stays: it is what the scan found, and a person's verdict does not change that.
A rescan inherits the previous verdicts — same fingerprint (rule, file, normalised sink code), same audit state and note. The second and third round of an assessment no longer re-judge what was already cleared.
Judge the whole filtered list at once — findings arrive in clusters of the same sink, and nobody clicks through them one at a time.
Filter by what is inside the flow — match calls and variables along the traced path (whole flow / source / sink, contains or not, regex allowed). Narrow to flows that went through sanitize, then clear them in one action.
Uncertain flows are marked — a flow that passed through a function whose code is not in the analysed set is flagged and filterable, which is the pile to review first.
Similar-issue grouping (same rule, same sink), verdict history (from what, to what, when), and save-and-next.
Running an assessment
Cancel a scan or a batch — a run started by mistake stops instead of being waited out.
Get back to a running scan — a sticky bar links to it from any screen.
Delete scans in bulk — a bad batch leaves hundreds of rows behind.
Per-project exclusions — path globs, rules and the stated reason are saved and applied to the next scan, and excluded files are never parsed. What was applied is stored on the scan, so the report reflects the run that produced it.
Scale: one analyst, hundreds of projects
Batch upload — select many zips at once, or upload a single zip containing project zips; each becomes its own project.
Batch progress — a FIFO worker scans projects sequentially with per-project status.
Project portfolio (/projects/) — every project's latest scan in one searchable, sortable, filterable table.
Bulk deliverables — select projects and download one ZIP with each project's PDF report and xlsx sheet, ready to hand to developers.
Assess against the standard your client asks for
Tick the references before the scan starts: MOIS Secure Coding Guide (Korea's public-sector standard) · Electronic Financial Supervision Regulation web checklist (Korean finance) · Mobile secure coding checklist (draft) · OWASP Top 10 (2021) · CWE. Pick several — real Korean deliverables report against more than one at a time.
The mapping key is CWE, so the scan runs once and the standards only shape the report — switching or adding references never means rescanning.
Filter the review screen by check item, group the issue list by it, and tick which standards each export carries. The report's check items section becomes those standards' full checklists with a verdict per item, and the xlsx gains a check items sheet. Items are identified by category and weakness name, the way real assessment deliverables are written — never by an item number, which differs between editions of the guide. Items that were assessed and came back clean stay in the table — that is the evidence of what was checked.
A check item with no rule behind it is never reported as "pass." Items outside static analysis — directory indexing, admin page exposure, CSRF — are marked Not assessed, so the deliverable never claims a check that did not happen.
Findings outside the chosen standard's mapping are reported separately, never silently dropped.
Deliverables you can actually hand over
Consolidated assessment report — tick the projects on the Reports screen and get one submission-ready document covering all of them: purpose and legal basis, schedule, tool, assessor, the standards' check items, initial findings → false-positive review → final items to remediate, per-project detail (files, lines of code, languages, weaknesses by severity), remediation by type, and appendices. Structured like the reports Korean assessment firms actually deliver.
Report templates — name a template and it decides which sections ship (detail, source and flow, reviewer comment, exclusions, applied rules, scope by language) plus the cover title, header note and logo. Client requirements differ and templates pile up per contract.
Exclusions, applied rules and scope appendices — what was excluded and why, every rule applied including the ones with no findings, and files/lines/findings/density per language. On a checklist-shaped deliverable "we checked and found nothing" carries as much weight as a finding.
The review verdicts become the report. Marking a finding as a false positive or excluding it on the review screen — with the note explaining why — is what turns a raw scanner dump into a deliverable. Section 3.2 is built from exactly those verdicts, and the initial/final totals differ accordingly.
Word (.docx) and PDF. The Word file is the editable master, so the analyst can drop it into the client's template, add on-site opinions, and ship it. Same sections, same tables, same wording as the PDF.
Analysis sheet (xlsx) — the fixed 14-column format Korean clients expect, plus a check items sheet.
Everything is black text on light grey. Assessment reports travel as black-and-white printouts and photocopies and get pasted into the client's own template, so nothing is distinguished by colour alone — severity is graded by lightness, verdicts read as words.
LLM triage
Claude · ChatGPT (OpenAI) · Gemini. Re-verifies findings for reachability and explains them; provider and model are selectable. Gemini's free tier is enough to try it.
Deliverables
Assessment report (PDF) — cover, revision history, table of contents, scope and methodology, severity chart, checklist, per-finding cards (target · description · data-flow steps · impact · remediation · safe example · CWE reference), overall assessment, severity-rating appendix, and an assessment-history table across runs.
It also runs portable — copy the dist/CPGuard folder and run CPGuard.exe.
From source — Windows · macOS · Linux
pip install .
cpguard --help
The engine, the web UI and every report format are pure Python and run on all three platforms.
Only the packaged installer and the native desktop window (WebView2) are Windows-specific.
Korean text in PDF reports needs a Korean font: Windows and macOS have one out of the box, on
Linux install fonts-nanum, or point CPGUARD_PDF_FONT at any TrueType font you prefer.
🚀 Usage
# CLI scan (SARIF + analysis sheet)
cpguard scan ./project --sarif out.sarif --xlsx out.xlsx
# Assess against one or more standards (mois | efs | owasp | cwe)
cpguard scan ./project --standard mois --standard efs --xlsx out.xlsx
# Re-verify with LLM triage
cpguard scan ./project --triage --provider gemini
# Web dashboard (browser)
cpguard serve
# Native desktop window
cpguard app
In the dashboard: upload zip(s) → progress screen (step checklist + runtime log) → review and mark verdicts →
add an LLM key in ⚙️ Settings to enable AI analysis and triage.
🔁 CI/CD (GitHub Actions)
Scan on every push and PR, upload SARIF to GitHub Code Scanning so new findings appear inline on the code and the PR. A severity gate can fail the build.
# .github/workflows/cpguard.yml
permissions:
contents: read
security-events: write
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- id: cpguard
uses: KimJeju/[email protected]
with:
path: '.'
fail-on: 'high' # fail the build on high or above (none = no gate)
- if: always()
uses: github/codeql-action/upload-sarif@v3
with: { sarif_file: '${{ steps.cpguard.outputs.sarif }}' }
The CLI gates too: cpguard scan . --sarif out.sarif --fail-on high (exit code 1 at or above that severity).
This repository's .github/workflows/cpguard.yml is a working example.
🤖 MCP server — AI agents drive it (SAST → dynamic validation)
An AI coding agent (Claude Code, Cursor) can drive CPGuard over MCP: scan, pull the
source-to-sink evidence, explain a rule, and dynamically validate a finding —
answering the question a static scanner never can, "is this actually exploitable?"
CPGuard does not fire HTTP. Because it knows the sink, it emits a probe plus an
oracle — what to send and, more importantly, what to observe that proves the sink
fired. The agent fires it with its own tools and hands back what it saw; CPGuard
matches that against the oracle and returns a verdict. It is oracle-match, not IAST —
no instrumentation, so it reports "the predicted signal appeared", not "I observed the
real execution path". NOT_REPRODUCED is kept distinct from FALSE_POSITIVE.
Nine tools: scan_file · scan_start / scan_status (async whole-repo audit) ·
finding.list · finding.evidence · explain · probe.get · validation.submit ·
verify (did your fix actually close the flow?). The core opens no socket; only the
agent's own web tools touch the network.
pip install "cpguard[mcp]"
claude mcp add cpguard -s user "<env>/bin/cpguard-mcp" # see docs/mcp-server-design.md
Measured against labelled ground truth in eight languages — five corpora totalling 138,785 cases, of which 76,866 are scored (the rest are categories excluded below). Score = recall − false-positive rate (the official OWASP metric; random guessing = 0.000).
Corpus
Language
Scored
Recall
Precision
Score
OWASP Benchmark v1.2
Java
1,572
95.8%
88.7%
0.826
C# Vulnerability Test Suite
C#
33,024
84.3%
91.1%
0.728
OWASP Benchmark for Python
Python
346
82.1%
83.3%
0.717
BenchProctor (httplib / standalone)
C++
800
~79%
100%
0.79
BenchProctor (gin / net_http)
Go
2,000
~80%
~85%
0.66
BenchProctor (standalone)
C
500
52.0%
100%
0.520
BenchProctor (express / koa)
JavaScript
2,200
~66%
~78%
0.47
BenchProctor (express_ts / nestjs)
TypeScript
2,200
~62%
~79%
0.45
BenchProctor (rails / sinatra)
Ruby
2,400
~56%
~81%
0.43
PHP Vulnerability test suite
PHP
31,824
47.0%
66.4%
0.369
Read it plainly: Java, C++, Python, C# and Go are at working-tool quality; C, JS/TS and Ruby are usable; PHP is not there yet. Where the score is low it is usually recall, not noise (PHP recall is 47.0%).
Values read out of a database or a file count as user input by default — that is where second-order injection and stored XSS come from. Pass --trust-stored-data to turn it off. The default was chosen by measurement, not taste: across 15 suites, treating stored data as a source cost nothing anywhere and bought Go 50 extra true positives for 9 extra false ones.
Do not take the 100% precision on C/C++ at face value. Those corpora are small (400-500 cases each) and their safe variants are generated from exactly two guard idioms (check(x) ? x : default, and "replace with a default when the check fails"). Teaching the engine to read those two took the false positives to zero in one step — that measures how completely the generator's rules were matched, not how varied real C code is. The 52-80% recall is the more honest signal. Kotlin and Swift have no public labelled corpus at all, so they are covered by idiom tests instead (see below).
Config-only categories (weakrand, crypto, hash, securecookie, trustbound) are not data-flow problems and are excluded rather than counted as free wins. Categories that are data-flow problems but that CPGuard has no rule for (NoSQL injection, SSTI, prototype pollution, XXE …) are reported separately from those, so coverage is not quietly inflated.
The benchmarks drove real engine work. Java started at 0.137 and PHP at 0.001; every point since came from a defect the numbers exposed — taint dying inside try blocks, for-each variables losing the collection's taint, no path sensitivity at all, container mutations not propagating, comparison results carrying taint, constructor-to-field-to-method flows missing in every language, by-reference output parameters (fgets(buf, …), Decode(&v)) invisible to a return-value-only model, closures running against an empty environment so anything they captured looked clean, and — most recently — validation applied to a projection of the tainted value (if !allowed[url.Parse(x).Hostname()] { reject }) leaving the original tainted, which was 59% of all Go false positives. Each fix is a general analysis technique, not a tweak aimed at the test cases. The full before/after ledger is in bench/README.md.
Where labelled data does not exist (Kotlin, Swift, and any framework a corpus does not cover), CPGuard ships idiom tests instead: 130 minimal reproductions of shapes that are common in real code, run as part of the test suite. They catch a different class of defect than the benchmarks do — TypeScript parameters were carrying their type annotation into the parameter name, which silently removed every typed function from interprocedural analysis, and no benchmark score moved when it was fixed.
A second measurement on a real application (DVWA, PHP) is also published. Full methodology, per-category tables and limitations: bench/README.md.
📈 Large codebases
Strategies for extreme scale (20–30 GB of source, 50k+ findings) — sink pre-filtering, incremental and summary caches, the finding DB table, aggregation with virtual scrolling, triage clustering — are in docs/large-scale.md.
CPGuard is developed in the open by one person. If it is useful to you, you can support
its continued development on Fairy @cp-guard.
📄 License
Apache License 2.0. Free to use, modify and redistribute, commercially included, provided the notice and license are preserved. Includes an express patent grant.
Bundled third-party font: NanumGothic (c) NHN Corporation, under the SIL Open Font License 1.1. It ships with the package so Korean reports render on servers without Korean fonts installed.
