Befunde, Priorisierung und Triage

Wo Befunde liegen: die Tabs Repo, SCM, Cloud, Registry und App Pentest

Jedes Scanner-Ergebnis in Plexicus wird in ein einheitliches Befundformat umgewandelt und dann mit Zuordnungen und Scores angereichert, dazu mit einem KI-Urteil, wenn AI False-Positive Detection aktiviert ist. Alles landet auf einer Seite: Findings . Diese Seite ist in fünf Tabs aufgeteilt, einen für jede Art von Asset, die du testen kannst.

Tab	Was du dort findest	Woher das Asset kommt
Repo	Code-Befunde aus Repository-Scans: Schwächen im Code, verwundbare Abhängigkeiten, hartcodierte Secrets sowie Infrastructure-as-Code- oder Container-Konfiguration, die im Repository deklariert ist	Assets, Repo Scan
SCM	Posture-Befunde zur Einrichtung deiner Quellcodeverwaltung, nicht zum Code darin	Dein verbundener Anbieter für Quellcodeverwaltung
Cloud	Befunde zur Konfiguration von Cloud-Konten, zu Identitäten und Zugriffen sowie zu exponierten Ressourcen, geprüft gegen Benchmarks	Assets, Cloud Assessment
Registry	Befunde zu Container-Images, die in deinen verbundenen Registries gefunden wurden, filterbar nach Image, Tag und Registry-Verbindung	Assets, Registry Audit
App Pentest	Befunde aus AI Pentest-Läufen, mit der Evidenz und dem Angriffspfad, die sie belegt haben	Der Bereich Pentest

Eine SQL-Injection in einem Login-Handler erscheint unter Repo, ebenso ein verwundbares Base-Image, das im Dockerfile eines Repositorys deklariert ist. Eine verwundbare Systembibliothek in einem Image, das in deiner verbundenen Container-Registry liegt, erscheint unter Registry. Eine IDOR-Schwachstelle in einer Rechnungs-API, die der AI Pentest gegen dein autorisiertes Ziel reproduziert hat, erscheint unter App Pentest. In der Produktoberfläche heißt AI Swarm Pentest „AI Pentest“ und liegt im Bereich Pentest.

Was alle Tabs gemeinsam haben

Die Tabs teilen sich eine Tabelle, ein Filtersystem und eine Detailansicht, daher gilt alles, was du in diesem Modul über Triage lernst, überall. Felder, die nur zu einer Art von Asset passen, etwa Region bei Cloud-Befunden, sind in den Tabs ausgeblendet, in denen sie nicht zutreffen.

Bei nativen Scans zeigt das Feld Tool die Plexicus-Engine, die den Befund erzeugt hat, etwa plexicus-sast oder plexicus-iac; importierte Ergebnisse zeigen das Format, aus dem sie importiert wurden, etwa sarif. Modul 3 behandelt, welche Engines es gibt und was jede abdeckt.

Extras im Tab Repo

Der Tab Repo hat in seiner Toolbar zwei zusätzliche Bedienelemente:

• Upload Scan importiert Ergebnisse eines externen Scanners in ein Repository deiner Wahl. Es akzeptiert SARIF 2.1.0 und mehrere Formate kommerzieller Scanner, und die importierten Befunde landen im Tab Repo neben den nativen.
• Add Repository startet denselben Ablauf, den du unter Assets nutzt. So fügst du ein Repository hinzu, ohne Findings zu verlassen.

Mit Columns to show fügst du Tabellenspalten wie Priority, Reachability, EPSS, CWE, Issue Owner oder Confidence hinzu und ordnest sie neu an. Das Layout wird pro Benutzer gespeichert.

Anatomie eines Befunds

Klick auf eine beliebige Zeile, um den Befund in einem Detailpanel über der Liste zu öffnen. Mit K oder J springst du zum vorherigen oder nächsten Befund, ohne das Panel zu schließen.

