[SECURITY] Cross-Module - v3 Remediation Tracking #5184

Legacy Baseline Note (2026-05-31)

• Legacy issue title (pre-v3): [SECURITY] 65 modules ├ù 1,514 gaps (C:90 H:1150) ÔÇö CWE-200/327/532/676/798/1333
• Legacy counts in early scanner waves are historical snapshots and not the current canonical risk metric.
• Canonical baseline now follows the v3 pipeline and module-level governance docs.

Current Status

• Category: Security
• Current v3 total: 575
• Canonical source: ai_working/gap_scan_pipeline_v3_summary.json
• Scope: cross-module remediation and triage, not a single-module implementation slice

Scope Snapshot

Top Affected Modules

• server: 118 findings
• llm: 66 findings
• importers: 65 findings
• query: 60 findings
• cache: 57 findings
• storage: 44 findings
• prompt_engineering: 36 findings
• content: 15 findings

Abhakbare Remediation-Slices

• src/server/http_server.cpp (server, 371 findings) - L9888: audit_logging - Security function "authorize" without audit log; L9855: audit_logging - Security function "authorize" without audit log; L9854: audit_logging - Security function "authorize" without audit log
• src/server/query_api_handler.cpp (server, 239 findings) - L2839: performance - O(n²) pattern: linear search inside nested loop; L1266: determinism - Floating-point exact comparison (use tolerance/epsilon); L1265: determinism - Floating-point exact comparison (use tolerance/epsilon)
• src/llm/llama_wrapper.cpp (llm, 227 findings) - L3285: llm_ai_safety - Model loading without integrity verification (poisoning risk); L3225: llm_ai_safety - Model loading without integrity verification (poisoning risk); L3207: llm_ai_safety - User input in prompt without sanitization (injection risk)
• src/llm/lora_framework/kernels/vulkan_kernels.cpp (llm, 217 findings) - L1113: llm_ai_safety - User input in prompt without sanitization (injection risk); L1108: llm_ai_safety - User input in prompt without sanitization (injection risk); L1107: llm_ai_safety - User input in prompt without sanitization (injection risk)
• src/importers/postgres_importer.cpp (importers, 119 findings) - L2411: audit_logging - Hardcoded std::cout/printf instead of structured logging; L1436: performance - O(n²) pattern: linear search inside nested loop; L951: performance - O(n²) pattern: linear search inside nested loop
• src/importers/flatfile_importer.cpp (importers, 69 findings) - L1373: performance - vector::push_back in loop without prior reserve(); L1285: performance - vector::push_back in loop without prior reserve(); L1212: performance - vector::push_back in loop without prior reserve()
• src/query/query_engine.cpp (query, 226 findings) - L4699: determinism - Floating-point exact comparison (use tolerance/epsilon); L4540: performance - O(n²) pattern: linear search inside nested loop; L2540: determinism - Floating-point exact comparison (use tolerance/epsilon)
• src/query/aql_translator.cpp (query, 116 findings) - L541: legacy_duplication - Legacy/compatibility/deprecation marker detected (review removal/containment plan).; L1299: performance - vector::push_back in loop without prior reserve(); L1038: performance - vector::push_back in loop without prior reserve()

Phase 0: Pre-Start Validation & Planning

• Confirm this category is still present in the current v3 summary
• Confirm linked module issues exist for the top affected modules
• Confirm remediation ownership is clear when a finding spans multiple modules

Phase 1: Code Audit & Gap Discovery

• Validate top affected modules against the current per-module reports
• Spot-check representative file findings to separate true positives from noise
• Record recurring sub-patterns that should be fixed with one shared refactor

Phase 2: Implementation Planning

• Split work by module and shared pattern families
• Create a first remediation wave for the highest-density modules
• Record which modules will be fixed here vs. tracked in their own module issue

Phase 3: Code Implementation

• Remediate highest-risk file slices first
• Use one implementation slice per module/pattern cluster and check it off here
• Keep module issues and this cross-module issue synchronized when slices are moved or split

Phase 4: Automated Review & Testing

• Rebuild only the touched targets first, then widen if needed
• Run focused tests for each affected module
• Confirm the category count trends downward on the next v3 scan

Phase 5: Human Code Review & Sign-Off

• Review whether shared fixes introduced regressions in adjacent modules
• Review deferrals for noisy or low-confidence findings
• Confirm issue checkboxes still reflect actual remaining slices

Phase 6: Documentation & Governance Sync

• Update affected module docs when category-driven fixes changed module status
• Record scan delta and any notable false-positive triage in comments or docs

Phase 7: Merge & Close-Out

• Close only when the category backlog is either resolved or explicitly decomposed into active module issues
• Leave a closing summary with modules touched and delta from the previous scan

Production Readiness Checklist

• Top modules for Security have an active remediation path
• High-density files are split into checkable implementation slices
• Focused tests exist for touched modules
• v3 rescan shows a real reduction or a documented reclassification