Automatisierung, Integrationen und Entwickler-Tools

Plexicus Automation: Trigger, Schritte und das Flow-Modell

Plexicus Automation arbeitet neben dem Workflow Validieren → Verstehen → Beheben von Proof-Driven AppSec. Es wendet die wiederkehrenden Entscheidungen deines Teams („sofort fixen“, „dafür ein Ticket anlegen“, „erst den AppSec-Lead fragen“) auf jeden passenden Befund an. Du öffnest es über die linke Hauptseitenleiste. Die Seite heißt Automations, und die Pfade in diesem Modul beginnen dort, etwa Automations New automation .

Stell dir eine SQL-Injection mit dem Schweregrad Critical im Login-Handler deiner Billing-API vor. Ein Flow kann einen Pull Request mit der Behebung anfordern, auf die Freigabe deines AppSec-Leads warten, ein Jira-Issue anlegen und eine In-App-Benachrichtigung senden. Nichts wird von selbst gemergt; dein Team prüft den Pull Request.

Trigger → Entscheidung → Aktion → Protokoll

Jeder Flow besteht aus vier Teilen:

1. Trigger. Ein Ereignis startet einen Lauf. Jeder Flow hat genau einen Trigger.
2. Entscheidung. Bedingungsschritte leiten den Lauf nach Schweregrad, Befundtyp, Repository oder Webhook-Daten weiter. Außerdem hat jeder Schritt einen Erfolgspfad und einen Fehlerpfad.
3. Aktion. Aktionsschritte fordern eine Behebung an, legen ein Ticket an, benachrichtigen Personen oder rufen ein verbundenes System auf.
4. Protokoll. Läufe werden mit Logs pro Schritt gespeichert, Änderungen an Flows landen im Audit-Log (Modul 10), und Tickets werden in der Timeline des Befunds verknüpft.

Trigger

Trigger	Ein Lauf startet, wenn	Hinweise
New finding	Plexicus einen Befund erstellt	Optionale Filter: Severity, Finding type, Repository ID
Finding enriched	Plexicus einem bestehenden Befund Kontext hinzufügt	Dieselben optionalen Filter
Finding reopened	ein Scan einen Befund erneut erkennt, nachdem er behoben war	Läuft bei jedem erneuten Öffnen, sobald der vorherige Lauf beendet ist
Webhook	ein signierter Request die Ingress URL des Flows erreicht	Behandelt in Lektion 3
Schedule	ein Cron-Zeitplan auslöst	Cron mit 5 Feldern plus Zeitzone (standardmäßig UTC)
Manual	jemand den Lauf mit Run now startet	Erscheint in der Liste als „Manual only“

Um den Trigger festzulegen, wählst du auf dem Canvas den Knoten Trigger aus und bearbeitest sein Panel. Trigger ziehst du nicht aus der Palette. Öffne das Trigger-Panel nach dem Speichern erneut, um zu prüfen, ob deine Filter oder dein Zeitplan erhalten geblieben sind, und mach einen Testlauf des Flows, bevor ein Admin ihn aktiviert.

Für Flows, die auf Befund-Ereignisse reagieren, gelten zwei Regeln. Erstens läuft ein Flow pro Befund höchstens einmal automatisch. Die Ausnahme ist ein Flow mit dem Trigger Finding reopened: Er läuft bei jedem erneuten Öffnen, sofern sein vorheriger Lauf für diesen Befund beendet ist. Ein Flow mit New finding oder Finding enriched läuft beim erneuten Öffnen nicht noch einmal. Leg daher einen eigenen Flow mit Finding reopened an, um auf erneut geöffnete Befunde zu reagieren. Zweitens fasst Deduplicate by fingerprint Befunde, die denselben Secret-Fingerprint haben, im bereits aktiven Lauf zusammen. So führt ein geleakter API-Key zu einer Rotation statt zu fünf.

Schritte

