Operator FAQ

The issue was confirmed through runtime or interaction testing. It’s stronger than an unverified static hit, but you should still inspect the evidence and trust context before prioritizing work. See Findings & evidence.

critical and high findings cause the PR check to fail. medium, low, and info are reported but non-blocking. See Severity & merge blocking.

A scan that completed with limited coverage. Findings still persist, but trust drops and the run should be reviewed for skipped scanners, coverage gaps, missing secrets, or sandbox limitations. See Trust & readiness.

Browser-based web applications. Scans against repositories that can’t be served as one finish in a blocked state with an Unsupported App message — the PR check completes neutrally instead of returning a misleading pass.

Suppressions are fingerprint-based. Repo scope hides the finding only for that repository. User scope applies across that user’s matching findings, regardless of repo. When multiple suppressions match the same fingerprint, the most recent one wins. Deleting the suppression restores the finding presentation without touching history.

Use Settings > Environment Secrets or persist new env vars from the scan launcher. Values are encrypted at rest with AES-256-GCM and decrypted server-side only when injected into the sandbox at scan time. Listing endpoints return key names and metadata only — values are masked.

Yes. Add .infiniview.yml at the repo root for scanner, threshold, exclusion, runtime-agent, timeout, plan, and evidence-detail overrides. Repo config wins for overlapping fields. See Configuration.

Yes. POST /api/validate-infiniview-yml is unauthenticated. POST { "yaml": "..." } and you’ll get { valid, errors } back.

Most common reasons: the PR is still in draft, the repo isn’t in the auto-review allowlist, own-PR-only is enabled and the PR was opened by another author, the PR was previously ignored with @infiniview ignore, or the synchronize event landed inside the push debounce window.

Owners, members, or collaborators on the repository, or users with write, maintain, or admin permission. Comments from anyone else are ignored.

Open the run from review detail. The page streams updates over Server-Sent Events at /api/scan-runs/{id}/live. For one-shot polling there’s also /api/scan-runs/{id}/progress.

Budgets adapt to the size and complexity of the repo. The wall-clock cap is one hour; smaller repositories typically finish well under that. The configured wall-clock setting acts as a floor.

Yes. The GitHub App requests read access only to repositories you explicitly install it on. Private and public repositories work identically.

Encrypted at rest with AES-256-GCM. Values are decrypted server-side only when injected into the sandbox at scan time. Listing endpoints return key names and metadata only — values are masked. Sandboxes are ephemeral and torn down at the end of each run.

Yes. Scope a scan to a subpath via exclude_paths in .infiniview.yml, or rely on default scanners to walk the tree. For very large monorepos, lower max_plans and tighten exclusions to stay within the wall-clock cap.

Validation is available without the App — POST /api/validate-infiniview-yml is unauthenticated and safe to call from CI. Triggering a full scan still requires the GitHub App on the target repo or a manual scan launched from the dashboard.

Reviews, runs, findings, and proof bundles remain readable through the retention window listed on your plan. New scans can’t be launched after cancellation takes effect. See Billing & plans.

Yes. GET /api/scan-runs/{id}/comparereturns baseline counts plus delta movement (new, recurring, regressed, fixed, suppressed) for the run versus the previous successful scan on the same target. The dashboard’s Compare panel renders the same data.

Use GET /api/security-findings/export?scope=all. The backlog export streams CSV across active and archived runs. For per-run dumps, GET /api/scan-runs/{id}/csv is available once the run reaches a terminal status. See Exports & bundles.