Findings, prioritization and triage

Where findings live: the Repo, SCM, Cloud, Registry and App Pentest tabs

Every scanner result in Plexicus is converted into one common finding format, then enriched with mappings and scores, plus an AI verdict when AI False-Positive Detection is on. All of it ends up on one page: Findings . That page is split into five tabs, one for each kind of asset you can test.

Tab	What you find there	Where the asset comes from
Repo	Code findings from repository scans: code weaknesses, vulnerable dependencies, hardcoded secrets, and infrastructure-as-code or container configuration declared in the repository	Assets, Repo Scan
SCM	Posture findings about your source-control setup rather than the code inside it	Your connected source-control provider
Cloud	Findings about cloud account configuration, identity and access, and exposed resources, checked against benchmarks	Assets, Cloud Assessment
Registry	Findings for container images discovered in your connected registries, filterable by image, tag and registry connection	Assets, Registry Audit
App Pentest	Findings produced by AI Pentest runs, with the evidence and attack path that proved them	The Pentest section

A SQL injection in a login handler appears under Repo, and so does a vulnerable base image declared in a repository’s Dockerfile. A vulnerable system library inside an image stored in your connected container registry appears under Registry. An IDOR in an invoice API that the AI Pentest reproduced against your authorized target appears under App Pentest. In the product UI, AI Swarm Pentest appears as “AI Pentest” under the Pentest section.

What every tab shares

The tabs share one table, one filter system and one detail view, so the triage skills in this module apply everywhere. Fields that fit only one kind of asset, such as Region for cloud findings, are hidden on tabs where they do not apply.

For native scans, the Tool field shows the Plexicus engine that produced the finding, such as plexicus-sast or plexicus-iac; imported results show the format they were imported from, such as sarif. Module 3 covers which engines exist and what each one covers.

Repo tab extras

The Repo tab has two extra controls on its toolbar:

Upload Scan imports results from an external scanner into a repository you choose. It accepts SARIF 2.1.0 and several commercial scanner formats, and the imported findings land in the Repo tab next to the native ones.
Add Repository starts the same flow you use under Assets, so you can add a repository without leaving Findings.

Columns to show lets you add and reorder table columns such as Priority, Reachability, EPSS, CWE, Issue Owner or Confidence. The layout is saved per user.

Anatomy of a finding

Click any row to open the finding in a detail panel over the list. Press K or J to step to the previous or next finding without closing it.

The header strip shows Severity, CVSS 3.1, Priority, EPSS, Reachability, Internet path and Occurrences. Below it come the sections Code & taint trace (Evidence & attack path for pentest findings), AI verdict, Risk & exposure, Exposure, Compliance & OWASP, Activity (when your role can view the audit trail) and Metadata & notes. Risk & exposure also holds an AI-generated attack scenario; verify it against the trace before acting on it.

Reference: the signals on a finding

Field	What it tells you	How to read it
Severity (scanner)	The raw severity the tool reported	Critical, High, Medium, Low or Informational
Severity	The severity after AI validation	Can rise at most one level above the scanner’s label. An AI false-positive verdict lowers it to Informational without touching the scanner severity. Compare both under “Severity — scanner vs AI”.
Priority	How urgent the finding is in your context, from 0 to 100	Blends severity and impact with exploitability (EPSS, or an AI estimate). Discounted heavily when not reachable, slightly when unknown, and dampened by low confidence. Scores of 90 and above show in red. The score comes from a fixed formula, not from an AI judgment; high-impact weaknesses such as SQL injection, OS command injection, path traversal, SSRF and hard-coded credentials get a bonus.
AI confidence	How strongly the signals agree the finding is real, from 0 to 100	Low below 40, Medium from 40 to 74, High from 75. An “Estimated” badge means it was derived from severity, not measured.
Reachability	Whether the vulnerable code is actually reached	Reachable, Not reachable, Unknown reachability, or N/A
Internet path	Whether a public route reaches the affected workload	exposed, or none (None found under Risk & exposure). It changes priority, never severity.
Exposure section	The deployment checks exposure analysis ran for the workload	A pill reads Exposed, Not exposed or Not analyzed yet; module 5 explains how to read it together with Internet path
EPSS	The probability that the vulnerability is exploited in the wild	Only filled for findings that carry a CVE; otherwise “No data”
CVSS	The standard severity score and vector	CVSS 3.1 in the strip; v3 and v4 as columns and filters. May be labeled estimated (AI) or estimated (severity).
CWE / OWASP	The weakness class and its OWASP Top 10 category	Mapped automatically from the CWE with a short rationale, and also to OWASP CI/CD Top 10 and your enabled compliance controls
Issue Owner	The developer attributed to the code	Filled in from your SCM’s blame of the affected file; the filters call it “Assigned to”
Class	Exploitable issue or posture observation	Vulnerability or Hardening
Occurrences	How many instances exist	Counts instances of the same issue in the repository