Die Kopfleiste zeigt Severity, CVSS 3.1, Priority, EPSS, Reachability, Internet path und Occurrences. Darunter folgen die Abschnitte Code & taint trace (Evidence & attack path bei Pentest-Befunden), AI verdict, Risk & exposure, Exposure, Compliance & OWASP, Activity (wenn deine Rolle den Audit-Trail sehen darf) und Metadata & notes. Risk & exposure enthält außerdem ein KI-generiertes Angriffsszenario; gleiche es mit dem Trace ab, bevor du danach handelst.

Referenz: die Signale an einem Befund

Feld	Was es dir sagt	Wie du es liest
Severity (scanner)	Der rohe Schweregrad, den das Tool gemeldet hat	Critical, High, Medium, Low oder Informational
Severity	Der Schweregrad nach der KI-Validierung	Kann höchstens eine Stufe über dem Label des Scanners liegen. Stuft die KI einen Befund als False Positive ein, sinkt der Wert auf Informational, ohne dass sich der Scanner-Schweregrad ändert. Vergleiche beide unter „Severity — scanner vs AI“.
Priority	Wie dringend der Befund in deinem Kontext ist, von 0 bis 100	Kombiniert Schweregrad und Auswirkung mit der Ausnutzbarkeit (EPSS oder einer KI-Schätzung). Wird stark abgewertet, wenn der Code nicht erreichbar ist, leicht, wenn die Erreichbarkeit unbekannt ist, und bei niedriger Konfidenz gedämpft. Werte ab 90 erscheinen rot. Der Score stammt aus einer festen Formel, nicht aus einem KI-Urteil; Schwächen mit hoher Auswirkung wie SQL-Injection, OS Command Injection, Path Traversal, SSRF und hartcodierte Zugangsdaten erhalten einen Bonus.
AI confidence	Wie stark die Signale darin übereinstimmen, dass der Befund echt ist, von 0 bis 100	Low unter 40, Medium von 40 bis 74, High ab 75. Das Badge „Estimated“ bedeutet, dass der Wert aus dem Schweregrad abgeleitet und nicht gemessen wurde.
Reachability	Ob der verwundbare Code tatsächlich erreicht wird	Reachable, Not reachable, Unknown reachability oder N/A
Internet path	Ob eine öffentliche Route den betroffenen Workload erreicht	exposed oder none (unter Risk & exposure: None found). Das Feld ändert die Priorität, nie den Schweregrad.
Abschnitt Exposure	Die Deployment-Prüfungen, die die Exposure-Analyse für den Workload ausgeführt hat	Ein Badge zeigt Exposed, Not exposed oder Not analyzed yet; Modul 5 erklärt, wie du es zusammen mit Internet path liest
EPSS	Die Wahrscheinlichkeit, dass die Schwachstelle in freier Wildbahn ausgenutzt wird	Nur bei Befunden mit CVE gefüllt; sonst „No data“
CVSS	Der standardisierte Schweregrad-Score und sein Vektor	CVSS 3.1 in der Kopfleiste; v3 und v4 als Spalten und Filter. Kann als estimated (AI) oder estimated (severity) gekennzeichnet sein.
CWE / OWASP	Die Schwachstellenklasse und ihre Kategorie in den OWASP Top 10	Automatisch aus der CWE zugeordnet, mit kurzer Begründung, außerdem den OWASP CI/CD Top 10 und deinen aktivierten Compliance-Kontrollen
Issue Owner	Der Entwickler, dem der Code zugeschrieben wird	Wird aus dem Blame deines SCM für die betroffene Datei übernommen; in den Filtern heißt das Feld „Assigned to“
Class	Ausnutzbares Problem oder Posture-Beobachtung	Vulnerability oder Hardening
Occurrences	Wie viele Instanzen es gibt	Zählt die Instanzen desselben Problems im Repository

Erreichbarkeit in der Praxis

Bei einem Abhängigkeitsbefund bedeutet Reachable, dass das verwundbare Symbol aus deinem Anwendungscode aufgerufen wird. Bei einem Code-Befund bedeutet es, dass ein Datenfluss von der Source zum Sink bestätigt wurde. Unknown kann einen Zusatz tragen: „transitive“, wenn sich die Erreichbarkeit bei einer transitiven Abhängigkeit nicht bestätigen lässt, oder „evaluation error“, wenn die Prüfung fehlgeschlagen ist und wiederholt wird.

Den Taint-Trace lesen

