Vulnerability triage sessions
A triage session is a way to triage analyzer findings not one by one, but by a slice (snapshot): a security engineer goes through the list of snapshot vulnerabilities and assigns a classification to each one, a second employee checks the markup, and only approved classifications are applied to the project.
Until the review is completed, the markup remains a draft: on the “Security” page, detected vulnerabilities continue to be shown as unclassified.
Access permissions
| Action | Required permission |
|---|---|
| Creating a session, markup, submitting for review | Vulnerability triage (TRIAGE_VULNERABILITY_SESSION) |
| Reviewing markup, approving and rejecting | Vulnerability triage review (APPROVE_VULNERABILITY_SESSION) |
| Canceling a session that is under review | Project administrator |
Both permissions are available from the “Developer” level and above.
A session can be opened for reading by its author, the assigned reviewer, and any holder of the triage review permission. Anonymous users do not have access to Triage sessions.
You can go to vulnerability triage by the path Project → Security → Triage. The section contains two tabs:
- My sessions — sessions where you are the author;
- Sessions under review — the general list of submitted project sessions. The tab is visible only with the triage review permission.
Filters “Status” and “Branch”, as well as search by session name, are available on both tabs.
Lifecycle
| Status | What it means | What is available |
|---|---|---|
| New | The session has been created, markup is in progress | Markup, “Finish session”, “Dismiss session” |
| Under review | Submitted, waiting for a reviewer or already assigned to one | View for the author; review for the reviewer; cancellation for the project administrator |
| Rejected | Some positions were returned to the author for revision | Re-markup of returned items, resubmission, engineer reassignment |
| Approved | Markup accepted, classification applied | View only |
| Dismissed | The session was canceled by the author before submission | Not displayed in any list |
Transitions: New → Under review → Approved or → Rejected → Under review (repeat review cycle). It is possible to reject only from the “New” status.
Creating a session
The Start new session button opens the “Create session” window:
- Branch or tag — selected on the corresponding tab;
- Snapshot — a slice of analysis results for the selected branch or tag;
- Report type — SAST, DAST, or SCA.
The report type list offers only those types for which at least one free vulnerability remains in the snapshot — that is, without a classification decision and not occupied by another session. A type for which there is nothing to triage would give an empty queue, so it is not shown and is not accepted.
The session name does not need to be set: it is formed from the snapshot name. Additionally, the session receives a local sequential number in the project; it is shown as #N.
The session is fixed on the combination “snapshot + report type + author”. Until the previous one is approved or dismissed, a second identical one cannot be created — the interface will report that the session is already open, submitted for review, or returned for revision.
Markup
The markup screen is titled “Stage 1: False positive classification” and consists of a list of vulnerabilities on the left and the card of the current vulnerability on the right.
Queue. It contains findings of the selected snapshot and selected report type for which the project does not yet have a classification decision. The order is by severity: high, medium, low, potential.
Occupied vulnerabilities. Vulnerabilities taken into work by another session are not removed from the list, but move to its end and are marked as “Blocked”. When attempting to open such a vulnerability, a message is displayed: the vulnerability is being classified by another user, editing is unavailable. This makes it clear why there are 500 vulnerabilities in the snapshot, but 480 are available for triage.
Classification. Two buttons are available on the card:
- Confirmed threat — the vulnerability is real;
- False positive — the analyzer was mistaken.
The classification can be changed without restrictions until the session is submitted for review. The counter on the session card shows “Checked: N” — how many vulnerabilities have already received a classification.
Vulnerability locking. An opened vulnerability is assigned to the session so that someone else does not triage it at the same time. When the next card is opened, the previous one is released automatically if no classification was assigned to it. Marked vulnerabilities remain assigned until the end of the review.
Completing markup. The Finish session button submits the session for review; the interface warns that after completion it will go to review. Shown but unmarked vulnerabilities return to the common slice. A session with no marked positions cannot be submitted.
The reviewer is not selected during submission: the session goes to the common pool and is assigned to the first person who opens it.
Dismissal. The Dismiss session button is available only before the first submission (from the "My sessions" page). The session changes to the “Dismissed” status, all its locks are removed, and the classification remains unapplied. A session can be dismissed by its author or by a holder of the triage review permission — otherwise an abandoned session would hold vulnerabilities and they would not be available to anyone. After a session has been under review at least once, dismissal is closed to everyone: such a session is unlocked by cancellation, not by dismissal.
Review
On the Sessions under review tab, all submitted project sessions are visible — those awaiting review, rejected ones, and approved ones.
Taking into work. The session is assigned to a reviewer when it is first opened. Taking over is impossible: another employee cannot take an occupied session. By default, the author can review their own session; this behavior is disabled by a project setting (see below) — then the list shows a hint “You cannot review your own session”.
Decisions by positions. For each marked vulnerability, the Accept and Reject buttons are available. Decisions accumulate as a draft: until the review is completed, nothing goes to the project classification, and the decision can be changed.
Completion. The Finish review button applies the result in one operation:
- accepted classification is written to the project classification;
- rejected classifications in the markup are returned to the author with a mark that the reviewer rejected them;
- positions without a decision are also returned to the author;
- locks are removed from applied vulnerabilities.
The outcome depends on whether anything was returned. Something was returned — the session receives the “Rejected” status and goes for revision. Nothing was returned — the status is “Approved” and all session locks are removed.
There is no requirement to decide 100% of positions: unchecked positions are moved to a repeat review cycle.
Session cancellation. The Cancel button (“Session cancellation” window) resets the triage session completely: all positions return to the author, drafts of triage sessions are canceled. The action is available only to the project administrator — this is an emergency mechanism that unlocks the session if the reviewer assigned to it is unavailable. Vulnerability locks are not removed during cancellation: findings are returned to the author together with the vulnerabilities assigned to them.
Engineer reassignment. In a rejected session, the Reassign engineer button transfers it to another employee for repeated markup. It is available to the assigned reviewer and the project administrator. The new engineer must have the vulnerability triage permission, otherwise the session cannot be opened or dismissed. After reassignment, the previous author loses access to the session immediately.
This is the only way out of a situation when the author of a submitted session no longer works on the task: such a session cannot be dismissed, and it holds vulnerabilities.
Re-review
In a rejected session, the author sees only what returned from review: rejected positions and positions for which there was no decision. Already accepted vulnerabilities do not go to re-review — they are applied and are not subject to repeated markup. New vulnerabilities from the snapshot cannot be added to a rejected session.
After repeated markup, the session is submitted with the same Finish session button and again goes to the common pool: it is not assigned to the reviewer who rejected it.
What gets into the project classification
Classification is the final decision on a vulnerability in the project, one per finding. It records the classification, the source session, the markup author, and also who approved the decision and when.
- A record is created only when the review is completed and only for accepted positions.
- A decision is not overwritten repeatedly: if the vulnerability already has a classification, a new record is not created.
- After the decision is recorded, the vulnerability disappears from the queues of all triage sessions — it no longer needs to be triaged.
- For a vulnerability with the “Confirmed threat” classification, tracking in the project's LTS branches is additionally initialized.
Discussions
Three discussion feeds are available inside a session:
| Feed | Where it is shown | Who can write |
|---|---|---|
| General session discussions | On the session screen and on its completion screen | Author and reviewer |
| Vulnerability discussions in this session | On the vulnerability page | Author and reviewer |
| Vulnerability discussions from other contexts | On the vulnerability page, read-only | — |
Anyone admitted to the session can read discussions; only its participants — the author and reviewer — can write. A discussion can be marked as resolved; a new reply makes it unresolved again. Its author deletes their own reply; someone else's reply is deleted by the holder of the discussion deletion permission. In approved and dismissed sessions, feeds are available for reading only.
The discussion counter is shown in the row of each vulnerability and on the session card.
Project settings
Project settings → Security → ASOC: session review.
The “Prohibition on reviewing your own sessions” checkbox determines whether an engineer can review a triage session that they created themselves. It is disabled by default — self-review is allowed.
The prohibition applies only to taking a free session: if the reviewer has already been assigned to a session, they complete the started review to the end.
Important. In a project where only one person has the triage review permission, enabling the prohibition means that their own sessions will never be completed, and the vulnerabilities assigned to them will remain blocked. Enable the setting only if there are several reviewers in the project.
Limitations
- Dismissed sessions are not shown in any list or under any filter.
- Until the session is completed, the classifications assigned in it do not affect the “Security” page: vulnerabilities continue to be considered untriaged.
- The report type or snapshot of a created session cannot be changed — it must be dismissed and a new one created.
Automated translation!
This page has been automatically translated. The text may contain inaccuracies.