Scan-Engines und Abdeckung

Plexicus-Engines und was sie abdecken

Plexicus arbeitet nach dem Prinzip Proof-Driven AppSec: AI Swarm Pentest validiert, was tatsächlich ausnutzbar ist, Deep Code Analysis erklärt, was ein Befund betrifft, und Remediation bereitet einen Fix vor, den dein Team prüft und mergt. Die Scan-Engines speisen diesen Kreislauf. Sie geben dir eine breite, wiederholbare Abdeckung deines Codes, deiner Abhängigkeiten, deiner Konfiguration und deiner Lieferkette. Behandle einen Scanner-Treffer als Kandidaten, nicht als Nachweis: Ohne reproduzierbaren Nachweis kein verifizierter Befund.

Jede Plexicus-Engine ist ein verwaltetes Bundle: eine Fähigkeit, die du als Einheit ein- oder ausschaltest und die mehrere zugrunde liegende Scanner ausführen kann. Jeder Befund hält im Feld Tool fest, welche Engine ihn erzeugt hat, zum Beispiel plexicus-sast oder plexicus-iac.

Der Engine-Katalog

Engine	Wonach sie sucht	Typisches Beispiel
Plexicus SAST (`plexicus-sast`)	Schwachstellen im Code wie Injection-Lücken und unsichere Muster, mit Datenflussverfolgung	Ein Login-Handler, der den Benutzernamen per String-Verkettung in eine SQL-Abfrage einbaut
Plexicus SCA (`plexicus-sca`)	Verwundbare Open-Source-Abhängigkeiten in den gängigen Paketmanagern, abgeglichen mit CVE-Quellen wie der NVD und der GitHub Security Advisory Database	Ein veralteter XML-Parser mit veröffentlichter CVE in deinem Lockfile
Plexicus Secrets (`plexicus-secrets`)	Hartcodierte Zugangsdaten, API-Keys und Tokens im Arbeitsverzeichnis und in der gesamten Git-Historie, mit Live-Prüfung beim ausstellenden Dienst	Ein Cloud-Access-Key, letztes Jahr committet, später gelöscht und noch immer in der Historie
Plexicus IaC (`plexicus-iac`)	Richtlinienverstöße in Terraform, CloudFormation, Kubernetes, Helm, Ansible und ARM-Templates	Ein Storage-Bucket, der mit öffentlichem Lesezugriff deklariert ist
Plexicus CI/CD (`plexicus-cicd`)	Fehlkonfigurationen, unsichere Berechtigungen und offengelegte Zugangsdaten in Pipeline-Definitionen wie GitHub Actions, GitLab CI und Azure Pipelines	Ein Workflow, der seinem Token Schreibzugriff auf alles gewährt
Plexicus Container (`plexicus-container`)	Fehlkonfigurationen, unsichere Basis-Images und bekannte Schwachstellen in den Dockerfiles und Container-Artefakten des Repositorys	Ein Dockerfile, das auf einem veralteten Basis-Image mit bekannten CVEs aufbaut
Plexicus License (`plexicus-license`)	Copyleft-, proprietäre oder unbekannte Lizenzen in den Abhängigkeiten	Eine Copyleft-Bibliothek in einem Produkt, das du vertreibst
Plexicus SBOM, CBOM und AIBOM	Inventare statt Befunde mit Schweregrad: Softwarekomponenten (CycloneDX oder SPDX), kryptografische Assets samt Quantum Readiness sowie KI-Modelle, Datensätze und Model Cards	Ein RSA-Schlüsselpaar, das die CBOM als quantenanfällig markiert
Plexicus SCM (`plexicus-scm`)	Sicherheitslage der Lieferkette und SLSA-Praktiken: signierte Commits, Artefakt-Provenienz, Build-Härtung	Ein Default-Branch, der unsignierte Commits akzeptiert