Der Dataflow & Taint Trace zeigt nummerierte Schritte mit den Labels Source, Propagation und Sink; Cross-File markiert einen Schritt, der Dateigrenzen überschreitet. Bei einer SQL-Injection in einem Login-Handler könnte die Source der Parameter für den Benutzernamen sein, ein Propagation-Schritt die Hilfsfunktion, die ihn in einen Query-String verkettet, und der Sink der Aufruf der rohen Query. Jeder Schritt trägt ein Herkunfts-Badge: Scanner dataflow, AI-verified oder AI-inferred (unverified). Das Panel zeigt einen Pfad nur, wenn seine Source und sein Sink gegen das Repository verifiziert sind. Ein leerer Trace bedeutet, dass noch kein verifizierter Pfad existiert oder dass für diesen Befund weder AI False-Positive Detection noch eine Scanner-Regel im Taint-Modus einen erzeugt hat. Modul 5 behandelt, wie diese Traces entstehen.

Status und Lebenszyklus eines Befunds

Der Status eines Befunds zeigt, wo er im Behebungs-Workflow steht. Solange die KI-Anreicherung noch läuft, ist ein neuer Befund in der Standardliste ausgeblendet. Diese Phase hat kein eigenes Label; ein direkt geöffneter Befund zeigt bereits AI-Analysed. Die Labels, die du siehst, sind:

Status	Was er bedeutet	Wie ein Befund dorthin kommt
AI-Analysed	Die Anreicherung ist abgeschlossen: Scores und Zuordnungen liegen vor, dazu das KI-Urteil, wenn AI False-Positive Detection aktiviert ist	Bereit für deine Triage
Needs Input	Die Behebungsvorlage braucht Angaben von dir	Der Button zur Behebung bietet Enter details an
Ready to Fix	Eine Behebung wurde erzeugt, oder der Befund wurde an die Entwickler geschickt	Nachdem eine Behebung erzeugt wurde oder nach Send to Dev Team
Fix Submitted	Ein Pull Request (bei GitLab ein Merge Request) mit dem Fix wurde geöffnet	Nachdem eine Behebung an dein SCM übermittelt wurde
Issued	Für den Befund wurde ein Issue erstellt	Wird genutzt, wenn der Behebungstyp Issue ist
Fixed	Der Fix ist umgesetzt	Der Webhook deines SCM meldet, dass der Pull Request der Behebung gemergt oder das verknüpfte Issue geschlossen wurde

Ob ein Befund Fixed erreicht, liegt bei deinem Team: Deine Reviewer entscheiden, ob und wann gemergt wird.

Flags neben dem Status

False Positive. Ein Befund kann auf zwei Wegen als nicht echt eingestuft werden. AI False-Positive Detection ist eine optionale Organisationseinstellung unter Settings Platform , standardmäßig aus und je nach Plan verfügbar; sie führt nach jedem Scan einen KI-Durchlauf aus. Du kannst auch selbst entscheiden, mit Mark as false positive im Detailpanel des Befunds. Eine menschliche Markierung schließt die offenen Fix-Pull-Requests des Befunds, löscht seine erzeugten Behebungen, aktualisiert die Zahlen des Repositorys und speichert das Urteil als menschlich. Außerdem öffnet sie einen Pull Request, der für diese Regel einen Inline-Suppression-Kommentar hinzufügt, ohne dein KI-Nutzungskontingent zu belasten (Modul 7). Das Urteil wird nur innerhalb deiner Organisation gespeichert: Spätere Scans unterdrücken dieselbe Regel automatisch, wenn sie bei strukturell identischem Code anschlägt. Mit den integrierten Rollen dürfen Admin und Cyberoper False Positives markieren, Benutzer mit der Rolle Developer nicht.

Revert false positive macht das rückgängig: Der Befund kehrt zu AI-Analysed zurück, und sein Wert für Severity wird auf den Scanner-Schweregrad zurückgesetzt. False Positives sind in der Standardliste ausgeblendet, also bewahre dir einen Link zu jedem Befund auf, den du dir später noch einmal ansehen musst.