Reachability in practice

For a dependency finding, Reachable means the vulnerable symbol is invoked from your application code. For a code finding, it means a dataflow from source to sink was confirmed. Unknown can carry a suffix: “transitive” when it cannot be confirmed for a transitive dependency, or “evaluation error” when the check failed and will be retried.

Reading the taint trace

The Dataflow & Taint Trace shows numbered steps labeled Source, Propagation and Sink, with Cross-File marked when a step crosses files. For a SQL injection in a login handler, the source might be the username parameter, a propagation step the helper that concatenates it into a query string, and the sink the raw query call. Each step carries a provenance badge: Scanner dataflow, AI-verified or AI-inferred (unverified). The panel shows a path only when its source and sink are verified against the repository. An empty trace means no verified path exists yet, or that neither AI False-Positive Detection nor a taint-mode scanner rule produced one for this finding. Module 5 covers how these traces are built.

Statuses and the finding lifecycle

A finding’s status tracks where it is in the remediation workflow. While AI enrichment is still running, a new finding is hidden from the default list. That stage has no label of its own; a finding opened directly already reads AI-Analysed. The labels you see are:

Status	What it means	How a finding gets there
AI-Analysed	Enrichment is complete: scores and mappings are in place, and the AI verdict if AI False-Positive Detection is enabled	Ready for you to triage
Needs Input	The remediation template needs details from you	The remediation button offers Enter details
Ready to Fix	A remediation has been generated, or the finding was sent to developers	After a remediation is generated, or after Send to Dev Team
Fix Submitted	A pull request (a merge request on GitLab) was opened with the fix	After a remediation is submitted to your SCM
Issued	An issue was created for the finding	Used when the remediation type is Issue
Fixed	The fix landed	Your SCM’s webhook reports that its remediation pull request was merged or its linked issue was closed

Fixed depends on your team: your reviewers decide whether and when to merge.

Flags that sit beside the status

False positive. A finding can be judged not real in two ways. AI False-Positive Detection is an optional organization setting under Settings Platform , off by default and available depending on your plan; it runs an AI pass after each scan. You can also decide yourself with Mark as false positive in the finding’s detail panel. A human mark closes the finding’s open fix pull requests, deletes its generated remediations, updates the repository’s counts and records the verdict as human. It also opens a pull request that adds an inline suppression comment for that rule, at no cost to your AI usage allowance (module 7). The verdict is remembered within your organization only: later scans auto-suppress the same rule firing on structurally identical code. With the built-in roles, Admin and Cyberoper can mark false positives; Developer-role users cannot.

Revert false positive undoes it: the finding returns to AI-Analysed and its Severity is reset to the scanner severity. False positives are hidden from the default list, so keep a link to any finding you may need to revisit.

Automated verdicts get extra checks before they hide a finding, but do not treat those checks as a guarantee. If your organization turns on AI False-Positive Detection, agree how AI verdicts on Critical, High, reachable or exposed findings get a human look. A finding still pending false-positive review cannot be remediated yet, and the remediation button tells you so.

Mitigated. Mark as mitigated sets the finding’s Mitigated Externally flag. Use it when the risk is handled outside the code, for example by a WAF rule. It does not change the workflow status, and the finding stays in your list. Once you use it, the button disappears, and the flag cannot be undone in the console, so be sure before you click. Plexicus has no separate accept-risk or snooze status; record the compensating control in your ticket.

Duplicate and sub-finding. These are set by Plexicus, not by you. Duplicates are explained under Re-detection below, and sub-findings in the next lesson.

Request review

When a finding’s status is Ready to Fix, a user with the Developer role sees Request review in the detail panel. It sends a Review Request notification, and reviewers find these under Notifications Review Requests , opened from the header bell.

Re-detection

A new finding at the same repository, file and line, with the same CVE or finding type, is marked a Duplicate of the earlier one, and the surviving finding keeps the worst severity of the pair. Depending on your organization’s configuration, a later scan that detects a finding that was Fixed or Issued can reopen it: the finding goes back through analysis and is recorded as reopened.

