Compare, trust & readiness
Three companion views answer: what changed, how reliable is this scan, and can I rerun?
Compare
Compare answers what changed against the prior successful scan on the same target. It surfaces baseline counts plus delta movement (new, recurring, regressed, fixed, suppressed) so you can read churn at a glance.
GET /api/scan-runs/{id}/compareTrust
Trust explains how reliable the run is. It carries:
- Score (0–100) and label.
- Verification mix — verified vs unverified findings.
- Skipped scanners and the reason each was skipped.
- Replay readiness for runtime-discovered issues.
- Coverage gaps (missing credentials, sandbox limits, build failures).
- Recommended follow-up actions.
GET /api/scan-runs/{id}/trustTrust labels
| Label | Score | What it means |
|---|---|---|
strong | ≥ 80 | Full coverage; verified findings present where applicable. |
moderate | ≥ 55 | Some scanners skipped or runtime testing limited. |
limited | < 55 | Substantial coverage gaps; treat findings as a starting point. |
degraded | — | Coverage was reduced enough that the run is annotated as degraded. |
scanner_skipped, runtime_not_tested, replay_unavailable, and degraded. Each gap names the affected tool or capability so you know what to fix before rerunning.Readiness
Readiness answers can I rerun. Review detail surfaces a rerun affordance only when readiness is positive: GitHub access reachable, env-var signals present, supported app type, and replay prerequisites met.
POST /api/reviews/{id}/rerunDegraded scans
A scan completes degraded when it ran 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. Use repo secrets to fix missing credentials before rerunning.