Automatisierte Urteile durchlaufen zusätzliche Prüfungen, bevor sie einen Befund ausblenden, aber verlass dich nicht darauf, dass diese Prüfungen eine Garantie sind. Wenn deine Organisation AI False-Positive Detection aktiviert, vereinbart im Team, wie KI-Urteile zu Befunden, die Critical, High, erreichbar oder exponiert sind, noch von einem Menschen geprüft werden. Ein Befund, dessen False-Positive-Prüfung noch aussteht, lässt sich noch nicht beheben, und der Button zur Behebung sagt dir das.

Mitigated. Mark as mitigated setzt das Flag Mitigated Externally des Befunds. Nutze es, wenn das Risiko außerhalb des Codes behandelt wird, etwa durch eine WAF-Regel. Es ändert den Workflow-Status nicht, und der Befund bleibt in deiner Liste. Sobald du es genutzt hast, verschwindet der Button, und das Flag lässt sich in der Konsole nicht rückgängig machen. Sei dir also sicher, bevor du klickst. Plexicus hat keinen eigenen Status, um ein Risiko zu akzeptieren oder einen Befund zurückzustellen; dokumentiere die kompensierende Kontrolle in deinem Ticket.

Duplikat und Unterbefund. Diese setzt Plexicus, nicht du. Duplikate erklärt der Abschnitt Erneute Erkennung weiter unten, Unterbefunde die nächste Lektion.

Ein Review anfordern

Wenn der Status eines Befunds Ready to Fix ist, sieht ein Benutzer mit der Rolle Developer im Detailpanel Request review. Damit wird eine Benachrichtigung Review Request gesendet, und Reviewer finden diese unter Notifications Review Requests , erreichbar über die Glocke im Header.

Erneute Erkennung

Ein neuer Befund im selben Repository, in derselben Datei und Zeile, mit derselben CVE oder demselben Befundtyp, wird als Duplikat des früheren markiert, und der verbleibende Befund behält den höheren Schweregrad der beiden. Je nach Konfiguration deiner Organisation kann ein späterer Scan, der einen Befund mit Fixed oder Issued erneut erkennt, ihn wieder öffnen: Der Befund durchläuft die Analyse erneut und wird als wieder geöffnet erfasst.

Re-Scan unter Assets Repo Scan löscht die Befunde eines Repositorys samt ihren Status (Modul 2); nutze Relaunch scan im Activity Center, um sie zu behalten. Von Menschen gesetzte False-Positive-Markierungen werden gespeichert und erneut angewendet, wenn derselbe unveränderte Code gescannt wird.

Wenn deine Rolle den Audit-Trail sehen darf, listet der Abschnitt Activity des Befunds seinen Verlauf auf, den neuesten Eintrag zuerst: Statusänderungen, erzeugte, erstellte oder aktualisierte Behebungen, Sammelanfragen zur Behebung und Exporte, jeweils Pipeline oder User zugeordnet.

Finden, was zählt: Chips, Abfrageleiste, Filter, Views und der KI-Filter

Niemand liest jeden Befund. Die Toolbar bietet dir fünf Wege, die richtigen nach vorn zu holen.

Die Abfrageleiste und die Triage-Chips

Die Abfrageleiste durchsucht Befundtitel, CVEs, Pakete und Dateien. Daneben setzen die Triage-Chips mit einem Klick einen Filter, jeder mit einer live aktualisierten Anzahl: Critical, High, Medium, Reachable, EPSS ≥ 0.5, Vulnerability und New 7d. Kombinierst du Critical, High und Reachable, siehst du schnell die echte, dringende Arbeit. New 7d zeigt, was in den letzten sieben Tagen dazugekommen ist. Die Chips Reachable, EPSS, Vulnerability und New 7d fügen ihre Bedingung dem bereits aktiven Filter hinzu, sie grenzen die aktuelle Ansicht also ein, statt sie zu ersetzen.

Die Schweregrad-Chips filtern nach Severity (scanner); um nach dem KI-validierten Wert zu filtern, nutze Severity unter All filters.

Gruppierte Filter

All filters öffnet das Modal Filters, in dem die Felder nach der Frage gruppiert sind, die sie beantworten:

• What to look at first: Severity, Severity (scanner), Priority, Finding confidence, Class und Finding status
• Real risk: Reachable, EPSS, CVSS v3, CVSS v4 und Occurrences
• Weakness type: CWE, CVE, OWASP Top 10, Type und Category
• Compliance: Regulation, Control und Control category, beschränkt auf die Regulierungen, die deine Organisation aktiviert hat
• Where it lives: Repository, File, Language und ähnliche Felder zum Fundort
• Dependencies: Library und Library version
• Scanner: Tool, Rule und Provider
• Team & flow: Assigned to, Tags, Remediation type und Fixing effort
• Container registry: Felder zu Images, nur im Tab Registry sichtbar

Jeder Wert lässt sich ein- oder ausschließen. Klick in der Abfrageleiste bei einem gesetzten Filter auf den Feldnamen, um seinen Operator zwischen is und is not oder zwischen in und not in umzuschalten. Der Button zum Anwenden heißt „View N findings“, und seine Zahl aktualisiert sich, während du anpasst. So wendest du nie einen Filter blind an.

Gespeicherte Views und geteilte Links

Sobald ein Filter passt, speichere ihn: Findings Views Save view , gib ihm einen Namen wie „Tägliche Triage“ und klick auf Save. Eine gespeicherte View wendest du später mit einem Klick an. Die URL enthält immer den aktuellen Filter, daher teilst du mit Copy link genau diese Ansicht mit jemandem aus deinem Team.

Der KI-Filter in natürlicher Sprache

Je nach deinem Plan öffnet das Zauberstab-Symbol in der Abfrageleiste „Describe what you want to see“. Gib eine Anfrage ein wie „critical injection findings in the payments repo from the last week“ und klick auf Build filter. Plexicus macht aus dem Satz einen strukturierten Filter. Jede Anfrage verbraucht eine KI-Filterumwandlung. Für diese Umwandlungen gibt es ein eigenes monatliches Kontingent, getrennt vom KI-Nutzungskontingent, das Fixes und die False-Positive-Analyse verbrauchen. Prüfe den erzeugten Filter, bevor du auf Basis der Ergebnisse handelst, und speichere ihn als View, um ihn wiederzuverwenden.

Was standardmäßig ausgeblendet ist und warum

Die Standardliste blendet fünf Arten von Befunden aus:

• False Positives, weil sie als nicht echt eingestuft sind
• Duplikate, weil der verbleibende Befund sie bereits repräsentiert
• Unterbefunde: Abhängigkeitsbefunde für dieselbe Bibliothek, Version und CVE an derselben Stelle werden unter einem Hauptbefund gruppiert, und wer den Hauptbefund behebt, behebt sie mit. Die Detailansicht eines Unterbefunds zeigt Go to Parent Finding.
• Gelöschte Befunde
• Befunde, die noch angereichert werden, weil ihre Priorität und ihr KI-Urteil noch nicht feststehen

Nicht erreichbare Befunde werden nie standardmäßig ausgeblendet. Die Erreichbarkeit senkt ihre Priorität, aber ein statisches Urteil ist Evidenz, kein Beweis für Sicherheit, deshalb bleibt der Befund sichtbar. Wenn du sie aus einer bestimmten View heraushalten willst, filtere selbst nach Reachable.

Befunde bearbeiten: Zuständigkeit, Tickets, Behebung, Berichte und Exporte

Triage zahlt sich erst aus, wenn jeder relevante Befund am Ende eine zuständige Person und einen nächsten Schritt hat.

Zuständigkeit

Der Issue Owner jedes Code-Befunds stammt aus dem Blame deines SCM für die betroffene Datei. Mit dem Filter „Assigned to“ baust du eine Queue für einen einzelnen Entwickler auf oder prüfst, wie ausgelastet eine Person ist.

Um Arbeit ausdrücklich an Entwickler zu übergeben, wähle Befunde aus und nutze Send to Dev Team. Das gilt für Befunde, die bereits eine erzeugte Behebung haben: Sie werden den Benutzern mit der Rolle Developer zugewiesen, wechseln zu Ready to Fix, und es wird festgehalten, wer das Review angefordert hat. Benutzer mit der Rolle Developer sehen nur die Befunde, die ihnen zugewiesen sind.