Sofern für deine Organisation aktiviert, ergänzen zwei weitere Engines die Abdeckung über das Repository hinaus: Plexicus Registry scannt Images in angebundenen Container-Registries, und Plexicus Cloud prüft angebundene Cloud-Konten auf Fehlkonfigurationen und zu weit gefasste IAM-Richtlinien. Beide speisen dasselbe Befundmodell (Lektion 5).

Zwei weitere von Plexicus verwaltete Karten gehören zur Kategorie SAST: Plexicus AI Scan, eine experimentelle KI-gestützte Engine, die Plexicus jeweils für einzelne Organisationen freischaltet (Modul 5), und GitHub SAST, das Code-Scanning-Alerts von GitHub übernimmt. Außerdem enthält die Kategorie die Karte SARIF Import und die Karten der kommerziellen Connectors (Lektion 3). AI Swarm Pentest ist keine Repository-Engine; er erscheint als AI Pentest im Bereich Pentest (Modul 6).

Die Verfügbarkeit hängt von deinem Plan ab

SAST, SCA, Secrets und IaC sind nicht an den Plan gebunden. Andere Engines wie Container, CI/CD, License, SCM, Registry, Cloud und AI Scan hängen von deinem Plan ab. Enthält dein Plan eine Engine nicht, öffnet ihre Karte einen Upgrade-Hinweis, statt sie einzuschalten, und das Backend setzt dieselbe Regel durch. Für planabhängige Engines kann ein Admin unter Settings Billing einen Planwechsel anfragen (Modul 10). AI Scan ist die Ausnahme: Plexicus schaltet sie auf Anfrage frei (Modul 5).

Die passende Auswahl für deine Organisation und deine Repositories

Orientiere dich daran, was deine Repositories enthalten. Manche Engines lassen sich pro Repository festlegen, andere gelten für die gesamte Organisation (Lektion 2).

Ein Python- oder Node.js-Service: SAST, SCA und Secrets. Nimm CBOM dazu, wenn der Code mit Kryptografie arbeitet.
Terraform-, CloudFormation- oder Helm-Definitionen: zusätzlich IaC.
Pipeline-Definitionen: zusätzlich CI/CD.
Dockerfiles: Container, dazu License für Lizenzrisiken. Beide gelten organisationsweit.
Sicherheitslage der Lieferkette: SCM, ebenfalls organisationsweit.
Inventar-Nachweise: SBOM, CBOM und AIBOM. Modul 8 zeigt, wie sie in die XBOM einfließen.

Scans konfigurieren

Die Organisation legt die Standardeinstellungen der Engines fest, und jedes Repository kann einige davon überschreiben. Stell zuerst die Standards richtig ein und überschreibe sie dann nur dort, wo sich ein Repository wirklich unterscheidet.

Standards der Organisation auf der Seite Connectors

Die Seite Connectors listet die Scan-Engines und Tool-Connectors nach Kategorien auf, von SAST, SCA und Secrets / PII Scan bis zu CI/CD Posture, License und SCM Security. Du erreichst sie, indem du /connector auf deinem Plexicus-Host öffnest; leere XBOM-Inventare verlinken außerdem mit Go to Connectors dorthin. Quellcodeverwaltung, Registries, Cloud-Konten und Ticketing bindest du separat unter Settings Integrations an.

Öffne eine Engine-Karte, um ihr Konfigurationspanel zu sehen:

Tab	Was er bewirkt
Tool	Der Schalter Enable schaltet die Engine für die gesamte Organisation ein oder aus. Nur auf Organisationsebene.
Severity	Legt fest, welche Schweregrade Plexicus für diese Engine behält. Standard ist Medium, High & Critical.
Advanced Options	Engine-spezifische Parameter, nur bei Engines, die welche haben. Klick auf Save, um Änderungen zu übernehmen.

Änderungen gelten für künftige Scans.

Überschreibungen pro Repository

