Vulnerability Management

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. Secrets found in repositories are not listed here: they go to 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.

zoom_inEnlarge

• 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:

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 is generated. An AI verdict you cannot audit is just a different kind of false positive.

zoom_inEnlarge

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.

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. Accepting a risk, and suppressing a name (below), are decisions a person makes.

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

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. It is offered to operators and team admins.

zoom_inEnlarge

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/<TEAM>/findings (filters product_id, status, severity, search), GET /api/teams/<TEAM>/findings/<ID>, 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.

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. Suppression rules, Suppress by name, the Actions menu and the exports have no API.

Read https://scansuite.eu/documentation/usage/vulnerability-management. Using the ScanSuite team API at <SCANSUITE_URL> for team <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 <PRODUCT_ID>. 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.

zoom_inEnlarge

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. Suppressing a name deletes findings and cannot be undone.

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 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.

zoom_inEnlarge

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.
• On the 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

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; ServiceNow statuses are in 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.

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.

Team admins and operators can change these. CI/CD quality gates count only stored findings.

Who can do what

See Teams and roles.