Optional bounded OpenGrep analysis-provider evidence in the graph

[kerberosmansour]

Problem

Graphify can explain code structure, but external static-analysis findings remain flat reports. An engineer or coding agent cannot traverse from a source file or symbol to the applicable finding, rule, severity, and source range inside the same auditable graph.

Static-analysis output must not be treated as semantic/compiler truth, and scanner execution must not weaken Graphify's local, non-mutating security model.

Proposed direction

Add an optional OpenGrep analysis-provider adapter that is deliberately separate from the LSP semantic-provider proposal in #2948:

• provider kind is analysis, never semantic;
• accept OpenGrep JSON (with SARIF as a follow-up/compatible interchange format);
• normalize bounded finding nodes and has_finding edges with rule ID, severity, CWE/OWASP metadata, provider version, run ID, timestamp, source range, and deterministic finding ID;
• retain no matched source snippet in the provider artifact;
• reject finding paths that resolve outside the selected workspace;
• merge additively into a separate graph output by default;
• report analysis providers separately in graph metadata.

Safe execution boundary

The adapter should accept only local, operator-reviewed rule files inside the workspace and invoke OpenGrep with an argv list and shell=False. It must not enable:

• autofix;
• local project builds;
• remote/automatic registry rules;
• untrusted validators;
• version-check/telemetry calls;
• source mutation.

Timeout, output size, target size, job count, and finding count are explicit budgets. Exceeding a budget produces a visible budget_exhausted result rather than silently widening or discarding evidence.

Why this fits Graphify

The output is still a source-grounded, explainable graph: a finding is linked to the file that produced it and carries the evidence needed to audit that relationship. It complements native AST extraction and optional compiler/LSP evidence without replacing either.

Keeping analysis distinct also prevents a subtle failure mode: a scanner match is evidence that a rule fired, not proof that a vulnerability is exploitable or that a compiler-resolved relationship exists.

Suggested PR boundary

1. Bounded OpenGrep JSON runner/normalizer.
2. Distinct analysis-provider metadata and additive merge behavior.
3. Unit/security tests plus a real local OpenGrep fixture smoke test.
4. Documentation of the trust boundary and intentionally disabled flags.

No bundled scanner, automatic install, default scan, remote rules, source snippets, or remediation/autofix in the first change.

I have a working local prototype and will keep this as a separate PR from #2948 so each evidence kind can be reviewed on its own semantics.

[kerberosmansour]

The compiler/LSP evidence foundation is now proposed in #2951. OpenGrep is intentionally not included there: scanner findings need the distinct analysis-provider semantics and execution constraints described in this issue. A bounded local prototype has been exercised successfully, but keeping its follow-up separate avoids conflating compiler evidence with security findings or complicating review of #2951.