Findings and triage
Investigate findings, distinguish evidence from severity, and record decisions without mistaking triage for remediation.
Turn an assessment into a review queuePermalink to Turn an assessment into a review queue
Use Findings to work through issues across the workspace, or open a scan result to review one assessment in context. Search by title, file, or repository, then use proof and severity filters to narrow the list. Check loading notices and load more results when available before drawing conclusions from the visible count.
You need access to the workspace and the source code to investigate effectively. In an organization, owners and admins can change triage decisions; other members can read the decision and history. Arrange a reviewer who has the required permission if the Change action is unavailable.
Read the finding detailPermalink to Read the finding detail
- What we found explains the issue. Read it alongside the proof state, not just the title.
- Affected location identifies a file and line when available. Use the source link or Copy path to inspect the code in the assessed version, not only today's branch.
- Code context, when supplied, is a limited source excerpt. Redacted or truncated text is not a complete file.
- Classification may include CWE, CVSS, a category, or tags. Missing classification is missing information, not a low-severity verdict.
- Suggested next step describes remediation when available. Advice is not an applied patch or a promise that an automated fix exists.
- Review may explain why an item was set aside and what to investigate next. Your decision and Timeline record the workspace's triage, separately from the scan's proof state.
Use severity to prioritize, not to provePermalink to Use severity to prioritize, not to prove
| Severity | Practical interpretation |
|---|---|
| Critical | Review promptly with the responsible team and establish applicability and impact. |
| High | Prioritize investigation and remediation planning. |
| Medium | Plan work according to exposure, affected behavior, and other controls. |
| Low | Review in context and include applicable changes in maintenance work. |
| Informational | Read for useful context; it does not by itself establish a vulnerability. |
| Unknown | Determine impact from the content. Unknown does not mean low risk. |
Severity estimates the seriousness of an issue if it holds. It is not proof that the issue exists or is exploitable in your environment. Use proof, application context, and exposure alongside severity when ordering work.
Distinguish confirmed findings from candidatesPermalink to Distinguish confirmed findings from candidates
| Proof state | What it establishes | Next step |
|---|---|---|
| Confirmed | The scan established evidence for the finding within its assessment scope. | Read the evidence and decide how to address it. |
| Needs validation | The issue has not been confirmed. It remains a candidate. | Investigate the affected code and validate the claim within authorized scope. |
| Unconfirmed | The issue was not established. | Review the available explanation and treat it as a lead, not a conclusion. |
Needs validation is not confirmed
Record your decisionPermalink to Record your decision
In the finding detail, open Change under Your decision, select an outcome, add an optional note, and choose Save decision. Include the reasoning, relevant context, and a review or verification reference where useful. Check the updated decision and history after saving.
| Decision | Meaning and effect |
|---|---|
| Open | Keep the item under review, or reopen an earlier decision. This does not promote a candidate to confirmed. |
| Not a real issue | Record a false-positive decision. The item is excluded from confirmed findings and severity summaries. |
| Accepted risk | Record a decision to retain the risk. A confirmed finding remains counted; acceptance is not a fix. |
| Ignored | Record that the team is not acting on the item. It is excluded from confirmed findings and severity summaries. |
| Fixed | Record the team's belief that it is resolved. A confirmed finding remains counted; new verification is still needed. |
Triage is not remediation
Decisions belong to the workspace. The history records changes with the available actor, date, and note. If a save is refused or fails, do not assume the decision changed; check permission and reload the finding before retrying.
Work through a findingPermalink to Work through a finding
Read the original assessment
Check coverage, the assessed version, and the finding's proof state. A filtered list is not the whole scan.
Inspect the affected code
Read surrounding logic and dependency usage. If evidence is incomplete, record what still needs validation instead of filling the gap with assumptions.
Choose and record an action
Plan manual remediation, use an eligible fix proposal, or record a justified triage decision. Keep any runtime validation inside explicit authorization and scope.
Verify the changed code
After the change is reviewed and merged, run an appropriate scan or inspect the available post-merge verification. Check both the original issue and coverage; a lower count alone is not proof of a fix.
Prepare and review an eligible fixPermalink to Prepare and review an eligible fix
A confirmed dependency finding in a connected GitHub repository may offer Prepare fix, Review fix, or Resume review when eligible. The proposal must be reviewed and pass the current safety checks before approval can open a pull request. Relane does not merge for you, and merge is followed by verification rather than an automatic claim that the finding is resolved.