docs: define CodeQL scope for provider snapshots

Author: niakw

SECURITY.md

@@ -14,6 +14,8 @@ GitHub Actions use explicit least-privilege permissions and immutable full-lengt
 
 The provider worker is a defense-in-depth compatibility sandbox: it receives a reduced environment, blocks process spawning plus direct filesystem/network-capable Node modules, filters `process.getBuiltinModule` and legacy `process.binding` access, rejects static dangerous imports, and is launched by health checks under Node's Permission Model with read-only access limited to the worker scripts, dependencies and staged provider inputs. Provider network access must go through the guarded `fetch` surface so SSRF, redirect, host-count and response-size limits remain effective. This still does not claim perfect hostile-code isolation; OS/container isolation remains the stronger long-term boundary.
 
+CodeQL findings in repository-owned workflows, `scripts/`, `engine_v2/` and tests are treated as NiakVIO findings and must be resolved or explicitly justified. Files under `providers/` and `upstream-lkg/providers/` are generated or provenance-preserving snapshots of untrusted provider code; LKG snapshots are intentionally immutable and published bundles are regenerated through the provider pipeline rather than hand-edited. Static findings limited to those snapshot trees may therefore be dismissed as vendored/generated-code findings after verifying that no repository-owned path is involved. Such a dismissal does not mark the provider as trusted: sandboxing, network guards, identity checks and media validation remain the runtime security boundary.
+
 The dependency gate installs the committed lockfile with lifecycle scripts disabled, checks high-severity advisories for the non-optional production tree, and runs the deterministic repository suite. Published upstream bundles that still import `cheerio-without-node-native` are kept compatible through an npm alias to the audited `cheerio@1.2.0` implementation; the obsolete `0.20.2` dependency tree is no longer installed.
 
 For a potentially sensitive vulnerability, avoid publishing exploit details in a normal public issue. Prefer GitHub private vulnerability reporting when available for the repository, or contact the repository owner privately.