| 1 | # NOVELTY-DOCTRINE - How v2 Avoids Being Beaten to the Punch |
| 2 | |
| 3 | v1's deepest failure was not low severity - it was **non-novelty**. Every "find" was a *sibling-CVE*: |
| 4 | a variant of an already-public bug, discovered by pattern-matching the shape of known CVEs onto new |
| 5 | code. By construction, that approach can only ever rediscover known bug *classes* in known *places*. |
| 6 | This document is the discipline that makes v2 find **new** bugs. |
| 7 | |
| 8 | Related: [[../00-doctrine/OPERATING-CORE]] · [[../00-doctrine/SEVERITY-GATE]] · [[../04-cleared-axes/README|cleared-axes log]] |
| 9 | |
| 10 | --- |
| 11 | |
| 12 | ## The three levers of novelty |
| 13 | |
| 14 | ### Lever 1 - Hunt freshly-released code (the time-arbitrage) |
| 15 | |
| 16 | Public researchers, OSS-Fuzz, and CodeQL's default queries have already swept yesterday's code. The |
| 17 | edge is **code that is days old**: a feature merged last week, a new format extension, a fresh release, |
| 18 | a brand-new project from the AI gold-rush. New code is **unfuzzed, unaudited, and un-CVE'd**. |
| 19 | |
| 20 | Concrete sourcing: |
| 21 | - Watch the **commit/PR/release feed** of in-scope/owned projects. Target diffs that touch a |
| 22 | [[../00-doctrine/SEVERITY-GATE|gate]]-relevant sink: a new parser path, a new `ipcMain` handler, a |
| 23 | new tool, a new `run:` step, a new deserialization route. |
| 24 | - Prefer projects in their **first year** - the [[../01-archetypes/ai-agent-mcp|AI-agent]] and |
| 25 | [[../01-archetypes/ml-model-loaders|model-loader]] ecosystems are months old; their defenses are |
| 26 | immature and their parsers unfuzzed. |
| 27 | - **Re-run existing fuzz harnesses on the new commit.** OSS-Fuzz fuzzed the *old* tree. A new format |
| 28 | feature is new attack surface the corpus has never reached - point a coverage-guided fuzzer at it. |
| 29 | - Diff-driven: when a project lands a "safe mode" / allowlist / sandbox (e.g. PyTorch `weights_only`, |
| 30 | the HF chat-template sandbox, a new SSRF allowlist), that *defense* is the newest, least-tested code |
| 31 | in the repo. Hunt the bypass of the fresh defense. |
| 32 | |
| 33 | ### Lever 2 - Use the CPG to find UNEXPLORED source→sink paths |
| 34 | |
| 35 | This is the mechanical heart of v2 and the direct antidote to pattern-matching. Instead of asking |
| 36 | *"does this code look like CVE-X?"* (which only finds siblings), ask the **Code Property Graph**: |
| 37 | *"what attacker-reachable sources flow to a dangerous sink - by any path, including ones nobody named?"* |
| 38 | |
| 39 | Method (Joern / `joern_query`, plus `codeql_query`, `semgrep_scan` as cheaper pre-filters): |
| 40 | 1. **Define sinks from the gate, not from CVEs.** Enumerate the dangerous sinks for the archetype |
| 41 | (e.g. `child_process.exec`, `pickle.find_class`, `memcpy`, `gguf` size-math, `ipcMain` OS calls, |
| 42 | `${{ github.event }}`→`run:`). These come from the [[../01-archetypes/electron-desktop|archetype]] |
| 43 | boundary maps, not from a CVE list. |
| 44 | 2. **Define sources as trust-boundary inputs.** The crossings in the archetype boundary map (the model |
| 45 | file, the IPC arg, the PR title, the fetched URL, the tool arg). |
| 46 | 3. **Query for reachability between them** - `cpg.method(src).reachableBy(...)` / taint flows. The CPG |
| 47 | surfaces *every* path, including the long, weird, multi-hop ones a human (and a pattern-matcher) |
| 48 | would never enumerate. **Those long unexplored paths are where novelty lives** - the obvious |
| 49 | one-hop path is the one already CVE'd. |
| 50 | 4. **Rank by "has anyone looked here?"** Prefer paths through recently-added code (Lever 1), through |
| 51 | error/edge handlers, through a second format/port, through a defense's bypass. Deprioritize the |
| 52 | textbook path. |
| 53 | 5. **Confirm the guard is actually absent/bypassable** on the chosen path - then it's |
| 54 | SOURCE_CONFIRMED and goes to the oracle. The CPG finds the path; only the |
| 55 | [[../00-doctrine/OPERATING-CORE#2-the-only-proof-is-an-execution-artifact|dynamic oracle]] confirms |
| 56 | the bug. |
| 57 | |
| 58 | The mental shift: v1 used the LLM as the *detector* (pattern-match → "this is a bug"). v2 uses the |
| 59 | **CPG as the detector** (dataflow → "this path is reachable") and the **oracle as the judge** (artifact |
| 60 | → "this path is exploitable"). The LLM only *generates hypotheses and writes harnesses*. It never |
| 61 | declares a bug, and it never declares novelty. |
| 62 | |
| 63 | ### Lever 3 - Bug-class transplant onto an unhunted surface |
| 64 | |
| 65 | A *known bug class* in a *place no one has applied it* is novel. Take a mature class (integer-overflow |
| 66 | heap overflow, pickle `__reduce__`, SSRF→IMDS, workflow-injection) and apply it to a surface the class |
| 67 | hasn't been pointed at yet - e.g. the GGUF metadata parser, a new MCP server, a freshly-ported |
| 68 | safetensors reader, a brand-new agent's code tool. The *class* is old; the *instance and location* are |
| 69 | new. This is legitimately novel and is distinct from finding a variant of a specific public CVE in the |
| 70 | same project (that's a sibling). |
| 71 | |
| 72 | --- |
| 73 | |
| 74 | ## The sibling-CVE gate: novel vs. variant (run BEFORE deep work) |
| 75 | |
| 76 | Before investing oracle time in a SOURCE_CONFIRMED candidate, **check it against the CVE/advisory feed**. |
| 77 | This is cheap and saves you from weaponizing a known bug. |
| 78 | |
| 79 | Procedure: |
| 80 | 1. **Query the feed** for the project + the bug class + the sink (`cve_lookup`, `search_cves`, |
| 81 | `cve_semantic_search`, `variant_search_cve`, `advisory_search`). Also check GitHub Security |
| 82 | Advisories, the project's own changelog/security page, and recent commit messages ("fix overflow", |
| 83 | "security", "sanitize"). |
| 84 | 2. **Classify the candidate:** |
| 85 | |
| 86 | | | Already-public bug | Same class, **new** location/instance | |
| 87 | |---|---|---| |
| 88 | | Same project, same file/function, same root cause as a known CVE | **SIBLING - do not report.** | - | |
| 89 | | Same class but a *different* field/route/file, or a different project, or a re-implementation/port | - | **NOVEL - proceed.** | |
| 90 | | The bug is in *new code* (post-dates the latest relevant CVE) | - | **NOVEL - proceed.** | |
| 91 | |
| 92 | 3. **Document the novelty delta.** Every candidate that proceeds carries a one-paragraph "why this is |
| 93 | new": which CVE(s) it is adjacent to, and the specific reason this instance is *not* covered by them |
| 94 | (different sink field, unfuzzed new code, a port that dropped the fix, a bypass of the patch that |
| 95 | "fixed" the sibling). If you cannot articulate the delta, it is a sibling - stop. |
| 96 | 4. **Patch-bypass is novel.** If a project "fixed" a CVE but the fix is incomplete (the classic |
| 97 | incomplete-patch), demonstrating the bypass *is* a novel finding - document it as a bypass of the |
| 98 | specific fix commit. |
| 99 | |
| 100 | > The novelty check is a **pre-filter, run before the oracle**, not an after-the-fact justification. |
| 101 | > v1 weaponized first and rationalized novelty later. v2 proves novelty is plausible *before* spending |
| 102 | > the expensive oracle budget, then proves exploitability with the artifact. |
| 103 | |
| 104 | --- |
| 105 | |
| 106 | ## Anti-drift tie-in |
| 107 | |
| 108 | Novelty and anti-drift reinforce each other. The |
| 109 | [[../04-cleared-axes/README|cleared-axes log]] records every (target, archetype, axis) already |
| 110 | screened - so the agent never re-hunts ground it (or the public) has already cleared. Combined with the |
| 111 | [[../00-doctrine/OPERATING-CORE#4-the-anti-drift-rule-log-cleared-axes-rotate-archetypes|archetype-rotation rule]], |
| 112 | this forces the search toward *fresh* code and *unexplored* paths every iteration, which is exactly |
| 113 | where novel high-severity bugs are. |