# Vulnerability Management > Read, triage, assign and suppress findings: one record per issue, tracked through its history and closed on evidence. Source: https://scansuite.eu/documentation/usage/vulnerability-management Last reviewed: 2026-10-19 The **Vulnerabilities** page (sidebar, **Library**) is where findings are read, triaged, owned and closed. The AI scans record every finding here with the evidence a developer needs to fix it, and the classic scanners add theirs as described in [Which findings are stored here](https://scansuite.eu/documentation/usage/vulnerability-management#which-findings-are-stored-here). Secrets found in repositories are not listed here: they go to [Credentials](https://scansuite.eu/documentation/usage/credentials). Each issue is one record. The same issue found by several scanners, or found again by a later scan, stays one finding; an issue that comes back after it was resolved reopens the original record instead of arriving as a new one. That is why the counts on this page can be trusted. ## The dashboard The page opens on a summary: scanned products, scanned repositories, total and open vulnerabilities and scans executed, with a severity breakdown that shows the change since the last scan. The product selector at the top of the list (**All Products** or one product) sets what the whole page shows. ![ScanSuite vulnerability dashboard](https://scansuite.eu/static/assets/img/docs/usage/vulnerability-management/01.png) *The vulnerability management dashboard* - **Top 10 Most Vulnerable Targets** and **Top 10 Vulnerability Classes** rank by risk: each open finding counts 40 for Critical, 10 for High, 3 for Medium and 1 for Low. Each item shows how many findings it has; click it to filter the list. Resolved, False Positive and Risk Accepted findings do not count, and in the all-products view a finding that two products share counts once. - **Top 10 LLM Token Consuming Targets** shows which targets the AI scans spent the most on, in tokens and, once models are priced, in money. - With a product selected, the **Last scan** strip says what its latest scan did: how many findings were new, confirmed, reopened and auto-closed. Click a count to list those findings, or the date to open the scan's page. ## Reading a finding Each row of the list is one finding: | Column | What it shows | |---|---| | ID | The CVE, or #id for a finding without one. | | Vulnerability Title | What it is. Under the title, the scanner that found it and the repository; click either to list only its findings. Other scanners that reported the same issue are named beside it, and a Custom rule link opens the rule that reported it. | | Severity | Critical, High, Medium, Low or Info. | | Asset / Target | The file with :line, the URL or the host. The arrow opens the file at that line in the repository, at the commit the scan analysed. | | Product | The product, or N products when several products share the finding. | | Validation | The validation verdict of the finding. Click the chip for the reasoning. Unvalidated means no validation details exist. | | Status | Open, In Progress, Risk Accepted, False Positive or Resolved, with chips: reopened (found again after it was resolved), verified (closed on the scanner's evidence that the defect is gone) and cross-file hunt (found by tracing a request across files). | | Last Confirmed | When a scan last reported it. ×3 counts the scans that reported it; 2 missed counts scans that covered its file without reporting it, which is not yet evidence of a fix. | | Actions | Triage (the menu below), Edit (loads the finding into the Add / Edit Vulnerability form) and Delete. | Click a row to open the finding's details and its history. Click the chip in the **Validation** column to check the reasoning: the code-flow diagram with its step explanation, the reachability rationale, the confidence statement and the risk score. This is also where a [proof of concept](https://scansuite.eu/documentation/usage/vulnerability-management/proof-of-concept) is generated. An AI verdict you cannot audit is just a different kind of false positive. ![ScanSuite finding detail with code-flow diagram](https://scansuite.eu/static/assets/img/docs/usage/vulnerability-management/03.png) *A finding opened to its code-flow diagram, tracing untrusted input to the dangerous sink* A finding found only by the cross-file hunt is closed automatically only by a Verify Fixes run that selects it; see [Rescans and fix verification](https://scansuite.eu/documentation/usage/vulnerability-management/rescans-and-fix-verification). ## Triage a product's findings The everyday job: go through a product's open Critical findings and decide each one. You need the Vulnerability manager, Operator or Team admin role. 1. Open **Vulnerabilities** and choose the product in the product selector. *Check:* the Last scan strip names the product's latest scan. 2. Set the severity filter to **Critical** (it reads **All Severities**) and the status filter to **Open** (it reads **All Statuses**). *Check:* *Showing N entries* gives how many are left. 3. For each finding, click the **Validation** chip and read the verdict, the rationale and the code-flow diagram. Click the row for the description, evidence and solution. 4. Open the row's **Triage** menu (the rule icon under Actions) and choose the decision: **Start work**, **False positive…**, **Accept the risk…**, **Mark resolved…** or **Assign…**. Write the reason and click **Apply**. 5. > **A person does this step:** Accepting a risk, and suppressing a name (below), are decisions a person makes. > > An agent may draft the reason; a person applies it. 6. *Check:* the Status column shows the new status and the finding drops out of the Open filter. Click the row: its **History** has the decision, who made it and the reason. If **Apply** does nothing, the dialog says *A reason is required for this decision.* If the Triage menu is missing, your role cannot change findings. ### Triage decisions | Decision | What it does | Reason | Offered when the finding is | |---|---|---|---| | Start work | Moves the finding to In Progress. | Optional | Open, Resolved, False Positive, Risk Accepted | | Reopen | Puts the finding back to Open. | Optional | Any status but Open | | False positive… | Records why the finding is wrong. | Required | Any status but False Positive | | Accept the risk… | Records why the risk is accepted. | Required | Any status but Risk Accepted | | Mark resolved… | Records how it was fixed. | Required | Any status but Resolved | | Assign… | Sets the Owner and the Due date. | None | Always | | Suppress by name… | See Suppress a noisy check below. | Optional | Always, for operators and team admins | Scans never change Risk Accepted or False Positive. For an AI Static, AI Dependency or custom rule finding, **False positive…** also offers **Don't report this class here again**, with **in this file** (the default), **in this folder** or **anywhere in this repository**. That creates a suppression rule, so later scans stop reporting the class there; see [Custom Rules](https://scansuite.eu/documentation/usage/custom-rules). It is offered to operators and team admins. ![False positive dialog](https://scansuite.eu/static/assets/img/docs/usage/vulnerability-management/04.png) *Ruling out a false positive with a reason, and not reporting the class in this file again* ### Triage through the API The page itself is for people. A script or an agent can read findings and set their status through the team API: `GET /api/teams//findings` (filters `product_id`, `status`, `severity`, `search`), `GET /api/teams//findings/`, and `PATCH` on the same address with `status` and optionally `notes` and `owner`. `notes` replaces the finding's Lifecycle Notes, so send the old notes with the new reason. The token goes in an `Authorization: Bearer` header. | Placeholder | What it is | Where it comes from | |---|---|---| | | The address of your ScanSuite, for example https://scansuite.example.com. | The browser address bar. | | | The team's short name in the API address. | The test command the new-token dialog shows: /api/teams//context. | | | The product's number. | The address of the product's page, or GET /api/teams//products. | | | A finding's number. | The id field of each finding the list returns. | Reading needs a **Reporting** or **CI pipeline** token. Changing a status needs a **Custom** token that includes *Change findings and write proof-of-concept exploits*, on a service account with the Vulnerability manager role or higher; see [Teams and roles](https://scansuite.eu/documentation/administration/teams-and-roles). Suppression rules, Suppress by name, the Actions menu and the exports have no API. > **A person does this step:** Creating the service account and its token is done by a team admin on the Teams page. > > The person puts the token in the SCANSUITE_TOKEN environment variable of the shell the agent uses; it is never typed into a chat. > **Agent prompt: Triage the open criticals with an agent** > > ```text > Read https://scansuite.eu/documentation/usage/vulnerability-management. Using the ScanSuite team API at for team , with the token already in the SCANSUITE_TOKEN environment variable (do not print it or ask me for it), list the Open Critical findings of product . For each, read its details and say whether it looks real or a false positive, and draft a one-paragraph reason. Show me the full list first. Change a status only for the findings I approve, and keep the existing notes when you add the reason. Never accept a risk or suppress anything yourself. > ``` ## Acting on several findings Tick findings in the list, then open **Actions** in the toolbar. The menu stays shut until something is ticked, and then reads **Actions · N**. The checkbox in the header ticks every finding on the current page only. ![Actions menu on the findings list](https://scansuite.eu/static/assets/img/docs/usage/vulnerability-management/02.png) *The Actions menu for a selection of findings* | Item | What it does | Shown to | |---|---|---| | Rescan N findings | Opens Static Code Analysis in Verify Fixes mode with the ticked findings. See [Rescans and fix verification](https://scansuite.eu/documentation/usage/vulnerability-management/rescans-and-fix-verification). | Operators, team admins | | Start work, Reopen, False positive…, Accept the risk…, Mark resolved…, Assign… | The triage decisions above, applied to every ticked finding with one reason. | Vulnerability managers, operators, team admins | | Suppress by name… | Deletes every finding with these names in the product and keeps the names out of later scans. See below. | Operators, team admins | | Delete N findings… | Deletes the ticked findings. | Operators, team admins | Each item appears only for a role that may use it. A reader sees no Actions menu. ## Suppress a noisy check Some checks are noise for a product: a network or web check that does not apply to it, reported again on every scan. **Suppress by name…** removes such a check for good, whichever scanner reports it. 1. Tick one finding of each check to remove (or use the row's Triage menu), open **Actions** and choose **Suppress by name…**. 2. Read the preview. It lists each **Name** (with its **Product** when several products are involved), how many **Findings** have it, and *N finding(s) will be deleted.* 3. > **A person does this step:** Suppressing a name deletes findings and cannot be undone. > > A person confirms it; an agent stops here. 4. Optionally fill in **Reason (optional)**, then click **Suppress and delete**. *Check:* the message says how many names were suppressed and findings deleted, and the name is listed under **Rules → Suppressions → Suppressed names** and on the product's page. - Every finding of that name in the product is deleted, whatever its scanner, target or status, and later scans of the product do not store the name again. - Names match ignoring case and surrounding spaces. AI scanners word their own titles, so a title worded differently is not matched; for code findings, the class rule of **False positive…** is the dependable one. - To store a name again, click **Remove** beside it under Rules → Suppressions. The findings deleted with it do not come back. ## Due dates and deadlines A new finding gets a due date as soon as it is found, from the team's remediation deadlines: by default 7 days for Critical, 30 for High, 90 for Medium and 180 for Low. Info findings get none. The deadlines are set on the **Teams** page, **Scanning** tab, in the **Remediation deadlines** card; 0 turns deadlines off for a severity. Team admins and operators can change them. - A finding keeps the date it was given; a later scan never moves it, and changing a deadline does not change the dates of findings already found. - Change one finding's date with **Assign…**. - Findings past their date are counted as overdue on the [Products](https://scansuite.eu/documentation/usage/products) pages. ## A finding's history Open a finding to see its **History**: when it was detected, each scan that confirmed it, scans that covered its file without reporting it, its closure on the scanner's evidence, a reopening, each status change with who made it and why, a merge into another finding, and suppression. Each entry links to the scan that caused it. ![Finding history timeline](https://scansuite.eu/static/assets/img/docs/usage/vulnerability-management/05.png) *A finding's history: detected, confirmed, closed on evidence, then reopened by a later scan* ## Findings of one scan or one host - From a scan's page, click one of its counts — new, confirmed, reopened, auto-closed — or **View findings** to open this list filtered to that scan. See [The scan page](https://scansuite.eu/documentation/usage/managing-scan-execution/scan-page). - On the [Assets](https://scansuite.eu/documentation/usage/assets) page, a host's **Vulnerabilities** tab lists the findings on it; **Open in Vulnerabilities** opens this list filtered to that host. The active **Scan** or **Asset** filter shows above the list; click ✕ to clear it. ## Search, filter and export | Control | What it does | |---|---| | Search CVEs, titles, targets | Every word must match. Quotes make a phrase. target:"name" and scanner:"engine" are exact filters; clicking a scanner or repository name in a row fills them in. | | Product | All Products, or one product. | | All Severities | One severity. | | All Statuses | One status. | | Class | Set by clicking a class in Top 10 Vulnerability Classes. | **Export** downloads what the page lists: - **Findings report (PDF)** — for managers: the findings these filters show. - **Findings report (HTML)** — for engineers: every finding these filters show, in full. - **XLSX** — the findings these filters show, as a spreadsheet. - With a product selected: **JSON** — every stored row of the product — and **ServiceNow XLSX**, ready to upload. The options of each are in [Reports and exports](https://scansuite.eu/documentation/usage/reports-and-exports); ServiceNow statuses are in [Rescans and fix verification](https://scansuite.eu/documentation/usage/vulnerability-management/rescans-and-fix-verification). ## Adding a finding by hand For issues found outside a scan — a pentest report, a bug bounty submission, a code review — choose a product, open **Add / Edit Vulnerability**, fill in the form and click **Save Vulnerability**. **New** clears the form. The Edit action of a row loads that finding into the same form. | Field | What it holds | Default | |---|---|---| | Title | What it is. | Required | | CVE | The CVE, in the form CVE-2026-0001. | Empty | | Severity | Critical, High, Medium, Low or Info. | Critical | | CVSS | 0 to 10, in steps of 0.1. | Empty | | Target | The URL, host or file. | Required | | Scanner | Who found it, for example Pentest 2026-Q3. | Empty: shown as Manual | | Status | Open, In Progress, Risk Accepted, False Positive or Resolved. | Open | | Owner, Due Date | Who fixes it and by when. | Empty | | Scan ID | A scan to link it to. | Empty | | Product | Read-only: the product chosen in the selector. Save is disabled until one is chosen. | The selected product | | Tags, References | Your own classification and external links. | Empty | | Description, Evidence, Solution | The detail a developer needs. | Empty | | Lifecycle Notes | The running record of decisions about this finding. | Empty | ## Deleting and clearing findings - **Actions → Delete N findings…** deletes the ticked findings; the trash icon of a row deletes one. - **Clear** deletes findings of the selected product. The select beside it chooses **Entire product** or one repository, with its count. Findings whose scan is no longer on record are counted as **Unattributed (N)** and can only be cleared with the entire product or one by one. Deleting, clearing and suppressing by name are for operators and team admins. ## Which findings are stored here The AI scans (AI Native SAST, dependency reachability, AI DAST, AI Pentest), Nessus and your custom rules always store their findings here. The classic scanners — Semgrep, KICS, Trivy, Nuclei, ZAP, Wapiti, Acunetix and OpenVAS — store theirs here as well, according to the **Scanner findings in Vulnerabilities** card on the team's **Scanning** tab. Their reports and DefectDojo get every finding either way. | Setting | What it does | Default | When to change it | |---|---|---|---| | Store scanner findings | Stores the classic scanners' findings on this page. | On | Off when you work those findings only in DefectDojo. | | Lowest severity to store | Findings below this severity stay in the scan reports only. Applies to Nessus too. | Medium | Low or Info to see everything; High to keep the list short. | | Close findings a rescan no longer reports | Semgrep: a Semgrep finding is closed when a rescan of its file with the same rules no longer reports it. All scanners: web and infrastructure findings close too, after two completed scans in a row of the same profile stop reporting them on a service that answered. Off: never. | Semgrep | All scanners when you rescan web apps and hosts on a schedule. | Team admins and operators can change these. CI/CD quality gates count only stored findings. ## Who can do what | Action | Roles | |---|---| | See findings, open details, export | Every role | | Triage, assign, edit, add by hand, generate and refactor a proof of concept | Vulnerability manager, Operator, Team admin | | Run a proof of concept, Rescan N findings | Operator, Team admin | | Don't report this class here again | Operator, Team admin | | Delete, Clear, Suppress by name | Operator, Team admin | See [Teams and roles](https://scansuite.eu/documentation/administration/teams-and-roles).