Um die Engines für ein einzelnes Repository zu ändern, öffne Assets Repo Scan Configure (das Zahnradsymbol in der Zeile des Repositorys). Das Panel zeigt nur die Kategorien, die du pro Repository festlegen kannst, etwa SAST, SCA, Secrets, IaC, CI/CD und die BOM-Engines (Bill of Materials). Container, License und SCM entscheidest du organisationsweit auf der Seite Connectors.

Für ein Repository ohne eigene Auswahl öffnet sich das Panel mit der aktuellen Auswahl deiner Organisation und listet unter „Enabled for this repository“ auf, was aktiv ist. Beim Speichern wird diese Liste zu einer expliziten Kopie für das Repository, und spätere Änderungen an den Standards der Organisation erreichen es nicht mehr. Die Konsole hat keinen Button zum Zurücksetzen; zur Auswahl der Organisation kehrst du über die REST API zurück (Modul 9).

Mit dem Schalter auf einer Engine-Karte aktivierst oder deaktivierst du sie für dieses Repository. Eine Toast-Meldung bestätigt das, zum Beispiel „Plexicus IaC tool enabled for this repository“.
Connectors, die Zugangsdaten brauchen, öffnen zuerst ihre Konfiguration; der Schalter bleibt erst eingeschaltet, wenn der Connector konfiguriert ist.
In der Konsole zeigt das Detailfenster der Engine hier nur die Tabs Severity und Advanced Options, und Änderungen dort gelten für die gesamte Organisation. Über die REST API lassen sich für eine einzelne Engine auch Parameter pro Repository und ein Schweregradfilter setzen.

Wenn du Repositories unter Manage Repositories hinzufügst, scannt Launch jedes davon mit der Standard-Engine-Auswahl deiner Organisation. Advanced Options öffnet stattdessen „Configure Tools for Repository“, wo du vor dem Start für jedes Repository die Engines auswählst.

Der Schweregradfilter und Ausschlusspfade

Der Tab Severity legt fest, welche Schweregrade Plexicus für diese Engine behält. Ergebnisse außerhalb der Auswahl werden nach dem Scan verworfen und nie zu Befunden, du kannst sie also später nicht sichtbar machen. Der Standard Medium, High & Critical bedeutet, dass Low- und Informational-Ergebnisse bei keiner Engine gemeldet werden, solange du sie nicht hinzufügst. Um Low-Ergebnisse zu sehen, füge Low hinzu und starte den Scan erneut. BOM-Engines erzeugen Inventare und ignorieren diese Einstellung.

Für Ausschlusspfade gibt es in der Konsole kein Feld. Sie sind Bundle-Parameter, die du über die Endpunkte der REST API für die Tool-Konfiguration setzt (Modul 9). Die meisten Code-Engines unterstützen sie, nicht aber Secrets, SCM, AIBOM und CBOM.

Erweiterte Optionen

Einige engine-spezifische Optionen, die du nutzen wirst:

SAST: baseline_commit meldet nur Probleme, die seit einem bestimmten Commit neu sind; exclude_rule schaltet eine Regel ab, die zu viel Rauschen erzeugt.
SCA: fail_on legt das Gating über den Exit-Code fest; only_fixed behält nur CVEs, für die es einen Fix gibt.
Secrets: redact blendet Secret-Werte in der Ausgabe aus; include_detectors und exclude_detectors wählen die Detektoren.
IaC: skip_check und skip_framework lassen einzelne Checks oder ganze Frameworks weg; soft_fail meldet Ergebnisse, ohne den Lauf scheitern zu lassen. Die Karte Plexicus CI/CD hat keinen Tab Advanced Options.

Der Schalter Autonomous Scan für Pull-Request-Scans befindet sich unter Settings Platform (Lektion 4).

Andere Ergebnisse einbinden

Viele Teams betreiben bereits andere Scanner oder erhalten Berichte von externen Testern. Du musst dich nicht zwischen ihnen und Plexicus entscheiden. Importiere ihre Ergebnisse, und sie landen in derselben Queue und durchlaufen dieselbe Anreicherung und dieselbe Deduplizierung wie native Befunde.

Upload Scan