Schritt	Was er tut	Pflichteinstellungen
Remediation	Fordert eine KI-Behebung an, etwa einen Pull Request zum Review (Modul 7)	Art der Behebung
Ticket	Legt ein Ticket bei einem Anbieter wie Jira an	Ticket-Anbieter (Projektschlüssel optional)
Notify	Erstellt eine In-App-Benachrichtigung	Benachrichtigungskanal, der als Titel dient; Nachricht optional
Wait for approval	Pausiert den Lauf, bis jemand freigibt oder ablehnt	Optionale Approver-Rolle und optionales Timeout in Sekunden
Condition (if)	Folgt der Kante „yes“, wenn die Bedingung zutrifft, sonst der Kante „no“	Bedingung
Condition (switch)	Nimmt den ersten passenden Fall oder die Fehlerkante, wenn keiner passt	Fälle
Connector	Ruft eine Fähigkeit einer registrierten Integration auf	Connector-Typ, Fähigkeit, Connector-Name

Fünf Schritte zur Secret-Rotation stecken hinter der Vorlage Secret rotation. Notify benachrichtigt nur in der App. Um ein anderes System zu erreichen, nutze einen Ticket-Schritt oder einen Connector-Schritt, der eine HTTP-API-Integration aufruft.

Bedingungen nutzen eingeschränkte JSON-Logik. Diese hier soll Befunde mit dem Schweregrad Critical erfassen:

{ "==": [{ "var": "finding.severity" }, "Critical"] }

Erlaubte Operatoren: ==, !=, >, <, >=, <=, and, or, not, in und var. Du kannst Felder des Befunds wie severity, type, status und repository_id prüfen und Webhook-Daten über trigger.payload.FIELD. Werte werden exakt verglichen, einschließlich Groß- und Kleinschreibung. Nutze lieber den visuellen Bedingungseditor, und mach einen Testlauf mit einem Befund, von dem du weißt, dass er Critical ist, bevor du dich auf eine von Hand geschriebene Bedingung verlässt.

Flows sicher erstellen

Zwischen einer Idee und einem aktiven Flow stehen bei Plexicus mehrere Schutzmechanismen: deaktivierte Entwürfe, Testläufe, eine Aktivierung nur durch Admins, Versionen und die Laufhistorie.

Drei Wege zum Start

Vorlagen. Automations Start from a template bietet fertige Flows:

• Auto-remediate + ticket: fordert bei einem neuen Befund eine KI-Behebung an, legt ein Jira-Ticket an und sendet eine In-App-Benachrichtigung, wenn ein Schritt fehlschlägt.
• Conditional remediation: Befunde mit High und Critical gehen in die automatisierte Behebung mit Pull Request, alles andere wird zu einem Jira-Ticket für die Triage.
• Secret rotation: rotiert ein geleaktes Secret, speichert es in HashiCorp Vault, öffnet einen Draft-PR, der den hartcodierten Wert durch eine Umgebungsvariable ersetzt, prüft den neuen Wert durch erneutes Auslesen, wartet auf die Freigabe eines Admins und überführt den PR dann aus dem Draft-Status. Jeder Fehler legt ein Jira-Ticket an.

Vom Prompt zum Flow. Automations New from prompt macht aus einer Beschreibung in natürlicher Sprache mit bis zu 4.000 Zeichen einen Entwurf. Dafür nutzt es das KI-Modell, das für deine Organisation konfiguriert ist. Zum Beispiel: „Wenn ein kritischer Befund erstellt wird, warte auf die Freigabe eines Admins und leg dann ein Jira-Ticket an.“ Der Entwurf listet unter This flow will contact: jedes externe System auf, das er erreichen wird, und gespeichert wird erst, wenn du auf Confirm and save draft klickst.