Re-Scan under Assets Repo Scan clears a repository’s findings and their statuses (module 2); use Relaunch scan in the Activity Center to keep them. False-positive marks made by people are remembered and applied again when the same unchanged code is scanned.

When your role can view the audit trail, the finding’s Activity section lists its history, newest first: status changes, remediations generated, created or updated, bulk remediation requests and exports, each attributed to Pipeline or User.

Finding what matters: chips, query bar, filters, views and the AI filter

Nobody reads every finding. The toolbar gives you five ways to put the right ones first.

The query bar and triage chips

The query bar searches finding titles, CVEs, packages and files. Next to it, the Triage chips apply one-click filters, each with a live count: Critical, High, Medium, Reachable, EPSS ≥ 0.5, Vulnerability and New 7d. Combining Critical, High and Reachable is a fast way to see real, urgent work. New 7d shows what arrived in the last seven days. The Reachable, EPSS, Vulnerability and New 7d chips add their condition to whatever filter is already active, so they narrow the current view rather than replace it.

The severity chips filter on Severity (scanner); to filter on the AI-validated value, use Severity in All filters.

Grouped filters

All filters opens the Filters modal, where fields are grouped by the question they answer:

What to look at first: Severity, Severity (scanner), Priority, Finding confidence, Class and Finding status
Real risk: Reachable, EPSS, CVSS v3, CVSS v4 and Occurrences
Weakness type: CWE, CVE, OWASP Top 10, Type and Category
Compliance: Regulation, Control and Control category, limited to the regulations your organization enabled
Where it lives: Repository, File, Language and similar location fields
Dependencies: Library and Library version
Scanner: Tool, Rule and Provider
Team & flow: Assigned to, Tags, Remediation type and Fixing effort
Container registry: image fields, shown on the Registry tab

Each value can be included or excluded. Click a pill’s field name in the query bar to switch its operator between is and is not, or in and not in. The apply button reads “View N findings” and its count updates as you adjust, so you never apply a filter blind.

Saved views and shared links

Once a filter is right, save it: Findings Views Save view , give it a name such as “Daily triage”, then click Save. Applying a saved view later takes one click. The URL always carries the current filter, so Copy link shares the exact view with a teammate.

The plain-language AI filter

Depending on your plan, the wand icon in the query bar opens “Describe what you want to see”. Type a request such as “critical injection findings in the payments repo from the last week” and click Build filter. Plexicus turns the sentence into a structured filter. Each request uses one AI filter conversion. Conversions have their own monthly allowance, separate from the AI usage allowance that fixes and false-positive analysis draw on. Check the generated filter before acting on the results, and save it as a view to reuse it.

What is hidden by default, and why

The default list hides five kinds of findings:

False positives, because they are judged not real
Duplicates, because the surviving finding already represents them
Sub-findings: dependency findings for the same library, version and CVE at the same location are grouped under a main finding, and fixing the main finding fixes them too. A sub-finding’s detail shows Go to Parent Finding.
Deleted findings
Findings still being enriched, because their priority and AI verdict are not ready yet

Not-reachable findings are never hidden by default. Reachability lowers their priority, but a static verdict is evidence, not proof of safety, so the finding stays visible. If you want them out of a particular view, filter on Reachable yourself.

Acting on findings: owners, tickets, remediation, reports and exports

Triage only pays off when every finding that matters ends with an owner and a next step.

Owners

Each code finding’s Issue Owner comes from your SCM’s blame of the affected file. Use the “Assigned to” filter to build a queue for one developer or check one person’s load.

To hand work to developers explicitly, select findings and use Send to Dev Team. It applies to findings that already have a generated remediation: they are assigned to the users with the Developer role, move to Ready to Fix, and record who requested the review. Developer-role users see only the findings assigned to them.

Bulk actions and roles

Bulk actions need at least two selected rows, and what you see depends on your role:

Role	Bulk actions
Admin	Remediate, Send to Dev Team, Create Pull Request
Cyberoper (security operator)	Remediate, Send to Dev Team
Developer	Create Pull Request, enabled only when the selection includes a Ready to Fix finding

Tickets

In the detail panel header, Create Ticket offers your organization’s active ticketing integrations: Jira opens a ticket form, ServiceNow raises an incident, and Webhook sends the finding to your configured issue webhook. If nothing is configured, the menu links to the ticketing integrations page. Module 9 covers setting these up.

Starting remediation