Der direkteste Weg ist Findings Repo Upload Scan . Den Button gibt es nur im Tab Repo.

Select repository: das Plexicus-Repository, zu dem die Ergebnisse gehören.
Select tool: generisches SARIF oder das Exportformat eines der unterstützten kommerziellen Tools für SAST, SCA oder dynamisches Testen; die Liste zeigt, welche.
Select file: der Bericht, den dein Tool erzeugt hat.
Klick auf Upload.

Wird der Upload angenommen, siehst du „Data uploaded successfully“. Danach werden die Ergebnisse wie bei jedem anderen Scan verarbeitet.

SARIF-2.1.0-Import

Plexicus akzeptiert SARIF 2.1.0 von jedem kompatiblen Analyzer, entweder über Upload Scan oder über die Karte SARIF Import in der Kategorie SAST auf der Seite Connectors. Der Schweregrad wird in dieser Reihenfolge bestimmt:

SARIF-Daten	Plexicus-Schweregrad
`security-severity` der Regel ab 9,0	Critical
`security-severity` ab 7,0, unter 9,0	High
`security-severity` ab 4,0, unter 7,0	Medium
`security-severity` unter 4,0	Low
Kein `security-severity`: Ergebnis-Level `error`	High
Ergebnis-Level `warning`	Medium
Ergebnis-Level `note` oder `none`	Low
Auch kein Ergebnis-Level	Das Standard-Level der Regel, auf dieselbe Weise zugeordnet; Low, wenn die Regel keines hat

CWE-IDs werden aus Tags wie external/cwe/cwe-89 gelesen und steuern später die OWASP-Zuordnung (Lektion 5). Plexicus entfernt aus jeder Ortsangabe ein file://-Präfix und einen führenden Schrägstrich. Erzeuge SARIF also mit Pfaden relativ zum Stammverzeichnis des Repositorys. Andernfalls passen Datei und Zeile nicht zu deinem Code.

Connectors für kommerzielle Scanner

Auf der Seite Connectors stehen auch kommerzielle Scanner. Manche holen die Ergebnisse über die API des Anbieters, sobald du die Zugangsdaten des Anbieters auf der Karte einträgst. Andere nehmen eine hochgeladene Exportdatei an, genau wie Upload Scan. Die Karte GitHub SAST übernimmt Code-Scanning-Alerts von GitHub. Ergebnisse dynamischer Tests aus einem Drittanbieter-Tool sind von AI Swarm Pentest getrennt. Manche Connectors gibt es nur in bestimmten Plänen; wende dich an Plexicus, um einen freischalten zu lassen.

Uploads aus CI

Die Plexicus API bietet die Operation Upload Scan Results, die extern erzeugte Ergebnisse für ein Repository übernimmt. Eine Pipeline kann sie nach ihren eigenen Scannern mit einem persönlichen API-Token aufrufen; Tokens und die REST API behandelt Modul 9.

Scans aus CI/CD ausführen

Plexalyzer ist der Scanner von Plexicus. In CI läuft er in deiner Pipeline und sendet die Ergebnisse an deine Plexicus-Organisation, wo sie wie bei jedem anderen Scan im Dashboard und unter Findings erscheinen. Du hast drei Möglichkeiten, ihn einzurichten.

Plexicus startet nicht von sich aus bei jedem Push einen Scan. Neue Scans entstehen durch deine CI-Pipeline (einschließlich Pull-Request-Scans), durch das Hinzufügen eines Repositorys, durch Relaunch scan im Activity Center oder durch Re-Scan. Damit ein Repository gescannt wird, wenn sich sein Code ändert, richte die Pipeline dafür ein.

Das Plexalyzer-Token

Jeder Plexalyzer-Lauf authentifiziert sich mit dem Plexalyzer-Token der Organisation, auch CI/CD-Scanner-Token genannt. Admins verwalten es unter Settings Plexalyzer Token . In manchen Releases erscheint dasselbe Token als Abschnitt CI/CD-Scanner-Token unter Settings API Tokens . Du kannst ein Token mit einem Token Name und einem optionalen Expired Date erstellen, es kopieren und löschen. Das mit Default gekennzeichnete Token lässt sich nicht löschen, solange andere Tokens existieren. Löschst du ein Token, funktioniert keine Pipeline mehr, die es noch verwendet.

