Findings & Fixes

Severity and confidence

Every finding carries two independent signals:

• Severity — critical, high, medium, or low. How bad it is if exploited.
• Confidence — how sure the source is that this is a real, exploitable issue. Deterministic tool findings (Gitleaks, Semgrep, OSV-Scanner) are effectively always high-confidence; AI findings vary, and a low-confidence AI finding is labeled as such rather than presented with the same certainty as a confirmed leaked secret.

Each finding also includes evidence, the concrete attack scenario, and a recommendation — written to be actionable on its own, without needing to re-derive the reasoning from the code.

Status workflow

A finding is open, fixed, ignored, or false_positive. Fixed findings can be reopened. For findings from the deterministic tools (Gitleaks, Semgrep, OSV-Scanner), a false_positive/ignored status reliably survives re-scans of the same code — it won't reappear as a fresh "new" finding. For AI-sourced findings this is a strong mitigation, not an absolute guarantee: the model is told what's already been dismissed for that file and asked not to restate it, but it doesn't have a fixed rule catalog the way deterministic tools do, so it can occasionally re-derive the same issue under different wording. Genuinely different code at the same location is always evaluated fresh either way.

Exporting

From the Findings page, export the current filtered view as:

• Markdown — for pasting into a ticket or PR description.
• JSON — for feeding into your own tooling.
• SARIF — the standard static-analysis interchange format, for GitHub code scanning or any SARIF-consuming pipeline (validated against the official 2.1.0 schema).
• PDF — a formatted report suitable for handing to management or a client, grouped by repository, with full narrative detail (description, impact, evidence, remediation) for AI-sourced findings and compact tables for the rest. Rendered server-side, so it can take a few seconds longer than the other formats.

Pull/merge request comments

When a scan is triggered by a pull or merge request, a summary comment is posted directly on it — new findings introduced by the change, and any findings this change fixed. Pushing more commits to the same PR/MR updates that one comment in place rather than piling up duplicates.

AI-suggested fix PRs

Findings with a suggested patch show a Create fix PR (or MR, on GitLab) button. Clicking it:

1. Creates a dedicated branch (vuln-scanner-fix/<finding-id>).
2. Applies the AI-generated patch — validated to actually apply cleanly and touch only the finding's own file before anything is committed.
3. Opens a real pull/merge request against the repository's default branch, tagged as AI-generated and explicitly flagged for human review.

This is deliberately a manual, one-click action — never automatic. Writing a commit and opening a PR against your repository is consequential enough that a person decides when it happens, even though the patch itself came from the model. Nothing is ever merged automatically.

Re-triggering a fix for the same finding reuses the same branch (force-pushed), so retrying doesn't pile up duplicate PRs.