Quick Start: Triage a Finding

Every finding gets a persistent triage record. Suppress one and it’s gone from future reports of the same namespace:

curl -X PATCH http://localhost:8000/findings/a3f1c2d4.../TFSEC-040 \
  -H "Content-Type: application/json" \
  -d '{"status": "suppressed", "note": "accepted risk — internal tool"}'

status is one of open, needs_review, acknowledged, suppressed, false_positive — see Findings for the full reference, including how to list and filter finding records.

Say why, and the next analysis is better for it

Every status that carries a verdict is also recorded against the rule that raised it, not just this one finding — that log is what the Rule Health page counts and what later analyses are calibrated on. The optional reason_code is what makes it usable:

curl -X PATCH http://localhost:8000/findings/a3f1c2d4.../TFSEC-040 \
  -H "Content-Type: application/json" \
  -d '{"status": "suppressed", "reason_code": "accepted_risk", "note": "internal tool, no public route"}'

reason_code is one of false_positive, accepted_risk, fixed, not_applicable_here, other.

For suppressed it is the only thing that separates “this is wrong” from “this is right and we accept it” — two opposite signals behind one word. Without it, OpenTremor records the verdict as unclear rather than guessing, and it counts toward neither. acknowledged and false_positive already say which way they point, so there the reason only adds colour. The dashboard asks for it in a dialog when you change a status; over the API it is optional everywhere.

If the finding came from a GitHub pull request, this same call re-posts that PR’s commit status. Acknowledging the last finding holding a check is what turns it green — you don’t need to push again to clear it. See Clearing a held check.

Or answer the pull request

If the finding came from a GitHub pull request, you can record the same verdict without leaving the review. Reply to OpenTremor’s report comment — or write any comment on the pull request — with a command:

@opentremor false-positive TFSEC-040: internal tool, no public route

The GitHub equivalent of the PATCH above. You don’t type a reason_code — the verdict word carries it (false-positive → false_positive, accept-risk → accepted_risk) — and the comment resolves back to the analysis under review on its own. Name the rule id in every command except missed, which describes something no rule caught yet; a command naming a rule the analysis doesn’t have is recorded as unclear rather than dropped, so a typo is visible instead of silent. The @opentremor prefix is the default and is configurable per deployment.

Write it as a new comment or reply, not as an edit to OpenTremor’s own comment — that one is rewritten in place on every push, so an edit to it is overwritten before anyone reads it. See How a reply finds its analysis for why, and Review Feedback Loop for the full verdict vocabulary.

---

Next steps

See Authentication to set up a real multi-tenant deployment, or Review Feedback Loop for what happens to the verdicts you record here — and, at greater length, what they are deliberately not allowed to change.