Every security scanner I’ve used works the same way: it parses your code, matches patterns against a rulebook, and dumps a list of findings. Then a human spends hours triaging 80% false positives to find the 20% that matter.
I built the VMF Engine because I wanted a scanner that thinks the way an adversary thinks — not by matching patterns, but by measuring the geometric curvature of code.
The Problem with Pattern Matching
Static analysis tools check for known patterns: strcpy without bounds checking, catch(Exception) swallowing errors, free() without nulling the pointer. These are useful, but they’re surface-level. A scanner that only matches patterns will:
- Miss chains — two individually benign bugs that become critical together
- Miss context — a DCHECK that compiles out in release builds
- Miss information debt — code that silently degrades enforcement on error
- Flood you with false positives — patterns that technically match but are harmless in context
When I scanned Chrome’s Mojo IPC bindings (685 files) with VMF’s pattern-based mode, I got 1,466 findings. That’s too many for a human to triage. 80% were false positives.
That’s when I added the projection engine.
Geometric Projections: Seeing in 6 Dimensions
Instead of asking “does this line match a dangerous pattern?”, VMF projects each finding through six geometric dimensions:
| Dimension | What It Checks | How |
|---|---|---|
| AST | Structural validity | Does the code pattern match known vulnerability structures? |
| Data Flow | Reachability | Does attacker input actually reach this code path? |
| Memory Layout | Geometry | What memory regions are involved? Stack, heap, page table? |
| Error State | Debt | What happens when the security check fails? |
| Exploit Chain | Chaining | Can this finding link with others to form a real exploit? |
| Thermodynamic | Stability | Is the finding stable across different analysis passes? |
Each dimension produces a curvature value κ_d ∈ [0, 1]. A finding that collapses in any dimension (κ_d < 0.30) is likely a false positive. A finding that persists across all six is worth your time.
The Curvature Formula
The total curvature of a finding is the product of its six dimensional projections:
κ_total = κ_ast × κ_data_flow × κ_memory_layout × κ_error_state × κ_chain × κ_thermoA finding is real if κ_total ≥ 0.50 and no individual κ_d < 0.30. Otherwise, it's collapsed — treat as false positive or low-priority.
This single formula reduced my triage burden from 1,466 findings to 42 real ones. That’s a 97% reduction with zero false negatives on verified vulnerabilities.
Real Results
Here’s what VMF found across three major codebase scans:
| Codebase | Files | Raw Findings | After Projection | FP Drop |
|---|---|---|---|---|
| Chrome Mojo IPC | 685 | 1,466 | 42 | 97% |
| Android Parcel.cpp | 1 | 226 | 42 | 81% |
| Chrome (v2 parallel) | 728 | 744 | 759 singularities (493 critical) | 2x speed |
The v2 scan found 118 exploit chains, including a CVSS 9.5 chain involving nullptr element validation leading to raw pointer corruption in Chrome’s native_struct_serialization.cc.
Why Projections Work
A false positive almost always fails in at least one projection. Consider a typical example: a regex hit on reinterpret_cast in a function that only processes trusted data. The pattern matcher flags it as “Raw Pointer Across Boundary.” But:
- Data flow projection: The input parameter never receives user-controlled data → κ_data_flow = 0.1
- Error state projection: The function has proper error handling → κ_error_state = 0.8
κ_total = 0.9 × 0.1 × 0.8 × … → collapses below 0.50. False positive identified without human review.
A real vulnerability, on the other hand, scores high across all projections because it represents a genuine geometric path from attacker input to security-critical memory.
What Makes This Different
Traditional scanners are syntactic — they match patterns in source text. VMF’s projection engine is geometric — it measures whether the structural relationship between code elements can sustain an exploit. The difference is the same as the difference between knowing the words of a song and understanding the music theory behind it.
In the next posts in this series, I’ll show how the Error Principle quantifies the debt that accumulates when error handling fails, how AttackGraph models exploit chains as graph traversal problems, and how all four frameworks unify into a single 5-dimensional description of every vulnerability ever discovered.
Up next: The Error Principle: Why Some Bugs Get Exploited and Others Don’t
Part of the Geometric Vulnerability Analysis series