Visueller Editor. Automations New automation öffnet drei Bereiche: links die Schrittpalette (Triggers, Logic, Actions und Integrations), in der Mitte den Canvas und rechts den Inspector mit den Tabs Config, Last run I/O und Notes. Zieh einen Schritt auf den Canvas oder füge ihn per Doppelklick hinzu. Der Inspector markiert jeden Schritt als Configured oder Incomplete. Das aktuelle Release bringt Rückgängig und Wiederherstellen sowie einen Zeitplan-Builder mit Vorschau auf den nächsten Lauf.

Egal, wie du startest: Du bekommst einen deaktivierten Entwurf, der nichts tut, bis ein Admin ihn aktiviert. Plexicus validiert den Flow beim Speichern, und Probleme wie zwei Kanten, die aus einem Zweig zu unterschiedlichen Zielen führen, erscheinen unter This flow has validation errors.

Testläufe

Ein Testlauf geht den gesamten Flow durch und simuliert jeden Schritt, der ein externes System berühren würde. Jeder Schritt hält fest, was er getan hätte, zum Beispiel „Would create jira ticket in project SEC“, und Parameter, die nach Secrets aussehen, werden maskiert. Testläufe funktionieren mit Entwürfen, werden nicht auf die Ausführungslimits angerechnet und erscheinen in der Laufhistorie mit dem Badge Dry run. Gib in der oberen Leiste des Editors eine Finding ID ein und klick auf Dry run. Im aktuellen Release kannst du auch Flows mit Zeitplan oder Webhook ohne Finding ID testen.

Aktivierung und Versionen

Nur Admins der Organisation können Flows erstellen, bearbeiten, aktivieren oder löschen. Alle anderen haben Lesezugriff und können die Laufhistorie trotzdem einsehen.

Bei der Aktivierung wird jede Verbindung, die der Flow nutzt, erneut geprüft, einschließlich der Connector-Schritte und des Anbieters im Ticket-Schritt. Schlägt ein Test fehl, siehst du Activation failed mit dem betroffenen Connector. Je nach Plan kann die Zahl aktiver Flows und manueller Läufe begrenzt sein.

Wenn du einen aktiven Flow bearbeitest und auf Save new version klickst, entsteht die nächste Version. Bereits gestartete Läufe bleiben auf der Version, mit der sie begonnen haben, und ältere Versionen bleiben erhalten. Prüf nach dem Speichern die Spalte Status und aktiviere die neue Version, falls dort Inactive steht.

Laufhistorie, Status und Freigaben

Öffne Automations Edit Runs , um für jeden Lauf Automation, Finding, Status und Startzeit zu sehen. Klapp eine Zeile auf, um die Logs pro Schritt zu sehen, oder geh mit Replay einen Lauf Schritt für Schritt durch, samt Input und Output jedes Schritts.

Status	Bedeutung
Running	Schritte werden ausgeführt
Waiting	Pausiert bei einem Schritt Wait for approval
Completed	Der Flow hat ein Ende erreicht, über einen Erfolgspfad oder einen Fehlerpfad
Failed	Der Lauf wurde mit einem Fehler beendet oder lief länger als das Maximum von 30 Tagen
Cancelled	Der Lauf wurde gestoppt, bevor er fertig war

Wartende Läufe zeigen Approve, Reject und Cancel. Approve setzt den Lauf auf dem Erfolgspfad fort. Reject und ein Timeout folgen dem Fehlerpfad. Cancel verhält sich wie Reject: Der Lauf geht auf dem Fehlerpfad weiter. Das Timeout wird in Sekunden angegeben und beträgt standardmäßig 7 Tage (604.800 Sekunden). Nennt der Schritt eine Approver-Rolle, können nur Nutzer mit dieser Rolle freigeben oder ablehnen.

Ticketing und ausgehende Integrationen

Plexicus verbindet sich an zwei Stellen mit anderen Systemen: Unter Settings Integrations liegen die Ticketing-Connectors hinter dem Button Create Ticket an Befunden, und die Seite für Automation-Integrationen enthält die Systeme, die deine Flows nutzen.

Jira und ServiceNow verbinden

Öffne Settings Integrations Ticket Management . Dort findest du Jira, ServiceNow und Webhook.

