Triage
Findings live on the project, with a note of which branch they were seen on. A won't-fix on main stays a won't-fix on the next PR. "Show only new issues on this PR" is a first-class view.
Statuses
| Status | Meaning | Still open? | Blocks the PR gate? |
|---|---|---|---|
new | Just discovered | yes | yes |
triaged | Looked at, not decided | yes | yes |
accepted | Follow-up later / accepted risk | yes | no |
needs_retest | Ready for a targeted retest | yes | yes |
still_vulnerable | Retest saw it again | yes | yes |
fixed | Gone, or a covered retest confirmed it | no | no |
false_positive | Not a real issue (--reason required) | no | no |
wont_fix | Accepted risk | yes | no |
accepted and wont_fix stay on the dashboard (open) but drop out of actionable, so gate and wait stop blocking. That is how an agent loop can converge after a risk decision.
Every change records who did it.
From the CLI
thespider-agent findings triage 501 --status triaged --note "reviewing this sprint"
thespider-agent findings triage 501 --status accepted --reason "compensating control in the WAF"
thespider-agent findings triage 501 --status false_positive --reason "test fixture, not shipped"
thespider-agent findings triage 501 --status fixed --commit 9f3c1ab
To triage only what a run just added, cut the list at the campaign you already reviewed:
thespider-agent findings list --actionable --since 25
--since takes a campaign id (findings discovered after it) or an ISO date, so an incremental
pass never means diffing two full listings by hand. It is a different question from --campaign N,
which selects everything sighted in that campaign, re-confirmations included.
--status takes the eight rows above. open / closed / actionable are filters, not statuses. --commit is for fixed. thespider-agent refine records proposed-fix commits as needs_retest plus commits on the same endpoint. --decider defaults to thespider-agent@<host> so the history timeline is never "No decider."
Link a finding to its merge request
When an agent (or you) opens a merge request or pull request that addresses findings, link it, so anyone looking at the findings list can see which ones already have a change in flight.
# One merge request, three findings. The address is built from the git remote.
thespider-agent findings link 501 502 503 --mr 128
# Or give the address yourself. Any http(s) URL works: GitLab, GitHub, Bitbucket, Azure DevOps,
# Gitea, Jira, Linear, or your own tracker.
thespider-agent findings link 501 --url https://gitlab.com/acme/api/-/merge_requests/128
# What still has no merge request?
thespider-agent findings list --actionable --unlinked
--mr (alias --pr) takes the number only; the repository's git remote supplies the rest. With
several remotes it uses origin, otherwise the first one configured, and --remote NAME overrides that.
The host decides the address shape (GitLab, GitHub, Bitbucket and Gitea are built in); for a
self-hosted host whose name does not say which it is, add --forge gitlab or pass --url.
Linking the same merge request twice changes nothing, and findings unlink removes a link. In the
web UI the findings list shows a chip for each link (the GitLab, GitHub or Bitbucket mark and the
!128 or #57 reference), the Links filter narrows to findings with or without one, and the
finding's drawer lists them with an add and remove control. The server never contacts GitLab or
GitHub, so a link records that a change exists, not whether it has merged.
New on a PR
The gate reports open findings whose first sighting is this PR branch and, for incrementals, whose files overlap changed_paths. Two common false "new"s:
- A rename may or may not de-duplicate onto the old finding.
- A model that never reported an old issue on
maincan look new on the PR. A reasonably fresh full scan of the default branch helps.
Duplicates attach to one canonical finding during ingest. There is no manual merge button in the UI or API today.
Model text is untrusted: the UI renders it as text, never as HTML. Export JSON downloads the filtered set.