DuckDB — CWE-407 Analysis
==========================

**Status: CLEAN — 0 confirmed defects**

DuckDB's query optimizer, planner, and execution engine were scanned. 80+ candidates
were returned; all are effectively false positives.

Container assessment:

- **All ``.find()`` calls on maps/sets** — DuckDB uses ``unordered_map`` and
  ``unordered_set`` throughout the optimizer. ``.find()`` on these is O(1) amortized.
  The 75+ candidates in this category are all false positives.

- **4 ``std::find`` on ``vector<ColumnBinding>``** — real O(n) linear scans:

  - ``build_probe_side_optimizer.cpp:94`` — ``ComputeOverlappingBindings`` counting
    column binding overlaps. O(|needles| × |haystack|).
  - ``deliminator.cpp:441`` — join group binding check. O(|groups| × |join_bindings|).
  - ``has_correlated_expressions.cpp:57`` — correlated column scan. O(|correlated|²).
  - ``topn_window_elimination.cpp:624`` — window child binding lookup.

  All four cases operate on **column binding vectors** — bounded by query width, not
  by data size. Realistic inputs are < 20 columns. O(20²) = 400 operations — not a
  defect worth classifying as CWE-407. No tickets created.

DuckDB's optimizer was written with explicit performance awareness and uses
``unordered_map``/``unordered_set`` as the default collection type for all graph
and plan state tracking.

* Scanner: ``tools/scans/duckdb.sh``
* Scan result: ``tools/scan-results/duckdb.txt`` — 80+ candidates, all clean or bounded