Jira hat vier Tabs: Credentials, Stage Configuration, Test Connection und Create Ticket. Unter Credentials gibst du eine Email Address, ein API Token und die Server URL deiner Jira-Cloud-Instanz an, etwa company.atlassian.net.

ServiceNow fragt nach einem OAuth Token und deiner Instance URL, etwa https://dev12345.service-now.com. Plexicus legt Incidents im Status New mit der Kategorie Security an. Welche Connectors du aktivieren kannst, hängt von deinem Plan ab.

Beide Connectors haben zwei Stages, die du unter Stage Configuration ein- oder ausschaltest:

• Create Issue gilt für Tickets, die aus Befunden erstellt werden.
• Pull Request greift, wenn Plexicus einen Pull Request mit einer Behebung öffnet. Ein verknüpftes Ticket bekommt einen Kommentar mit dem PR-Link und wird als in Bearbeitung markiert. Ist noch kein Ticket verknüpft, legt Plexicus eines an.

Jede Stage hat ein Priority Mapping (standardmäßig ordnet Jira Critical der Priorität Highest zu und ServiceNow Critical dem Wert „1 - Critical“) und ein optionales Field Mapping, das Ticketfelder über Platzhalter wie %Finding.title% mit Befunddaten füllt. Die Stage bietet außerdem Filteroptionen; teste sie an einem Beispielbefund, bevor du dich auf sie verlässt. Führ nach dem Speichern der Zugangsdaten Test Connection aus.

Ein Ticket aus einem Befund erstellen

Auf der Detailseite eines Befunds listet das Dropdown Create Ticket jeden konfigurierten Anbieter. Jira öffnet ein Formular mit Service, Issue Type (Bug, Task, Story, Epic), Project Key und einem optionalen Priority Override. ServiceNow legt den Incident sofort mit den Mappings der Stage an. Webhook sendet den Befund an deinen konfigurierten Endpunkt.

Plexicus verknüpft ID, URL und Status des Tickets mit dem Befund und ergänzt seine Timeline um einen Eintrag „ticket created“. Geh nicht davon aus, dass sich das Ticket von selbst schließt, wenn der Befund behoben ist. Schließ es über den normalen Workflow deines Trackers.

Ausgehende Webhooks und Automation-Integrationen

Der Webhook-Connector sendet Befunde an einen HTTP-Endpunkt, den du kontrollierst. Sein Assistent hat vier Schritte: Settings (Webhook Name, Webhook URL, HTTP Method POST oder PUT, Data Format), Authentication (None, Basic oder Bearer Token), Headers und Preview, wo du den Payload prüfst und einen Test sendest.

Die Seite für Automation-Integrationen listet die verbundenen externen Systeme, die deine Automatisierungen nutzen können: HashiCorp Vault, Kubernetes Secrets, Jira, ServiceNow, Source control, HTTP API und Outgoing webhook. Das Feld Credentials reference enthält einen Verweis auf gespeicherte Zugangsdaten, nie das Secret selbst. Jede Karte zeigt Unverified, Healthy oder Unhealthy, und Save and test prüft eine neue Integration sofort. Eine Integration, die noch ein Flow nutzt, kannst du nicht löschen.

Signierte eingehende Webhooks

Ein Flow mit dem Trigger Webhook bekommt eine eigene Ingress URL. Klick im Trigger-Panel auf Generate new secret und kopier das Secret sofort, denn es wird nur einmal angezeigt. Ein neu generiertes Secret ersetzt das alte sofort, also aktualisiere alle Aufrufer gleichzeitig. Der Aufrufer signiert den rohen Request-Body per HMAC-SHA256 mit diesem Secret und sendet den Hex-Digest im Header X-Plexicus-Signature als sha256=HEX_DIGEST. Das Panel enthält einen fertigen Beispiel-Request. In einer Shell sieht das Signieren so aus:

