Security findings triage and reporting

Why this area matters

Alert fatigue is a security problem in its own right. When most findings are false positives, teams stop reading them, and the real issue sits in the backlog next to hundreds of non-issues. Raw scanner output also tends to leak: secret values pasted into tickets and PR comments, full reports shared more widely than the code they describe.

OpenRouting normalizes every scanner's output into one SARIF-based finding format with a fingerprint, so the same issue isn't reported twice across scans. A specialist review agent then gives each finding a verdict and confidence, a plain-English explanation and a suggested patch. Secret values are redacted before anything is sent to the model, and reports never include them.

What goes wrong in real applications

• Alert fatigue

  Untriaged findings bury real issues under noise, so the one that matters is ignored along with the rest.

• Secrets copied into reports

  Pasting raw scanner output into PR comments, chat or tickets spreads the secret it found to more people and systems.

• Findings without context

  A rule ID and a line number don't say why something is dangerous or how to fix it, which leads to wrong or superficial fixes.

• Duplicate and stale findings

  Without stable fingerprints, the same issue reappears every scan and fixed issues can't be told apart from new ones.

Sample: the risky pattern and the fix

import json

leaks = json.load(open("gitleaks.json"))
for leak in leaks:
    body = f"Leak in {leak['File']}:{leak['StartLine']} value={leak['Secret']}"
    post_pr_comment(pr_number, body)

import json

leaks = json.load(open("gitleaks.json"))
items = [f"{leak['RuleID']} in {leak['File']}:{leak['StartLine']}" for leak in leaks]
# Report rule and location only; secret values never leave the scanner output.
post_pr_comment(pr_number, title=f"{len(items)} possible secrets", items=items)

The original posts each secret's value into a PR comment, copying it to everyone who can read the PR and to notification emails. The fix reports the rule and location, which is enough to find and rotate the secret, and never repeats the value. OpenRouting's own PR comments and reports follow the same rule.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Every finding normalized to one schema: rule, scanner, severity, CWE, file, line range, snippet and fingerprint
• A verdict (true positive or likely false positive) with a confidence score, from the specialist agent the finding is routed to
• A plain-English explanation and a suggested patch for each finding
• Secret values redacted before any model call and kept out of reports and PR comments
• Full-repo scans produce a downloadable Markdown or PDF report; PR reviews post one summary comment for new findings

Scope and limits

• AI verdicts can be wrong. Each comes with a confidence score and reasoning, and you can set any finding to open, false positive, accepted risk or fixed.
• A report covers what the scanners surfaced and the agents reviewed in that scan. It is not a penetration test or a compliance attestation.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.