Dieses Token gehört der Organisation und wird nur vom Plexalyzer-Scanner verwendet, nicht für allgemeine API-Aufrufe. Persönliche API-Tokens für Skripte und den MCP-Server sowie das CLI-Token sind etwas anderes (Modul 9).

Setup Pipeline über Assets

Der schnellste Weg beginnt unter Assets Repo Scan . Die Spalte Pipeline bietet Setup Pipeline für Repositories auf GitHub, GitLab, Gitea, Forgejo und Bitbucket Cloud an; andere Anbieter zeigen Not Available.

Klick auf Setup Pipeline und bestätige.
Plexicus öffnet in deinem Repository einen Pull Request, der den Plexalyzer-Workflow hinzufügt. Auf GitHub ist das .github/workflows/plexalyzer-scan.yml, und Plexicus speichert das Token als Repository-Secret PLEXALYZER_TOKEN.
Die Spalte zeigt Pipeline Pending, bis der Pull Request angenommen ist, danach Pipeline Configured.

In deiner CI läuft nichts, bis jemand aus deinem Team diesen Pull Request geprüft und gemergt hat. Die Kontrolle über den Merge bleibt bei deinem Team.

Die Plexicus GitHub Action von Hand

Wenn du den Workflow selbst schreibst, nutze die offizielle Action plexicus/plexicus-action (auf der Plexicus-Website als Plexalyzer Action aufgeführt). Sie führt den Scanner in deinem Workflow aus und kann Befunde im Pull Request melden.

Kopiere das Plexalyzer-Token aus Plexicus.
Leg in GitHub unter Secrets and variables, Actions des Repositorys ein Repository-Secret namens PLEXALYZER_TOKEN an.
Füge die Repository-Variable für deine Plexicus-Repository-ID hinzu, wie in der README der Action beschrieben.
Übergib das Secret an den Input plexalyzer-token, zusammen mit repo-id, repo-name, branch, url, pr-id und workspace-path.

Wenn deine Organisation Autonomous Scan unter Settings Platform einschaltet, postet ein abgeschlossener Pull-Request-Scan aus der Pipeline einen Kommentar „Analysis Results“ im Pull Request (oder „No issues found“), sofern dein Anbieter für die Quellcodeverwaltung Kommentare in Pull Requests unterstützt. Plexicus erzeugt dann KI-Fixes für diese Befunde und öffnet einen gemeinsamen Pull Request mit dem Titel „Multiple security fixes“ aus einem neuen Branch mit dem Präfix Plexicus-AI-Remediation-. Plexicus mergt nie selbst; dein Team prüft ihn wie jeden anderen Pull Request.

Jenkins

Die Jenkins-Integration führt das Docker-Image der Plexalyzer CLI aus, daher braucht der Build-Agent Docker. Leg das Token als Jenkins-Credential vom Typ Secret text mit der exakten ID plexalyzer-token an. Kopiere Jenkinsfile, .plexalyzer/jenkins-plexalyzer-cli.groovy und .plexalyzer/custom_config.yml aus dem Repository plexicus/jenkins-cli-pipeline und erstelle dann einen Pipeline-Job, der Pipeline script from SCM verwendet.

Wähle die Engines in custom_config.yml über Bundle-Namen aus:

# .plexalyzer/custom_config.yml
excluded_tools:
  - plexicus-iac   # kein Infrastruktur-Code in diesem Repository
  - plexicus-cicd

Mit included_tools beschränkst du einen Scan stattdessen auf eine feste Auswahl. Nützliche Build-Parameter:

Parameter	Zweck
`PROJECT_NAME`, `BRANCH_NAME`	Repository-Name und Branch-Bezeichnung, die in Plexicus angezeigt werden
`REPOSITORY_ID`	ID eines bestehenden Repositorys; beim ersten Scan leer lassen
`OUTPUT_FORMAT`	`pretty`, `json` oder `sarif`; JSON und SARIF werden zusätzlich als Build-Artefakte archiviert
`ONLY_GIT_CHANGES`	Nur die im letzten Commit geänderten Dateien scannen; erfordert eine Checkout-Tiefe von mindestens 2
`PLEXICUS_URL`	Deine Plexicus-Basis-URL, für selbst gehostete Deployments

Exit-Code 0 bedeutet keine Befunde, Exit-Code 1, dass Befunde erkannt wurden. Beide markieren den Build als Success, sodass Befunde die Auslieferung standardmäßig nie blockieren. Exit-Code 500 ist ein schwerwiegender Fehler, etwa ein abgelehntes Token oder ein nicht erreichbares Backend. Damit der Build bei Befunden fehlschlägt, bearbeite handleExitCode() im Pipeline-Skript und lass case 1 das Build-Ergebnis auf FAILURE setzen.

Ein einheitliches Befundmodell

Egal, woher ein Ergebnis stammt (eine Plexicus-Engine, ein CI-Lauf, Upload Scan, ein Connector, eine Registry oder ein Cloud-Konto): Jedes landet in einem gemeinsamen Befundmodell. So kannst du über alle Quellen hinweg gleichzeitig filtern, priorisieren und berichten.

Normalisierung

Ein toolspezifischer Prozessor liest die Rohausgabe jedes Scanners (JSON, SARIF, CSV oder XML) und schreibt sie in das gemeinsame Schema: Tool, Regel-ID, Titel, Beschreibung, Datei, Zeile und Spalten, CWE sowie ein Schweregrad in fünf Stufen: Critical, High, Medium, Low und Informational. Das Activity Center zeigt das als „Processing results“ („Normalizing and ingesting findings“), dann Completed, dann „Enriched“ („AI analysis and prioritization applied“). Bei einem als Partial markierten Lauf sind einige Tools fehlgeschlagen. Seine Befunde sind echt, aber die Abdeckung ist unvollständig; scanne mit Relaunch scan im Activity Center erneut und behalte dabei deine Befunde (Modul 2).

Jeder Befund erhält außerdem einen Typ, der sich aus seiner Engine ableitet, etwa SAST, SCA, Secrets, License, Configuration oder Cryptography. Container-Befunde erhalten den Typ SCA, wenn sie eine CVE oder ein Paket enthalten, andernfalls Configuration. Als SARIF importierte Ergebnisse erhalten den Typ SAST.

Anreicherung

Feld	Was es ergänzt
CWE und OWASP	Befunde mit einer CWE werden mit einer kurzen Begründung einer Kategorie der OWASP Top 10 zugeordnet, zum Beispiel CWE-89 unter A03 Injection. Befunde werden außerdem den OWASP CI/CD Top 10 und deinen aktivierten Compliance-Frameworks zugeordnet.
CVE und EPSS	EPSS, die Wahrscheinlichkeit, dass eine CVE in freier Wildbahn ausgenutzt wird, wird nur bei Befunden mit CVE ausgefüllt. Alle anderen zeigen No data.
CVSS	Score und Vektor nach CVSS v3 und v4, verfügbar als Tabellenspalten.
Priorität und mehr	Ein Prioritäts-Score von 0 bis 100, die Programmiersprache und die Art der Behebung. Modul 4 erklärt Priorität und Erreichbarkeit.

SARIF 2.1.0 ist auch das Exportformat für Befunde; Modul 8 behandelt Exporte und ihren Inhalt.

Deduplizierung

Ein neuer Befund wird als Duplicate eines früheren Befunds im selben Repository eingestuft, wenn er in derselben Datei und Zeile liegt und entweder dieselbe CVE und CWE hat (Abhängigkeitsbefunde) oder denselben Befundtyp (Code-Befunde ohne CVE). Der verbleibende Befund übernimmt den höchsten Schweregrad und CVSS-Wert seiner Duplikate, sodass die Deduplizierung das Risiko nie unterschätzt.