BODY='{"service":"billing-api","event":"deploy"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" | awk '{print $NF}')
curl -X POST "$INGRESS_URL" \
  -H "Content-Type: application/json" \
  -H "X-Plexicus-Signature: sha256=$SIG" \
  --data "$BODY"

Signiere genau die Bytes, die du sendest. Serialisiert der Aufrufer das JSON nach dem Signieren neu, passt die Signatur nicht mehr.

HTTP-Response	Label unter Recent deliveries	Bedeutung
202	Accepted	Für jede angenommene Zustellung startet ein neuer Lauf
401	Invalid signature	Die Signatur fehlt oder passt nicht zum Body und zum aktuellen Secret, oder es wurde noch kein Secret generiert
409	Inactive	Der Flow ist inaktiv oder nutzt keinen Webhook-Trigger
400	Invalid JSON	Der Body ist kein gültiges JSON
413	Payload too large	Der Body überschreitet die Größenbegrenzung
429	Rate limited	Zu viele Zustellungen für die Organisation

Zugriff für Entwickler: API-Tokens und die REST API

Skripte, CI-Pipelines und IDE-Agenten greifen alle über Tokens auf Plexicus zu. Mit dem richtigen Token bleibt der Zugriff nachvollziehbar und lässt sich leicht widerrufen.

Persönliche API-Tokens

Geh zu Settings API Tokens . Gib einen Token name ein, wähle eine Expiration (30 days, 90 days oder No expiration) und klick auf Generate token. Der Wert erscheint einmalig unter „Save your token now“. Kopier ihn und klick dann auf I’ve saved it. Die Tabelle Active tokens zeigt Name, Created, Expires und Type, mit Revoke in jeder Zeile.

Ein persönliches Token hat keine eigenen Scopes. Es handelt in deinem Namen, mit deiner Rolle und deinen Berechtigungen in der Organisation. Ein Token, das ein Entwickler erstellt hat, kann genau das, was dieser Entwickler in der Konsole kann, und nicht mehr. Ein Widerruf wirkt sofort, und jeder spätere Aufruf mit dem Token liefert 401. Das Erstellen von Tokens wird im Audit-Log festgehalten.

Bewährte Gewohnheiten:

• Erstell ein Token pro Tool (ein Reporting-Skript, deine IDE, ein CI-Job), damit du eines widerrufen kannst, ohne die anderen lahmzulegen.
• Wähle lieber eine Laufzeit von 30 oder 90 Tagen. Wenn du No expiration wählst, prüf die Spalte Expires, denn möglicherweise gilt trotzdem eine lange Standardlaufzeit.

Das Plexalyzer-Token der Organisation

Das Plexalyzer-Token, auch CI/CD-Scanner-Token genannt, gehört der Organisation und nicht einer Person. Es authentifiziert den Plexalyzer-Scanner in deinen Pipelines. Admins erstellen es, optional mit Ablaufdatum, unter Settings Plexalyzer Token . In manchen Releases erscheint dasselbe Token als Abschnitt CI/CD scanner token unter Settings API Tokens . Wie du es als CI-Secret PLEXALYZER_TOKEN hinterlegst und Pipelines einrichtest, behandelt Modul 3.

Für allgemeine API-Aufrufe gibt es bei Plexicus kein Token auf Organisationsebene. Auch ein Skript, das unabhängig vom Zugang einer einzelnen Person weiterlaufen soll, braucht ein persönliches API-Token. Wähle also bewusst, wem es gehört, gib dem Token einen eigenen Namen und widerrufe es, sobald es nicht mehr gebraucht wird.

Token	Inhaber	Einsatzzweck
Persönliches API-Token	Du, mit deiner Rolle	Skripte, Integrationen, der MCP-Server
CLI-Token	Du, mit deiner Rolle	Die Plexicus TUI, erstellt durch plexicus login
Plexalyzer-Token	Die Organisation	Nur der Plexalyzer-Scanner in CI/CD

Grundlagen der REST API

