Vulnerability Research Tool Landscape --- Implementation Plan¶

For agentic workers: REQUIRED: Use superpowers:subagent-driven-development (if subagents available) or superpowers:executing-plans to implement this plan. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Populate all 28 skeleton documentation pages with substantive research content --- deep dives on major tools, practitioner guidance, and academic survey material.

Architecture: 4-phase execution. Phase 1 writes the methodology page (evaluation framework). Phase 2 dispatches 3 parallel agents for fuzzing tools, analysis tools, and emerging tech. Phase 3 dispatches 2 parallel agents for SWOT and gaps synthesis. Phase 4 writes overview pages, home page, and expanded glossary sequentially.

Tech Stack: MkDocs Material, Markdown, Mermaid diagrams, Vega-Lite charts, custom admonitions (opportunity, threat, pain-point, gap), pymdownx.snippets glossary auto-append.

Spec: docs/superpowers/specs/2026-03-14-research-plan-design.md

Content Standards Reference¶

Every page written in this plan MUST follow these rules:

• Frontmatter: Keep existing tags: from skeleton. Do not change the tag values.
• No emojis unless Material theme icons (:material-icon-name:)
• Em dashes: Use --- (renders as ---) not — directly
• Citations: Inline markdown links for key factual claims. If source unknown, use !!! warning "Knowledge Gap" admonition.
• Cross-references: Relative links between pages (e.g., [Coverage-Guided](../fuzzing-tools/coverage-guided.md))
• Glossary terms: Any new acronym must also be added to docs/glossary.md with both a table row and *[TERM]: Definition line. Coordinate with Phase 4 glossary task.
• Diagrams: Use ```mermaid fenced code blocks for flowcharts/architecture
• Custom admonitions: !!! opportunity, !!! threat, !!! pain-point, !!! gap --- use where semantically appropriate
• Standard admonitions: abstract (At a Glance), info, warning, tip, example, note

Page Template Reference¶

Tool Pages¶

---
tags:
  - <existing-tags>
---

# Page Title

!!! abstract "At a Glance"
    **Category:** <category>
    **Key Tools:** <tool1>, <tool2>, ...
    **Maturity:** <Mature | Growing | Emerging | Research>

## Overview

<what this category/approach is, why it matters, 200-400 words>

## Key Tools

### Tool Name

<description, architecture, 200-500 words per major tool>

**Strengths:**
- ...

**Weaknesses:**
- ...

**Use Cases:**
- ...

**Community & Maintenance:** <status>

### <repeat for each tool>

## Comparison Matrix

| Tool | License | Language | Maturity | Use Case | Learning Curve |
|------|---------|----------|----------|----------|----------------|
| ...  | ...     | ...      | ...      | ...      | ...            |

## When to Use What

<decision guide flowchart or prose, 200-400 words>

## Research Landscape

<academic papers, benchmarks, trends, 200-400 words>

## Related Pages

- [Link](../path/to/related.md) --- brief description

Analysis Pages (SWOT, Gaps)¶

---
tags:
  - <existing-tags>
---

# Page Title

!!! abstract "At a Glance"
    <2-3 sentence summary>

## <Main Analysis Section>

<structured findings with evidence, 1000-2000 words>

## Implications

<what this means for practitioners and tool builders, 300-500 words>

## Related Pages

- [Link](../path/to/related.md) --- brief description

Section Index Pages¶

---
tags:
  - <existing-tags>
---

# Section Title

<section overview, 200-400 words>

<optional: category taxonomy diagram (mermaid) or summary table>

| Page | Description |
|------|-----------|
| [Page Name](page.md) | Brief description |

Chunk 1: Phase 1 --- Foundation¶

Task 1: Write Methodology Page¶

Files: - Modify: docs/overview/methodology.md

• Step 1: Research evaluation frameworks

Web search for vulnerability tool evaluation criteria used in academic surveys (e.g., NIST SAMATE, IEEE S&P tool surveys, USENIX Security benchmarks). Note common dimensions used.

• Step 2: Write methodology page content

Replace the skeleton content in docs/overview/methodology.md with the full methodology page. Content must include:

1. At a Glance admonition --- research scope, approach summary
2. Research Approach --- how tools were identified, selected, and evaluated
3. Data Sources --- categories of sources (official docs, academic papers, benchmarks, community feedback, CVE databases)
4. Evaluation Framework --- the 7 scoring dimensions with definitions:
5. Maturity --- release history, stability, production readiness
6. Community Health --- contributors, issue response time, release cadence
7. Documentation Quality --- completeness, tutorials, API docs
8. Integration Ecosystem --- CI/CD support, IDE plugins, tool chaining
9. Target Domain Breadth --- languages, binary formats, protocols supported
10. Learning Curve --- time-to-first-result, prerequisite knowledge
11. Output Quality --- false positive/negative rates, actionability of findings
12. Tool Selection Criteria --- minimum thresholds for inclusion (e.g., active maintenance, public availability)
13. Scope & Limitations --- what's covered, what's excluded, known biases
14. Related Pages --- links to overview/landscape.md, overview/key-takeaways.md

Target: 1000--1500 words.

• Step 3: Verify build

Run: make lint Expected: Clean build, no errors or warnings.

• Step 4: Commit

git add docs/overview/methodology.md
git commit -m "docs: add methodology page with evaluation framework"

Chunk 2: Phase 2 --- Core Tool Research (3 Parallel Agents)¶

Phase 2 dispatches 3 independent agents. Each agent writes its assigned pages, runs make lint, and commits. Agents can run in parallel since they modify non-overlapping files.

Dependencies: Task 1 must be complete (methodology establishes evaluation framework).

Task 2: Write Fuzzing Tools Section (Agent A)¶

Files: - Modify: docs/fuzzing-tools/index.md - Modify: docs/fuzzing-tools/coverage-guided.md - Modify: docs/fuzzing-tools/hybrid-symbolic.md - Modify: docs/fuzzing-tools/grammar-aware.md - Modify: docs/fuzzing-tools/enterprise-platform.md

• Step 1: Research coverage-guided fuzzing tools

Research AFL, AFL++, libFuzzer, Honggfuzz, go-fuzz, cargo-fuzz. For each tool gather: architecture, key features, strengths/weaknesses, target use cases, community status, notable CVEs found. Search web for latest release info, benchmarks (e.g., Google FuzzBench results), and academic papers (e.g., AFL++ USENIX WOOT 2020).

• Step 2: Write docs/fuzzing-tools/coverage-guided.md

Deep dive page (2000--3000 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Coverage-Guided Fuzzing, Maturity=Mature - Overview of coverage-guided approach (instrumentation, feedback loop, corpus evolution) - Tool profiles: AFL++ (primary focus, 500+ words), libFuzzer (400+ words), Honggfuzz (300+ words), go-fuzz (200 words), cargo-fuzz (200 words) - Mermaid diagram showing the coverage-guided feedback loop - Comparison matrix (License, Language Support, Instrumentation, Distributed, Maturity) - When to Use What decision guide - Research Landscape (FuzzBench, key papers) - Cross-references to hybrid-symbolic.md, grammar-aware.md, ../emerging-tech/ai-ml-fuzzing.md

• Step 3: Research hybrid & symbolic execution tools

Research KLEE, S2E, SymCC, QSYM, Driller, Angr. Focus on: symbolic vs concolic distinction, constraint solving approaches, scalability limitations, integration with fuzzers.

• Step 4: Write docs/fuzzing-tools/hybrid-symbolic.md

Deep dive page (2000--3000 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Hybrid & Symbolic Fuzzing, Maturity=Growing - Overview explaining symbolic execution, concolic testing, hybrid approaches - Tool profiles: KLEE (400+ words), Angr (400+ words), S2E (300+ words), SymCC (300+ words), QSYM (200 words), Driller (200 words) - Mermaid diagram showing concolic execution flow - Comparison matrix - When to Use What --- when symbolic adds value over pure fuzzing - Research Landscape --- KLEE OSDI 2008, SymCC USENIX Security 2020 - Cross-references to coverage-guided.md, ../analysis-tools/hybrid-approaches.md

• Step 5: Research grammar-aware fuzzing tools

Research Nautilus, Domato, Fuzzilli, FormatFuzzer, Superion. Focus on: grammar specification formats, input structure awareness, target domains (browsers, file formats, protocols).

• Step 6: Write docs/fuzzing-tools/grammar-aware.md

Standard-to-deep page (1200--2500 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Grammar-Aware Fuzzing, Maturity=Growing - Overview explaining grammar-aware mutation, structure preservation, why random mutation fails on structured inputs - Tool profiles: Nautilus (400+ words), Fuzzilli (400+ words --- JavaScript engine focus), Domato (200 words), FormatFuzzer (200 words), Superion (200 words) - Example grammar snippet showing how input structure is defined - Comparison matrix - Cross-references to coverage-guided.md, ../gaps/stateful-fuzzing.md

• Step 7: Research enterprise fuzzing platforms

Research Synopsys Defensics, Code Intelligence (CI Fuzz), ForAllSecure Mayhem, ClusterFuzz/OSS-Fuzz, Fuzzbuzz. Focus on: commercial vs open-source, CI/CD integration, managed vs self-hosted, target industries, pricing models where public.

• Step 8: Write docs/fuzzing-tools/enterprise-platform.md

Deep dive page (2000--3000 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Enterprise Fuzzing Platforms, Maturity=Mature - Overview of enterprise fuzzing needs (scale, compliance, integration, reporting) - Tool profiles: OSS-Fuzz/ClusterFuzz (500+ words --- Google's infrastructure), Mayhem (400+ words), Code Intelligence (300+ words), Synopsys Defensics (300+ words), Fuzzbuzz (200 words) - Comparison matrix (Deployment, Pricing, CI/CD Integration, Language Support, Reporting) - When to Use What --- OSS project vs enterprise vs regulated industry - Cross-references to all other fuzzing pages

• Step 9: Write docs/fuzzing-tools/index.md

Section index page (500--800 words). Must include: - Overview paragraph explaining the fuzzing tools landscape - Mermaid diagram showing fuzzing category taxonomy (coverage-guided, symbolic, grammar-aware, enterprise) - Table linking to each sub-page with brief descriptions - Cross-references to ../analysis-tools/index.md, ../emerging-tech/index.md

• Step 10: Verify build

Run: make lint Expected: Clean build, no errors or warnings.

• Step 11: Commit

git add docs/fuzzing-tools/
git commit -m "docs: add fuzzing tools research — coverage-guided, hybrid-symbolic, grammar-aware, enterprise"

Task 3: Write Analysis Tools Section (Agent B)¶

Files: - Modify: docs/analysis-tools/index.md - Modify: docs/analysis-tools/static-analysis.md - Modify: docs/analysis-tools/dynamic-analysis.md - Modify: docs/analysis-tools/hybrid-approaches.md

• Step 1: Research static analysis tools

Research Coverity, Infer, Clang Static Analyzer, Semgrep, CodeQL, Checkmarx. For each: analysis technique (abstract interpretation, dataflow, pattern matching, query language), language support, false positive rates, integration capabilities, licensing.

• Step 2: Write docs/analysis-tools/static-analysis.md

Deep dive page (2000--3000 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Static Analysis, Maturity=Mature - Overview of static analysis approaches (AST-based, dataflow, abstract interpretation, query-based) - Tool profiles: CodeQL (500+ words --- query language, GitHub integration), Coverity (400+ words), Infer (400+ words --- Facebook's compositional analysis), Semgrep (300+ words), Clang Static Analyzer (300+ words), Checkmarx (200 words) - Mermaid diagram showing static analysis pipeline (source → parse → analyze → report) - Comparison matrix (Technique, Languages, CI/CD, License, False Positive Rate) - When to Use What --- SAST tool selection guide - Research Landscape --- Infer POPL papers, CodeQL academic origins (Semmle/QL) - Cross-references to dynamic-analysis.md, hybrid-approaches.md, ../fuzzing-tools/index.md

• Step 3: Research dynamic analysis tools

Research Valgrind (Memcheck, Helgrind, Callgrind), AddressSanitizer/MemorySanitizer/ThreadSanitizer/UndefinedBehaviorSanitizer, DynamoRIO, Intel Pin, Frida. Focus on: instrumentation approach (compile-time vs runtime), overhead, detection capabilities, platform support.

• Step 4: Write docs/analysis-tools/dynamic-analysis.md

Deep dive page (2000--3000 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Dynamic Analysis, Maturity=Mature - Overview of dynamic analysis (runtime instrumentation, sanitizers, binary instrumentation) - Tool profiles: Sanitizers family (500+ words --- ASan, MSan, TSan, UBSan as a group), Valgrind (400+ words), Frida (400+ words --- dynamic instrumentation for reverse engineering), DynamoRIO (200 words), Intel Pin (200 words) - Mermaid diagram showing compile-time vs runtime instrumentation approaches - Comparison matrix (Approach, Overhead, Detection Types, Platform, Integration) - When to Use What --- sanitizers for development vs Valgrind for debugging vs Frida for RE - Cross-references to static-analysis.md, hybrid-approaches.md, ../fuzzing-tools/coverage-guided.md

• Step 5: Research hybrid analysis approaches

Research Triton, IKOS, Frama-C, and combined static+dynamic strategies. Focus on: how approaches complement each other, practical workflows, academic foundations.

• Step 6: Write docs/analysis-tools/hybrid-approaches.md

Standard page (800--1200 words). Follow the Tool Pages template. Must include: - At a Glance: Category=Hybrid Analysis, Maturity=Growing - Overview of why combining static and dynamic analysis improves results - Tool profiles: Frama-C (300+ words --- formal methods), Triton (300+ words --- dynamic symbolic execution), IKOS (200 words --- abstract interpretation) - Discussion of practical hybrid workflows (static pre-filter → dynamic validation) - Cross-references to static-analysis.md, dynamic-analysis.md, ../fuzzing-tools/hybrid-symbolic.md

• Step 7: Write docs/analysis-tools/index.md

Section index page (500--800 words). Must include: - Overview paragraph explaining static vs dynamic vs hybrid taxonomy - Mermaid diagram showing analysis tool taxonomy - Table linking to each sub-page with brief descriptions - Cross-references to ../fuzzing-tools/index.md, ../emerging-tech/index.md

• Step 8: Verify build

Run: make lint Expected: Clean build, no errors or warnings.

• Step 9: Commit

git add docs/analysis-tools/
git commit -m "docs: add analysis tools research — static, dynamic, hybrid approaches"

Task 4: Write Emerging Tech Section (Agent C)¶

Files: - Modify: docs/emerging-tech/index.md - Modify: docs/emerging-tech/ai-ml-fuzzing.md - Modify: docs/emerging-tech/llm-bug-detection.md - Modify: docs/emerging-tech/cross-language.md - Modify: docs/emerging-tech/hardware-sidechannel.md

• Step 1: Research AI/ML-guided fuzzing

Research FuzzGPT, TitanFuzz, ChatAFL, reinforcement learning for fuzzing (e.g., NEUZZ, MTFuzz), neural program smoothing. Search for papers from 2023--2026 on ML-guided mutation strategies, seed scheduling, and coverage prediction.

• Step 2: Write docs/emerging-tech/ai-ml-fuzzing.md

Deep dive page (2000--3000 words). Follow the Tool Pages template adapted for emerging tech. Must include: - At a Glance: Category=AI/ML-Guided Fuzzing, Maturity=Emerging/Research - Overview of how ML enhances fuzzing (learned mutation strategies, coverage prediction, seed scheduling) - Approach profiles: Reinforcement learning (NEUZZ, MTFuzz --- 500+ words), LLM-guided (FuzzGPT, TitanFuzz --- 500+ words), ChatAFL (300+ words --- protocol fuzzing with LLMs), Neural program smoothing (200 words) - Mermaid diagram showing ML-in-the-loop fuzzing architecture - Comparison of approaches (table: Technique, Input Domain, Training Data, Overhead, Maturity) - Current limitations and open problems - Cross-references to ../fuzzing-tools/coverage-guided.md, llm-bug-detection.md, ../gaps/llm-integration.md

• Step 3: Research LLM-based bug detection

Research GPT-4/Claude for code review, vulnerability-specific fine-tuning (e.g., VulBERTa, LineVul), prompt engineering for security analysis, limitations vs traditional SAST. Search for benchmarks comparing LLM detection rates vs traditional tools.

• Step 4: Write docs/emerging-tech/llm-bug-detection.md

Deep dive page (2000--3000 words). Must include: - At a Glance: Category=LLM Bug Detection, Maturity=Emerging - Overview of how LLMs detect vulnerabilities (code understanding, pattern recognition, natural language reasoning) - Approach profiles: General-purpose LLMs for code review (500+ words --- GPT-4, Claude, capabilities and limitations), Fine-tuned models (400+ words --- VulBERTa, LineVul, CodeBERT), Prompt engineering for security (300+ words --- effective prompting strategies) - Honest assessment of limitations: hallucinations, false positives, context window limits, inability to execute code - Comparison with traditional SAST tools - Cross-references to ai-ml-fuzzing.md, ../analysis-tools/static-analysis.md, ../gaps/llm-integration.md

• Step 5: Research cross-language analysis tools

Research Joern, CodeQL multi-language support, LLVM-based IR analysis approaches, Weggli. Focus on: how tools handle language heterogeneity, IR-based approaches, practical limitations.

• Step 6: Write docs/emerging-tech/cross-language.md

Standard page (800--1200 words). Must include: - At a Glance: Category=Cross-Language Analysis, Maturity=Growing - Overview of the cross-language challenge (polyglot codebases, FFI boundaries, shared vulnerabilities) - Tool profiles: Joern (300+ words --- code property graphs), CodeQL multi-lang (300+ words), Weggli (200 words), LLVM IR approaches (200 words) - Cross-references to ../analysis-tools/static-analysis.md

• Step 7: Research hardware & side-channel analysis

Research Spectector, CacheD, timing analysis tools, EM-based fault injection detection. Focus on: Spectre/Meltdown-class detection, cache timing analysis, hardware-aware fuzzing.

• Step 8: Write docs/emerging-tech/hardware-sidechannel.md

Standard page (800--1200 words). Must include: - At a Glance: Category=Hardware & Side-Channel, Maturity=Research - Overview of side-channel vulnerabilities (timing, cache, power, EM) - Tool profiles: Spectector (300+ words --- speculative execution analysis), CacheD (200 words), timing analysis approaches (200 words), hardware-aware fuzzing (200 words) - Gap analysis: what tools are missing in this space - Cross-references to ../gaps/logic-bugs.md, ../analysis-tools/dynamic-analysis.md

• Step 9: Write docs/emerging-tech/index.md

Section index page (500--800 words). Must include: - Overview paragraph explaining the emerging tech landscape - Mermaid diagram showing maturity spectrum (Research → Emerging → Growing → Mature) with technologies placed on it - Table linking to each sub-page with brief descriptions - Cross-references to ../fuzzing-tools/index.md, ../analysis-tools/index.md

• Step 10: Verify build

Run: make lint Expected: Clean build, no errors or warnings.

• Step 11: Commit

git add docs/emerging-tech/
git commit -m "docs: add emerging tech research — AI/ML fuzzing, LLM detection, cross-language, hardware"

Chunk 3: Phase 3 --- Synthesis (2 Parallel Agents)¶

Dependencies: Tasks 2, 3, and 4 must be complete. Agents in this phase must read the completed tool pages from Phase 2 to ground their analysis in the actual research.

Task 5: Write SWOT Analysis Section (Agent E)¶

Files: - Modify: docs/swot/index.md - Modify: docs/swot/strengths.md - Modify: docs/swot/weaknesses.md - Modify: docs/swot/opportunities.md - Modify: docs/swot/threats.md

• Step 1: Read all completed tool pages from Phase 2

Read all files in docs/fuzzing-tools/, docs/analysis-tools/, and docs/emerging-tech/ to extract key findings that inform the SWOT analysis. Take notes on: what tools do well, where they fall short, emerging trends, competitive dynamics.

• Step 2: Write docs/swot/strengths.md

Analysis page (1500--2000 words). Follow the Analysis Pages template. Must include: - At a Glance summarizing top strengths - Structured analysis covering: - Mature fuzzing ecosystem (AFL++ lineage, 10+ years of development) - Strong open-source community (OSS-Fuzz, community-driven tools) - Sanitizer quality (ASan/MSan/TSan comprehensive and production-proven) - Diverse approaches (coverage-guided + symbolic + grammar-aware cover wide attack surface) - Vendor investment (Google, Microsoft, academic institutions funding research) - Growing AI/ML integration - Use !!! tip admonitions for practitioner takeaways - Evidence drawn from specific tools covered in Phase 2 - Cross-references to specific tool pages that demonstrate each strength

• Step 3: Write docs/swot/weaknesses.md

Analysis page (1500--2000 words). Must include: - At a Glance summarizing top weaknesses - Structured analysis covering: - Tool fragmentation (many tools, poor interoperability) - Steep learning curves (expert knowledge required for effective fuzzing) - Limited interop between static and dynamic tools - False positive burden (especially SAST tools) - Scaling challenges (symbolic execution path explosion, fuzzer throughput) - Gaps in stateful/protocol fuzzing - Reproducibility issues across environments - Use !!! pain-point admonitions for significant pain points - Cross-references to specific tool pages

• Step 4: Write docs/swot/opportunities.md

Analysis page (1500--2000 words). Must include: - At a Glance summarizing top opportunities - Structured analysis covering: - AI/ML integration potential (learned mutations, smart scheduling) - Cloud-native fuzzing-as-a-service - DevSecOps pipeline integration (shift-left) - Standardization efforts (common interfaces, result formats) - New vulnerability classes (supply chain, AI model vulnerabilities) - LLM-assisted harness generation and triage - Cross-language analysis for polyglot codebases - Use !!! opportunity admonitions for each major opportunity - Cross-references to emerging-tech/ pages and gaps/ pages

• Step 5: Write docs/swot/threats.md

Analysis page (1500--2000 words). Must include: - At a Glance summarizing top threats - Structured analysis covering: - Software complexity growth outpacing tool capabilities - AI-generated code introducing novel vulnerability patterns - Supply chain attacks exceeding current tool scope - Talent shortage in security research - Adversarial use of same tools/techniques - Open-source sustainability risks - Regulatory compliance burden without adequate tooling - Use !!! threat admonitions for critical threats - Cross-references to specific tool limitations from Phase 2

• Step 6: Write docs/swot/index.md

Section index page (500--800 words). Must include: - Overview explaining the SWOT framework and how it applies to the tool landscape - Mermaid quadrant or grid diagram showing SWOT categories - Table linking to each sub-page - Cross-references to ../overview/key-takeaways.md, ../gaps/index.md

• Step 7: Verify build

Run: make lint Expected: Clean build, no errors or warnings.

• Step 8: Commit

git add docs/swot/
git commit -m "docs: add SWOT analysis — strengths, weaknesses, opportunities, threats"

Task 6: Write Gaps & Opportunities Section (Agent F)¶

Files: - Modify: docs/gaps/index.md - Modify: docs/gaps/logic-bugs.md - Modify: docs/gaps/stateful-fuzzing.md - Modify: docs/gaps/llm-integration.md - Modify: docs/gaps/patch-generation.md

• Step 1: Read all completed tool pages from Phase 2

Read all files in docs/fuzzing-tools/, docs/analysis-tools/, and docs/emerging-tech/ to identify gaps in current tooling. Focus on: what problems remain unsolved, where tools explicitly fall short, what practitioners struggle with.

• Step 2: Write docs/gaps/logic-bugs.md

Analysis page (1500--2500 words). Follow the Analysis Pages template. Must include: - At a Glance summarizing the logic bug detection gap - Why logic bugs resist automation: - Require application-specific semantics (not generic patterns) - No universal specification to check against - Context-dependent correctness - Current approaches and their limitations: - Property-based testing (limitations at scale) - Formal verification (Frama-C, TLA+ --- labor-intensive) - Model checking (state explosion) - Specification inference (research stage) - What's missing: practical tools that bridge formal methods and developer workflow - Use !!! gap admonitions for key underserved areas - Cross-references to ../analysis-tools/static-analysis.md, ../analysis-tools/hybrid-approaches.md

• Step 3: Write docs/gaps/stateful-fuzzing.md

Analysis page (1500--2500 words). Must include: - At a Glance summarizing the stateful fuzzing gap - The stateful problem: - Network protocols with state machines - Multi-step API interactions - Authentication/session-dependent behavior - Resource lifecycle bugs (use-after-free across sessions) - Current approaches: AFLNet, StateAFL, SGFuzz, Boofuzz - Limitations: state space explosion, grammar + state combination, lack of protocol-specific tools - Opportunities: LLM-assisted state machine inference, hybrid approaches - Use !!! gap admonitions - Cross-references to ../fuzzing-tools/grammar-aware.md, ../fuzzing-tools/coverage-guided.md

• Step 4: Write docs/gaps/llm-integration.md

Analysis page (1500--2500 words). Must include: - At a Glance summarizing LLM integration opportunities - Where LLMs can augment existing tools: - Harness generation (automating the manual work of writing fuzz targets) - Seed corpus generation (structurally valid inputs from LLM knowledge) - Crash triage and root cause analysis - Vulnerability explanation and report generation - Fix suggestion (bridge detection → remediation) - Current state of integration (mostly research/prototype stage) - Challenges: reliability, hallucinations, cost, latency - Use !!! opportunity admonitions for promising directions - Cross-references to ../emerging-tech/ai-ml-fuzzing.md, ../emerging-tech/llm-bug-detection.md, patch-generation.md

• Step 5: Write docs/gaps/patch-generation.md

Analysis page (1500--2500 words). Must include: - At a Glance summarizing the detection-to-remediation gap - The gap between finding and fixing: - Current tools find bugs but rarely suggest fixes - Developer bottleneck in triage and remediation - Time-to-fix metrics and their impact - Current approaches: - GenProg, Angelix (search-based repair) - Facebook SapFix (production automated repair) - LLM-based fix generation (emerging) - Semantic patching (Coccinelle) - Limitations: correctness verification of generated patches, overfitting, regression risk - Use !!! gap admonitions for key missing capabilities - Cross-references to ../analysis-tools/static-analysis.md, llm-integration.md

• Step 6: Write docs/gaps/index.md

Section index page (500--800 words). Must include: - Overview of underserved areas in vulnerability research tooling - Summary table of gaps with severity/impact ratings - Table linking to each sub-page - Cross-references to ../swot/opportunities.md, ../swot/weaknesses.md

• Step 7: Verify build

Run: make lint Expected: Clean build, no errors or warnings.

• Step 8: Commit

git add docs/gaps/
git commit -m "docs: add gaps analysis — logic bugs, stateful fuzzing, LLM integration, patch generation"

Chunk 4: Phase 4 --- Overview, Home & Glossary¶

Dependencies: Tasks 2--6 must be complete. This phase synthesizes all prior research.

Task 7: Write Landscape Overview¶

Files: - Modify: docs/overview/landscape.md

• Step 1: Read all completed pages from Phases 2--3

Skim all tool pages, SWOT pages, and gaps pages to extract tool counts, categories, and key patterns for the landscape overview.

• Step 2: Write docs/overview/landscape.md

Overview page (1500--2000 words). Must include: - At a Glance admonition with landscape summary stats - Tool categorization matrix (table: Category × Maturity × Count) - Ecosystem overview --- how tool categories relate to each other - Mermaid diagram showing the vulnerability research tool ecosystem (inputs → tools → outputs) - Adoption trends --- what's growing, what's declining - Open-source vs commercial landscape - Cross-references to all section index pages

• Step 3: Verify build

Run: make lint Expected: Clean build.

• Step 4: Commit

git add docs/overview/landscape.md
git commit -m "docs: add tool landscape overview with categorization matrix"

Task 8: Write Market Map¶

Files: - Modify: docs/overview/market-map.md

• Step 1: Read all completed tool and analysis pages

Read all files in docs/fuzzing-tools/, docs/analysis-tools/, docs/emerging-tech/, docs/swot/, and docs/gaps/ to extract tool positioning, commercial vs OSS landscape, and competitive dynamics.

• Step 2: Write docs/overview/market-map.md

Overview page (1500--2000 words). Must include: - At a Glance admonition - Market segmentation: open-source vs commercial, point tool vs platform - Competitive positioning --- Mermaid quadrant or table showing tools positioned on axes (e.g., Ease of Use vs Detection Power, or Breadth vs Depth) - Key players by segment with brief profiles - Trends: consolidation, acquisitions, new entrants - Cross-references to all tool section pages

• Step 3: Verify build

Run: make lint Expected: Clean build.

• Step 4: Commit

git add docs/overview/market-map.md
git commit -m "docs: add market map with competitive positioning"

Task 9: Write Key Takeaways¶

Files: - Modify: docs/overview/key-takeaways.md

• Step 1: Read all completed pages

Read all content pages from Phases 2--3 to distill the top insights and practitioner recommendations.

• Step 2: Write docs/overview/key-takeaways.md

Overview page (1000--1500 words). Must include: - At a Glance admonition - 5--10 numbered key takeaways, each with: - Bold headline statement - 2--3 sentence explanation with evidence - Link to relevant detailed page - Practitioner recommendations section (which tools to start with, by use case) - Cross-references to all major sections

• Step 3: Verify build

Run: make lint Expected: Clean build.

• Step 4: Commit

git add docs/overview/key-takeaways.md
git commit -m "docs: add key takeaways with practitioner recommendations"

Task 10: Write Home Page Content¶

Files: - Modify: docs/index.md

• Step 1: Read all completed pages for stats and structure

Skim all section index pages to gather stats (tool count, category count, etc.) and understand the site structure for reading path recommendations.

• Step 2: Write docs/index.md

Home page content (500--800 words). This page uses template: home.html --- the hero section is in the template. The markdown content appears below the hero. Must include: - Keep existing frontmatter (template: home.html, tags) - Brief introduction paragraph (what this knowledge base covers) - "What You'll Find" section with cards or bullet list linking to each major section - "Who This Is For" section (security researchers, tool builders, vulnerability analysts) - "How to Use This Guide" section (suggested reading paths)

• Step 3: Verify build

Run: make lint Expected: Clean build.

• Step 4: Commit

git add docs/index.md
git commit -m "docs: add home page content with reading guides"

Task 11: Expand Glossary¶

Files: - Modify: docs/glossary.md

• Step 1: Collect all acronyms from completed pages

Search all docs/ files for acronyms and technical terms used across the site. Compile a master list of terms that need glossary entries.

• Step 2: Write expanded docs/glossary.md

Expand from 3 terms to 50+ terms. Must include both: 1. Table rows: | TERM | Full Name --- definition | 2. Abbreviation lines: *[TERM]: Full Name --- definition

Organize the table by category with subheadings:

Categories to cover: - Fuzzing Techniques: AFL, AFL++, ASan, MSan, TSan, UBSan, ASAN, concolic, symbolic execution, coverage-guided, grammar-aware - Analysis Methods: SAST, DAST, IAST, taint analysis, abstract interpretation, dataflow analysis, CFG, DFG, CPG - Tools & Platforms: KLEE, S2E, SymCC, Valgrind, Frida, CodeQL, Semgrep, OSS-Fuzz, ClusterFuzz - Vulnerability Classes: CVE, CWE, RCE, XSS, SQLi, SSRF, UAF, buffer overflow, integer overflow - Standards & Organizations: NIST, MITRE, OWASP, CVSS, NVD - AI/ML Terms: LLM, RL, neural program smoothing, fine-tuning - Hardware Security: side-channel, Spectre, Meltdown, cache timing

Keep existing 3 entries (AFL, ASan, CVE). Add new entries below them.

• Step 3: Verify build

Run: make lint Expected: Clean build. Also verify that abbreviation tooltips work by checking that *[TERM]: lines are properly formatted.

• Step 4: Commit

git add docs/glossary.md
git commit -m "docs: expand glossary to 50+ terms with abbreviation tooltips"

Execution Summary¶

Total tasks: 11 Total pages: 28 Estimated content: 18,000--25,000 words

Verification Checklist¶

After all phases complete:

• Run make lint --- full site builds with no warnings
• All 28 pages have substantive content (no "Content coming soon" remaining)
• Cross-references between pages resolve correctly
• Glossary abbreviation tooltips work site-wide
• Mermaid diagrams render correctly
• Custom admonitions (opportunity, threat, pain-point, gap) render with correct styling
• No broken external links

tags: - glossary

Glossary¶