Unterbefunde

Abhängigkeitsbefunde für dieselbe Bibliothek, Version und CVE an derselben Stelle werden unter einem Hauptbefund als Unterbefunde gruppiert. Die Detailansicht eines Unterbefunds zeigt Go to Parent Finding statt eines eigenen Buttons zur Behebung. Standardmäßig blendet die Befundliste Duplikate, Unterbefunde, False Positives, gelöschte Befunde und Befunde aus, die noch angereichert werden (Modul 4); die Summen im Dashboard behandelt Modul 2.

Registries und Cloud-Konten als ergänzende Quellen

Je nach deinem Plan und den für deine Organisation aktivierten Anbietern liefern Registries und Cloud-Konten ergänzende Abdeckung, die im selben Befundmodell landet. Container-Registries bindest du unter Settings Integrations Registry an: Docker Hub, JFrog Artifactory, Amazon ECR, Google GCR, Google GAR, Azure ACR, GitHub GHCR, GitLab Container Registry und Quay.io. Trag die Zugangsdaten im Tab Setup ein und klick auf Connect; Plexicus testet die Verbindung vor dem Speichern. Nutze im Tab List Discover images und danach Scan images. Anschließend synchronisiert Plexicus jede angebundene Registry einmal täglich neu, du brauchst diese Buttons also nur für eine sofortige Aktualisierung. Images mit dem Lifecycle Old erhalten einen Medium-Befund „Outdated registry image“. Verknüpfe ein Image mit Link to repo und einem Dockerfile-Pfad mit seiner Quelle; damit wird Remediate in repo verfügbar. Die Ergebnisse landen im Tab Registry unter Findings.

Cloud-Konten fügst du unter Settings Integrations Cloud Deployment hinzu; dort sind die unterstützten Cloud-Anbieter aufgeführt, etwa AWS, Azure und Google Cloud Platform. Speicherst du eines, entsteht ein Asset unter Assets Cloud Assessment ; Scan Now startet den Scan, und die Ergebnisse landen im Tab Cloud mit den Filtern Provider, Region und Resource. Cloud- und SCM-Befunde bieten nie eine KI-Behebung an, weil es keine Repository-Datei zum Patchen gibt.

Das Wichtigste in Kürze

Engines sind verwaltete Bundles. Leg die Standards der Organisation auf der Seite Connectors fest und überschreibe SAST, SCA, Secrets, IaC, CI/CD und die BOM-Engines mit Configure pro Repository; Container, License und SCM bleiben organisationsweit.
Das Speichern einer Auswahl pro Repository löst einen Re-Scan aus, der die Befunde dieses Repositorys löscht, und Änderungen an Severity und Advanced Options in der Konsole gelten für die gesamte Organisation.
Der Severity-Filter verwirft Ergebnisse nach dem Scan, daher werden Low- und Informational-Ergebnisse standardmäßig bei keiner Engine gemeldet; Code-Scans überspringen bereits gängige Test- und Doku-Pfade, außer bei Secrets.
Upload Scan, SARIF-2.1.0-Import und kommerzielle Connectors bringen externe Ergebnisse in dasselbe Modell, als Kandidaten, die weiterhin einen Nachweis brauchen.
In CI authentifiziert sich jeder Plexalyzer-Lauf mit dem Plexalyzer-Token der Organisation; Setup Pipeline öffnet einen Pull Request, den dein Team prüft, und Jenkins-Builds bestehen trotz Befunden, solange du handleExitCode() nicht änderst.
Jedes Ergebnis wird unabhängig von seiner Quelle normalisiert, mit CWE, OWASP, CVE, EPSS und CVSS angereichert, unter Beibehaltung des höchsten Schweregrads dedupliziert und zu Unterbefunden gruppiert.