Jeder Request sendet Authorization: Bearer, gefolgt von deinem Token, und Accept: application/json, bei POST, PUT und PATCH zusätzlich Content-Type: application/json. Die SaaS-Basis-URL steht im API-Guide unter docs.plexicus.ai; ein selbst gehostetes Deployment nutzt seine eigene URL. Ressourcenpfade stehen im Plural, etwa /repositories, /findings, /remediations, /repository-scans und /automations.

curl -H "Authorization: Bearer $PLEXICUS_API_TOKEN" \
     -H "Accept: application/json" \
     "$PLEXICUS_API_URL/findings?filters%5Bseverity%5D=critical,high&limit=25"

Listen nutzen Cursor-Pagination. Eine Response enthält items, total und einen next-Link; übergib dessen Cursor, um die nächste Seite zu holen. Die meisten Endpunkte liefern standardmäßig 25 Einträge pro Seite, mit limit änderst du das.

Lang laufende Aktionen liefern 202 und laufen im Hintergrund weiter. POST /repository-scans mit einer repository_id und einem scan_type von app oder sbom startet einen Scan. POST /remediations mit einer finding_id fordert einen KI-Fix an; frag GET /remediations?finding_id=... so lange ab, bis Diff und Hinweise zurückkommen (404 heißt: noch nicht fertig). KI-Aktionen gehen zulasten deines KI-Nutzungskontingents, das unter Settings Billing und in deinem Profilmenü angezeigt wird (Module 7 und 10). Du kannst einen Flow auch über den Executions-Endpunkt von /automations starten, für bis zu 100 Befunde pro Aufruf und optional als Testlauf.

Fehler nutzen das Format Problem Details nach RFC 7807. Ein 401 bedeutet, dass das Token ungültig, abgelaufen oder widerrufen ist. Ein 403 bedeutet, dass das Token funktioniert, deine Rolle oder dein Plan die Aktion aber nicht erlaubt. Ein 429 bedeutet, dass du ein Rate Limit erreicht hast; versuch es dann mit exponentiellem Backoff erneut.

Arbeiten im Terminal und in der IDE

Zwei Entwickler-Tools bringen Befunde dorthin, wo du ohnehin arbeitest: die Plexicus TUI in deinem Terminal und der Plexicus MCP server in deiner IDE.

Die Plexicus TUI

Lade das Binary für macOS Apple Silicon, macOS Intel oder Linux x86-64 von der Seite GitHub Releases unter github.com/plexicus/tui herunter. Danach:

plexicus --version   # Installation prüfen
plexicus login       # im Browser anmelden
plexicus             # Befunde und verbundene Repositories durchsuchen

Beim ersten Start fragt ein Einrichtungsassistent nach der URL deines Plexicus-Servers.

Taste	Aktion
F	Filter öffnen
/	Suchen
Enter	Befunddetails öffnen
r	KI-Behebung anfordern
p	Pull Request erstellen

Drück r, prüf den Diff und drück erst dann p. Der Pull Request durchläuft euren üblichen Review-Prozess, und dein Team behält die Kontrolle über den Merge.

Was plexicus login macht

plexicus login öffnet deinen Browser auf der Autorisierungsseite von Plexicus. Melde dich bei Bedarf an, auch mit 2FA, falls aktiviert. Die Seite zeigt „Authorizing Plexicus CLI…“ und danach „CLI authorized“. Im Hintergrund erstellt Plexicus ein persönliches API-Token namens CLI - YYYY-MM-DD, das 365 Tage gültig ist, und dein Browser übergibt es der CLI über eine lokale Adresse 127.0.0.1. Die CLI speichert es in ~/.config/plexicus.

Weil es ein normales persönliches Token ist, erscheint es unter Settings API Tokens , und dort widerrufst du es auch. plexicus logout löscht nur die lokale Kopie. Auf einem Headless-Rechner ohne Browser generierst du stattdessen ein persönliches Token und exportierst es als PLEXICUS_API_TOKEN.

