Docs/Platform

Scanner orchestrator

v1 roadmap

On the v1 roadmap, not in the POC you install today. FlowRail does not run scanners. It decides what to scan, which rules apply, and how to interpret the findings. Customer-side scanners stay where they are. The intelligence layer above them is the value.

01

Why this exists

Modern repos run a dozen scanners. Each emits hundreds of findings. Most are false positives, irrelevant to the change in flight, or duplicates across tools. Security teams burn most of their week triaging noise. FlowRail flips the loop: the design review predicts which threats are actually in scope for this work, the orchestrator runs only the rules that match, and the triage agent contextualizes whatever lands.

02

What it ingests

Semgrep (built-in adapter; FlowRail also drives rule selection from the active review's threats).

SARIF (generic adapter; covers SonarQube, Coverity, CodeQL, and any tool that emits SARIF).

Custom CLI scanners (any tool that outputs JSON; configure a normalizer in flowrail.yaml).

Pre-commit hook output, CI runs (GitHub Actions adapter), and ad-hoc on-demand scans.

Canonical finding shapev0.4.2
{
  "finding_id":     "fnd_d4a1c8e2",
  "scanner":        "semgrep",
  "rule_id":        "javascript.express.injection.tainted-sql-string",
  "cwe":            "CWE-89",
  "severity":       "high",
  "file":           "src/api/orders.ts",
  "line_range":     [42, 51],
  "code_hash":      "sha256:e3b0c44…",
  "correlated_threat": "injection",   // ↳ from the design review
  "correlated_guardrail": "no-sql-string-concat"
}
03

Contextual rule selection

When a scan runs, FlowRail filters its rule set against the active review's threats. A payments-feature review pulls PCI-relevant rules; an internal cron job pulls a leaner set. Same scanner, dramatically smaller noise floor.

04

Where scans run

Always customer-side. FlowRail tells the scanner what to run; the scanner runs in your CI, your laptop, or your pre-commit hook. Findings flow back to FlowRail; raw code never does. The orchestrator sees rule ids, line ranges, and content hashes, never the source.

GitHub Actions integrationv0.4.2
# .github/workflows/security.yml
- uses: flowrail/scan-action@v1
  with:
    workspace-key: ${{ secrets.FLOWRAIL_API_KEY }}
    review-id:     ${{ github.event.pull_request.head.ref }}
    scanners:      semgrep, sarif
05

Ecosystems and roadmap

In v1: Semgrep, SARIF, custom JSON normalizers, GitHub Actions trigger. Further out: Snyk, Wiz, Datadog, Gitleaks, TruffleHog, Dependabot continuous monitoring, full SCA vendor parity. The thesis is that scanning is commoditizing; FlowRail becomes the glue that connects whichever scanners you already pay for.