Each finding has a remediation type. Pull request means a code change; the button reads Create AI Remediation. Issue is used when there is no source line to change, for malicious artifacts, and for providers without pull requests; the button reads Create Issue. The footer link “Open in” plus your provider name and line number jumps straight to the file in your SCM.

Cloud and SCM findings have no remediation button, because there is no repository file to change. A registry finding offers Remediate in repo once its image is linked to a source repository.

For several findings at once, select them and choose Remediate. Plexicus groups them by repository, and you choose whether to Automatically create pull requests and which pull request mode to use (Single PR or One PR per remediation, the default). Module 7 explains both modes and the Bulk remediation status panel. AI remediation counts against your AI usage allowance.

Either way, Plexicus prepares a reviewable change and never pushes to production; your team keeps merge control. Module 7 covers remediation in depth.

Reports and exports

You need	Use	What you get
A shareable report of the current view	Download, then PDF	Generated in the background; a toast says “We’ll email you when it’s ready” and a Report Ready notification follows
Machine-readable findings	Download, then JSON	A SARIF 2.1.0 file (findings.json) of the current tab and filters, downloaded right away. By default it includes only findings in the AI-Analysed status (module 8).
One finding for a ticket or review	Download report, in the detail panel	That one finding as a SARIF document
Your repository inventory	Download, under Assets, Repo Scan	repositories.csv

Both list exports respect the active tab and filters. JSON exports are recorded in the audit trail. Reading findings through the REST API is covered in module 9.

Measuring progress on the Dashboard

Module 2 introduced the Dashboard tabs and filters; this lesson covers the widgets that track triage progress. Triage is a daily habit, and Dashboard tells you whether it is working.

What the totals count

Dashboard totals reflect open work. They exclude duplicates, sub-findings, false positives, deleted findings and findings already marked Fixed. Hardening findings are kept apart from the vulnerability figures. That is why a good triage week makes the numbers drop: marking false positives and merging fixes both remove findings from the open count.

The widgets that answer “are we getting better?”

Widget	Tab	What it shows
Risk Posture Score	CISO	A 0–100 score where higher is worse, built from open findings weighted by severity, with reachable findings weighing more. It shows a risk-appetite line, a trend, and a hint such as “Fix N findings to reach appetite”. The appetite line is fixed for now and cannot be configured.
New vs Fixed	CISO	Findings created per day against findings that reached Ready to Fix, Fix Submitted, Issued or Fixed, dated by their remediation
Top Risky Repositories	CISO	Repositories ranked by a risk score built from their findings’ severities and EPSS, with a trend arrow. The tooltip shows the score and the Critical and High counts. It is a current snapshot, so the repository filter applies but the date range does not.
MTTR / Remediation Velocity	DevSecOps	Two lines in days: Time to attempt, from a finding’s date until a remediation started, and Time to fix, from that remediation until it completed
Aging Buckets	DevSecOps	Open findings by severity in four age buckets: under 7 days, 7–30 days, 30–90 days and 90 days or more
Reachability Split	DevSecOps	Findings by severity, split into Reachable, Unreachable and Unknown

Other widgets include Total Findings, Supply Chain, Internet exposure, Scanner Coverage and the OWASP views. In Total Findings, Prioritized Vulnerabilities counts the open findings with a priority of 80 or more.

Reading MTTR

The two MTTR lines point to different bottlenecks. A long Time to attempt means findings wait before anyone starts a fix, which is a triage or ownership problem. A long Time to fix means remediations were started but take a long time to complete; compare it with Time to attempt to see whether work stalls before or after a remediation starts.

New vs Fixed compares arrivals with findings that received a remediation. If New stays above Fixed for weeks, remediation is not keeping pace with new findings.

Plexicus has no SLA or due-date tracking; use Aging Buckets and MTTR to see how long findings stay open.

Key takeaways

Findings live in five tabs (Repo, SCM, Cloud, Registry and App Pentest) that share one table, one filter system and one detail view.
Severity says how bad a finding could be; the 0–100 priority score says how urgent it is here, adjusted by exploitability, reachability, confidence and exposure.
Statuses run from AI-Analysed to Fixed. False positive and Mitigated Externally are flags, and a human false-positive mark can be reverted.
False positives, duplicates, sub-findings, deleted findings and findings still enriching are hidden by default. Not-reachable findings are only deprioritized.
Save your best filters as views, share them with Copy link, and give every finding that matters an owner, a ticket or a reviewable fix.
Dashboard totals count open work only. Use New vs Fixed, MTTR, Aging Buckets and Risk Posture Score to track progress.