Sammelaktionen und Rollen

Sammelaktionen brauchen mindestens zwei ausgewählte Zeilen, und was du siehst, hängt von deiner Rolle ab:

Rolle	Sammelaktionen
Admin	Remediate, Send to Dev Team, Create Pull Request
Cyberoper (Security-Operator)	Remediate, Send to Dev Team
Developer	Create Pull Request, nur aktiv, wenn die Auswahl einen Befund mit Ready to Fix enthält

Tickets

Im Kopf des Detailpanels bietet Create Ticket die aktiven Ticketing-Integrationen deiner Organisation an: Jira öffnet ein Ticketformular, ServiceNow legt einen Incident an, und Webhook sendet den Befund an deinen konfigurierten Issue-Webhook. Ist nichts konfiguriert, verlinkt das Menü auf die Seite der Ticketing-Integrationen. Modul 9 behandelt die Einrichtung.

Die Behebung starten

Jeder Befund hat einen Behebungstyp. Pull request steht für eine Codeänderung; der Button heißt dann Create AI Remediation. Issue wird genutzt, wenn es keine Quellcodezeile zu ändern gibt, bei bösartigen Artefakten und bei Anbietern ohne Pull Requests; der Button heißt dann Create Issue. Der Link „Open in“ im Fußbereich, gefolgt vom Namen deines Anbieters und der Zeilennummer, springt direkt zur Datei in deinem SCM.

Cloud- und SCM-Befunde haben keinen Button zur Behebung, weil es keine Datei in einem Repository zu ändern gibt. Ein Registry-Befund bietet Remediate in repo an, sobald sein Image mit einem Quell-Repository verknüpft ist.

Für mehrere Befunde auf einmal markierst du sie und wählst Remediate. Plexicus gruppiert sie nach Repository, und du entscheidest, ob du Automatically create pull requests nutzt und welchen Pull-Request-Modus du verwendest (Single PR oder One PR per remediation, der Standard). Modul 7 erklärt beide Modi und das Panel Bulk remediation status. KI-Behebungen werden auf dein KI-Nutzungskontingent angerechnet.

In beiden Fällen bereitet Plexicus eine prüfbare Änderung vor und pusht nie in die Produktion; dein Team behält die Kontrolle über den Merge. Modul 7 behandelt die Behebung im Detail.

Berichte und Exporte

Du brauchst	Nutze	Was du bekommst
Einen teilbaren Bericht der aktuellen Ansicht	Download, dann PDF	Wird im Hintergrund erzeugt; ein Toast meldet „We’ll email you when it’s ready“, danach folgt eine Benachrichtigung Report Ready
Maschinenlesbare Befunde	Download, dann JSON	Eine SARIF-2.1.0-Datei (findings.json) mit dem aktuellen Tab und den aktuellen Filtern, sofort heruntergeladen. Standardmäßig enthält sie nur Befunde im Status AI-Analysed (Modul 8).
Einen einzelnen Befund für ein Ticket oder ein Review	Download report im Detailpanel	Genau diesen Befund als SARIF-Dokument
Dein Repository-Inventar	Download unter Assets, Repo Scan	repositories.csv

Beide Listenexporte berücksichtigen den aktiven Tab und die Filter. JSON-Exporte werden im Audit-Trail erfasst. Wie du Befunde über die REST API liest, behandelt Modul 9.

Fortschritt auf dem Dashboard messen

Modul 2 hat die Tabs und Filter des Dashboards vorgestellt; diese Lektion behandelt die Widgets, die den Fortschritt der Triage verfolgen. Triage ist eine tägliche Gewohnheit, und Dashboard zeigt dir, ob sie wirkt.

Was die Summen zählen

Die Summen im Dashboard spiegeln offene Arbeit wider. Sie schließen Duplikate, Unterbefunde, False Positives, gelöschte Befunde und bereits als Fixed markierte Befunde aus. Hardening-Befunde werden getrennt von den Schwachstellenzahlen geführt. Deshalb sinken die Zahlen nach einer guten Triage-Woche: Sowohl das Markieren von False Positives als auch das Mergen von Fixes nimmt Befunde aus der Zahl der offenen heraus.