Der Plexicus MCP server

Der Plexicus MCP server (Paket plexicus-mcp) läuft lokal auf deinem Rechner und gibt einem MCP-kompatiblen IDE-Agenten mit deinem persönlichen Token Zugriff auf die Plexicus REST API. Zu den dokumentierten Clients gehören Cursor, VS Code, Windsurf und ein Coding-Agent für die Kommandozeile. Die Einrichtung umfasst drei Schritte:

1. Client wählen.
2. Startmethode wählen: uvx plexicus-mcp (empfohlen), pipx run plexicus-mcp oder pip install plexicus-mcp.
3. Token konfigurieren und verbinden. Nachdem du ein Token generiert hast, zeigt der Abschnitt Use with your IDE (MCP) auf der Seite API Tokens vorausgefüllte Snippets: einen einzeiligen Befehl für Kommandozeilen-Clients und eine JSON-Konfiguration für Cursor, VS Code und Windsurf.

{
  "mcpServers": {
    "plexicus": {
      "command": "uvx",
      "args": ["plexicus-mcp"],
      "env": {
        "PLEXICUS_API_TOKEN": "YOUR_TOKEN",
        "PLEXICUS_API_URL": "YOUR_API_URL"
      }
    }
  }
}

PLEXICUS_API_TOKEN ist Pflicht. PLEXICUS_API_URL ist optional; ohne Angabe wird die SaaS-API verwendet, für selbst gehostete Deployments setzt du die Variable. Mit einem ungültigen Token liefern die Tools „Authentication failed — the API token is invalid, expired or revoked.“

Der Server stellt 10 Tools bereit. Nur request_scan und generate_remediation verändern etwas; alle anderen lesen nur.

Tool	Zweck
get_current_repository	Das Git-Remote deines Workspaces einem Plexicus-Repository zuordnen
list_repositories, get_repository	Repositories, Zahlen je Schweregrad und Scan-Status durchsuchen
list_findings, get_finding	Nach Schweregrad, Status, CWE oder Titel filtern und dann Details lesen
request_scan, get_scan_status	Einen App- oder SBOM-Scan starten und verfolgen
generate_remediation, get_remediation	Einen KI-Fix anfordern und seinen Diff samt Hinweisen abrufen
get_security_posture	Kontoweite Summen und die riskantesten Repositories

Außerdem bringt er drei geführte Prompts (fix_finding, triage_findings, security_review) und zwei Ressourcen mit: plexicus://repositories und eine Befund-Ressource pro Repository. Jedes Tool liefert eine lesbare Zusammenfassung plus die rohen API-Daten.

Das Wichtigste in Kürze

• Jeder Flow hat einen Trigger, Schritte mit Erfolgs- und Fehlerpfaden und einen protokollierten Lauf. Ein Flow läuft einmal pro Befund; nur ein Flow mit dem Trigger Finding reopened läuft erneut, und zwar bei jedem erneuten Öffnen.
• Flows beginnen als deaktivierte Entwürfe. Prüf sie mit einem Testlauf, lass sie von einem Admin aktivieren (die Aktivierung testet die Verbindungen erneut) und lies die Logs pro Schritt, denn auch ein Lauf mit Completed kann einen fehlgeschlagenen Schritt enthalten.
• Jira, ServiceNow und ausgehende Webhooks findest du unter Settings Integrations Ticket Management . Eingehende Webhooks müssen per HMAC-SHA256 mit dem aktuellen Secret des Flows signiert sein.
• Persönliche API-Tokens handeln mit deiner eigenen Rolle; das Plexalyzer-Token der Organisation ist nur für den Scanner da. Nutze ein Token pro Tool und widerrufe, was du nicht nutzt.
• plexicus login erstellt ein widerrufbares persönliches Token für die TUI. Der MCP-Server gibt IDE-Agenten 10 Tools, und vorgeschlagene Fixes werden nie ohne dich zu Pull Requests.