Die Widgets, die beantworten, ob ihr besser werdet

Widget	Tab	Was es zeigt
Risk Posture Score	CISO	Ein Score von 0–100, bei dem ein höherer Wert schlechter ist, berechnet aus offenen Befunden, gewichtet nach Schweregrad, wobei erreichbare Befunde stärker zählen. Er zeigt eine Linie für den Risikoappetit, einen Trend und einen Hinweis wie „Fix N findings to reach appetite“. Die Linie für den Risikoappetit ist vorerst fest und lässt sich nicht konfigurieren.
New vs Fixed	CISO	Pro Tag erstellte Befunde im Vergleich zu Befunden, die Ready to Fix, Fix Submitted, Issued oder Fixed erreicht haben, datiert nach ihrer Behebung
Top Risky Repositories	CISO	Repositories, sortiert nach einem Risiko-Score aus den Schweregraden und EPSS-Werten ihrer Befunde, mit einem Trendpfeil. Der Tooltip zeigt den Score und die Zahl der Critical- und High-Befunde. Es ist eine aktuelle Momentaufnahme: Der Repository-Filter greift, der Zeitraum nicht.
MTTR / Remediation Velocity	DevSecOps	Zwei Linien in Tagen: Time to attempt, vom Datum eines Befunds bis zum Start einer Behebung, und Time to fix, von dieser Behebung bis zu ihrem Abschluss
Aging Buckets	DevSecOps	Offene Befunde nach Schweregrad in vier Altersgruppen: unter 7 Tagen, 7–30 Tage, 30–90 Tage und 90 Tage oder mehr
Reachability Split	DevSecOps	Befunde nach Schweregrad, aufgeteilt in Reachable, Unreachable und Unknown

Weitere Widgets sind Total Findings, Supply Chain, Internet exposure, Scanner Coverage und die OWASP-Ansichten. In Total Findings zählt Prioritized Vulnerabilities die offenen Befunde mit einer Priorität von 80 oder mehr.

MTTR lesen

Die beiden MTTR-Linien weisen auf unterschiedliche Engpässe hin. Eine lange Time to attempt bedeutet, dass Befunde warten, bevor jemand mit einem Fix beginnt. Das ist ein Problem der Triage oder der Zuständigkeit. Eine lange Time to fix bedeutet, dass Behebungen gestartet wurden, aber lange bis zum Abschluss brauchen; vergleiche sie mit Time to attempt, um zu sehen, ob die Arbeit vor oder nach dem Start einer Behebung stockt.

New vs Fixed vergleicht Neuzugänge mit Befunden, die eine Behebung erhalten haben. Liegt New wochenlang über Fixed, hält die Behebung nicht mit den neuen Befunden Schritt.

Plexicus hat kein Tracking für SLAs oder Fälligkeitsdaten; nutze Aging Buckets und MTTR, um zu sehen, wie lange Befunde offen bleiben.

Das Wichtigste in Kürze

• Befunde liegen in fünf Tabs (Repo, SCM, Cloud, Registry und App Pentest), die sich eine Tabelle, ein Filtersystem und eine Detailansicht teilen.
• Der Schweregrad sagt, wie schlimm ein Befund sein könnte; der Prioritäts-Score von 0–100 sagt, wie dringend er hier ist, angepasst an Ausnutzbarkeit, Erreichbarkeit, Konfidenz und Exposition.
• Die Status reichen von AI-Analysed bis Fixed. False Positive und Mitigated Externally sind Flags, und eine menschliche False-Positive-Markierung lässt sich rückgängig machen.
• False Positives, Duplikate, Unterbefunde, gelöschte Befunde und Befunde, die noch angereichert werden, sind standardmäßig ausgeblendet. Nicht erreichbare Befunde werden nur niedriger priorisiert.
• Speichere deine besten Filter als Views, teile sie mit Copy link und gib jedem relevanten Befund eine zuständige Person, ein Ticket oder einen prüfbaren Fix.
• Die Summen im Dashboard zählen nur offene Arbeit. Verfolge deinen Fortschritt mit New vs Fixed, MTTR, Aging Buckets und Risk Posture Score.