Grundlagen von Proof-Driven AppSec

Warum Alert-Volumen keine Sicherheit ist

Die meisten AppSec-Programme können dir sagen, wie viele Alerts sie haben. Weit weniger können dir sagen, welche dieser Alerts ein Angreifer tatsächlich ausnutzen kann, was jeder einzelne betrifft und ob der Fix ausgeliefert wurde. Genau bei dieser Lücke setzt der Kurs an, denn der Rest der Plattform ist darauf ausgelegt, sie zu schließen.

Eine Alert-Zahl misst, wie viele Tools du betreibst und wie viele Regeln sie anwenden. Sie misst kein Risiko. Vier Probleme erklären den Unterschied.

Tool-Wildwuchs

Teams führen Tools meist Kategorie für Kategorie ein: einen statischen Analyzer für Code, einen Abhängigkeitsprüfer, einen Secrets-Scanner, einen Checker für Infrastructure as Code, einen Scanner für Container-Images. Jedes Tool hat seine eigene Konsole, seine eigene Schweregrad-Skala und sein eigenes Ausgabeformat. Dieselbe verwundbare Abhängigkeit kann in zwei oder drei davon unter unterschiedlichen Namen und Schweregraden auftauchen, und niemand verantwortet die zusammengeführte Sicht. Am Ende gleichen Engineers Exporte ab, statt Code zu fixen.

Plexicus führt die Scanner-Ausgaben in einem einheitlichen Befundformat zusammen und dedupliziert sie. Der verbleibende Befund übernimmt dabei den höchsten Schweregrad seiner Duplikate. Du kannst außerdem Ergebnisse kompatibler Scanner von Drittanbietern (zum Beispiel als SARIF) in denselben Workflow importieren. Modul 3 behandelt Engines, Abdeckung und die genaue Deduplizierungsregel.

Rauschen

Nimm ein Ergebnis der statischen Analyse mit dem Titel „possible SQL injection in login handler“. Es kann eine echte, ausnutzbare Schwachstelle im Login-Formular sein, bei der der Benutzername direkt in einen Query-String fließt. Es kann aber auch eine Abfrage in einem Test-Helper sein, die aus einer Konstante gebaut wird und die keine Benutzereingabe je erreicht. Beide kommen mit demselben Label und oft mit demselben Schweregrad an.

Wenn sich die meisten Alerts als die zweite Sorte entpuppen, lernen Entwickler, die Liste nur noch zu überfliegen, und die echten werden dann ebenfalls überflogen. Was die beiden Fälle unterscheidet, ist Evidenz: ob es einen Pfad von angreiferkontrollierter Eingabe zum verwundbaren Code gibt, ob der Code überhaupt erreichbar ist und ob eine zweite, unabhängige Prüfung das Ergebnis bestätigt.

Der Engpass bei der Behebung

Erkennen ist nicht Beheben. Jeder offene Befund ist Arbeit, die dein Team noch schuldet. Ein neues Problem zu finden kostet wenig. Für die Behebung braucht es einen Entwickler, der den Code versteht, eine Änderung, die nichts kaputt macht, ein Review und einen Merge. Wächst die Queue schneller, als das Team sie abarbeiten kann, vergrößert mehr Erkennung nur den Backlog, ohne die Anwendung sicherer zu machen. Der eigentliche Engpass sind Kontext und prüfbare Änderungen, nicht ein Mangel an Alerts.

Fehlende Sicht auf die Sicherheitslage

Versuch einmal, diese Fragen anhand einer rohen Alert-Liste zu beantworten. Welche drei Repositories tragen das größte ausnutzbare Risiko? Schließt du Befunde schneller, als neue entstehen? Wie lange bleibt ein kritischer Befund offen? Ein wachsender Berg an Alerts beantwortet keine davon. Die Führungsebene sieht eine Zahl, die nur steigt, und das nächste Audit findet wieder dieselben Probleme.

Häufiger zu scannen hat dieselbe Grenze. Ein nächtlicher Scan, der einen Monat lang dieselbe unbehobene SQL-Injection meldet, misst Aktivität, keinen Fortschritt. Die Scan-Häufigkeit sagt dir, wie oft du hingeschaut hast, nicht, ob irgendetwas sicherer geworden ist.

Das Plexicus-Dashboard folgt derselben Idee: Seine Summen zählen nur offene Arbeit (Modul 2). Der Tab CISO zeigt einen Risk Posture Score, New vs Fixed und Top Risky Repositories. Der Tab DevSecOps ergänzt Erreichbarkeit, Alter der Befunde und Behebungsgeschwindigkeit.

Der Proof-Driven-Kreislauf: Validieren, Verstehen, Beheben

Plexicus nennt seinen Ansatz Proof-Driven AppSec: erkennen, was real ist, verstehen, was es betrifft, und es mit Evidenz beheben. Der Ansatz hat drei Schritte, und jeder Schritt ist ein Produkt.

Schritt	Produkt	Welche Frage er beantwortet	Was du bekommst
Validieren	AI Swarm Pentest	Lässt sich das im autorisierten Scope tatsächlich ausnutzen?	Verifizierte Befunde mit reproduzierbarer Evidenz, einer Priorität und einer dokumentierten Übergabe
Verstehen	Deep Code Analysis	Welchen Code, welche Daten und welchen Geschäftsablauf betrifft es, und kann ein Angreifer es erreichen?	Den betroffenen Ablauf, seine Erreichbarkeit und Exposition, eine CWE-Schwachstellenklasse und eine Priorität
Beheben	Remediation	Welche Änderung schließt die Lücke, und hat die Änderung funktioniert?	Eine reviewbereite Änderung mit angehängter Evidenz, geliefert über deinen Pull-Request-Workflow, plus Verifikations-Re-Tests, sofern konfiguriert

Validieren mit AI Swarm Pentest

AI Swarm Pentest ist ein klar abgegrenzter, autorisierter Auftrag gegen eine Anwendung, eine API, Quellcode oder eine Testumgebung. Koordinierte KI-Prüfungen kartieren die Angriffsfläche, bilden Hypothesen und testen Pfade, und ein zweiter Durchlauf bestätigt jeden Befund unabhängig, bevor er als verifiziert markiert wird. AI Swarm Pentest ist weder ein Signatur-Scanner noch ein Security-Chatbot. Im Produkt heißt er AI Pentest und liegt im Bereich Pentest. Modul 6 behandelt ihn ausführlich.

Verstehen mit Deep Code Analysis

Eine Regel der statischen Analyse kann ein Muster markieren, und ein Sprachmodell kann Code erklären. Keines von beiden stellt fest, wie sich eine Schwachstelle auf deine Anwendung auswirkt. Deep Code Analysis verbindet einen Befund mit Code, Datenfluss und geschäftlicher Auswirkung. Für jeden Befund bekommst du den betroffenen Ablauf (Source, Propagation und Sink), ob ein Angreifer ihn erreichen kann und von wo aus (Erreichbarkeit und Internet-Exposition) sowie eine Schwachstellenklasse, die auf CWE und OWASP abgebildet ist. Modul 5 behandelt sie.

Beheben mit Remediation

Sobald ein Befund verifiziert ist, bereitet Remediation den Kontext und eine vorgeschlagene Änderung als reviewbereiten Diff vor. Dein Team prüft ihn und entscheidet über den Merge. Wenn der Pull Request gemergt ist, markiert Plexicus den Befund als Fixed. Je nach Plan und Konfiguration kann ein Verifikationstest den Fix prüfen, bevor der Pull Request geöffnet wird, und bei einem Pentest-Befund kannst du das Assessment erneut scannen, um zu prüfen, ob der Pfad geschlossen ist. Modul 7 behandelt den Workflow.

Wo XBOM und Plexicus Automation ihren Platz haben

Zwei Produkte arbeiten neben dem Kreislauf statt innerhalb eines einzelnen Schritts:

• XBOM ist ein einheitliches Inventar aus Softwarekomponenten (SBOM), kryptografischen Assets (CBOM) und KI-Modellen (AIBOM), mit VEX-Statements, die festhalten, ob eine bekannte Schwachstelle dich betrifft. Es beantwortet Fragen wie „Wo liefern wir die verwundbare Version dieser Bibliothek aus?“ und liefert Nachweise für Audits. Modul 8 behandelt es.
• Plexicus Automation leitet Befunde an Fixes, Tickets, Freigaben und Benachrichtigungen weiter, zum Beispiel wenn ein Befund erstellt, angereichert oder erneut geöffnet wird. Nur Admins können einen Flow aktivieren. Modul 9 behandelt es.

SAST, SCA, Prüfungen von Infrastructure as Code, Secrets-Erkennung und importierte Scanner-Ergebnisse sorgen für ergänzende Abdeckung. Sie liefern Signale, die in den Kreislauf einfließen. Sie ersetzen ihn nicht.

Der Evidenzstandard und seine Leitplanken

Die Regel hinter allem, was Plexicus liefert, passt in eine Zeile: Ohne reproduzierbaren Nachweis kein verifizierter Befund. Diese Lektion behandelt, was als Nachweis zählt, wie aus einem Signal ein verifizierter Befund wird und welche vier Leitplanken einen Auftrag innerhalb der vereinbarten Grenzen halten.

Reproduzierbarer Nachweis

Jeder Befund, den ein AI Swarm Pentest liefert, enthält Evidenz, die jemand anderes reproduzieren kann: den Request, die Response, die Schritte und die nachgewiesene Auswirkung. „Der Scanner hat es gemeldet“ ist kein Nachweis. Pentest-Befunde im Produkt können einen Replay-Proof-of-Concept enthalten, etwa einen cURL-Befehl, ein Shell-Skript oder einen HAR-Mitschnitt. Er wird genau so angezeigt, wie er aufgezeichnet wurde, und nicht aus deinem Browser erneut ausgeführt.

Unabhängige Verifizierung

Ein Signal wird nicht deshalb zu einem verifizierten Befund, weil eine einzelne Prüfung das sagt. Ein zweiter Durchlauf muss das beobachtete Verhalten unabhängig bestätigen.

Phase	Was das bedeutet	Was als Nächstes passiert
Befundkandidat	Eine Hypothese hat ein Signal mit technischem Kontext erzeugt	Er geht in die unabhängige Verifizierung
Verifizierter Befund	Ein zweiter Durchlauf hat das Ergebnis reproduziert	Er wird mit Auswirkung und Priorität ins Ergebnis aufgenommen
Nicht bestätigt	Der zweite Durchlauf konnte ihn nicht reproduzieren	Er wird als unverifiziert markiert oder verworfen, nie als verifiziert gemeldet

Wende dieselbe Disziplin an, wenn du Scanner-Ergebnisse triagierst. Die Detailansicht eines Befunds zeigt den Schweregrad des Scanners neben dem von der KI validierten Schweregrad („Severity — scanner vs AI“). Außerdem kennzeichnet sie jeden Schritt eines Dataflow-Traces nach seiner Herkunft, etwa Scanner dataflow oder AI-verified. Behandle jeden Schritt, der als AI-inferred (unverified) markiert ist, als Spur, der du nachgehen solltest, nicht als Nachweis (Modul 5 erklärt, wie Traces verifiziert werden).

Die vier Leitplanken

Bei einem AI Swarm Pentest-Auftrag wird der Evidenzstandard durch vier Leitplanken abgesichert. Es sind dieselben vier, die du auf der öffentlichen AI Swarm Pentest-Seite siehst, und Modul 6 wendet sie ausführlich an.

Leitplanke	Was sie für dich bedeutet
Schriftlich vereinbarter Scope	Das Ziel (eine Anwendung, eine API, Quellcode oder eine Testumgebung), der Testzugang und die Einsatzregeln werden bestätigt, bevor die Arbeit beginnt. Plexicus handelt nicht außerhalb dieses Scopes.
Nachvollziehbare Evidenz	Unterstützende Evidenz bleibt an dem Befund angehängt, den sie erklärt.
Auftragsgrenzen	Zeit, Ressourcen und Zugriff sind begrenzt, damit jeder Lauf kontrolliert bleibt.
Menschliche Entscheidung	Dein Team behält die endgültige Freigabe und die Kontrolle über jede Änderung. Plexicus nimmt keine automatischen Änderungen in der Produktion vor.

Wie das Produkt den Scope durchsetzt

Du kannst einen AI Pentest erst starten, wenn du nachgewiesen hast, dass dir das Ziel gehört. Für eine einzelne Anwendung weist du das mit einem Token in einem HTML-Meta-Tag oder mit einer Datei unter /.well-known/ nach. Für eine ganze Domain weist du es mit einem DNS-TXT-Record nach. Das Akzeptieren von Nutzungsbedingungen zählt nicht als Nachweis. In einem neuen Assessment ist „Destructive actions“ als außerhalb des Scopes vorausgewählt, und der Assistent empfiehlt, Staging statt Produktion zu testen.

Menschliche Entscheidung und Kontrolle über den Merge

KI automatisiert die repetitive Arbeit beim Erkunden, Korrelieren und Reproduzieren. Dein Team behält den Kontext, die Aufsicht und die endgültige Entscheidung. Im Produkt ist die Entscheidung einer Person über „Mark as false positive“ maßgeblich, und spätere KI-Durchläufe setzen sie nicht außer Kraft. Von der KI vorbereitete Fixes enthalten einen Hinweis, der den Reviewer bittet, die Änderung zu validieren.

Plexicus verändert niemals die Produktion. Es liefert ausschließlich prüfbare Vorschläge, als Pull Requests oder separate Patch-Dateien. Der KI-Fix-Agent bearbeitet einen isolierten Klon deines Repositorys. Plexicus pusht die Änderung nur in einen neuen Branch und öffnet einen Pull Request gegen deinen Base-Branch, und es mergt diesen Pull Request nie. Das Mergen ist immer die Entscheidung deines Teams in deiner eigenen Quellcodeverwaltung.

Ein Überblick über die Plattform und wer sie nutzt

Die Hauptseitenleiste führt dich zu Dashboard, Assets, Pentest, Findings, XBOM, der Seite Automations und Settings. Docs und Support befinden sich ganz unten. Drück ⌘K (Strg+K unter Windows und Linux), um eine Befehlspalette zu öffnen und direkt zu jedem Bereich zu springen.

Bereich	Was du dort tust	Wer ihn am meisten nutzt
Dashboard	Die Sicherheitslage über die Tabs CISO, DevSecOps, Compliance, Developer und Custom verfolgen, gefiltert nach Zeitraum und Repository	Security-Verantwortliche, Security Engineers, Entwickler
Assets	Verbundene Repositories im Tab Repo Scan verwalten: Repositories hinzufügen, Scans verfolgen, erneut scannen. Die Tabs Registry Audit und Cloud Assessment sind je nach Plan verfügbar	Security Engineers, Plattformverantwortliche
Pentest	AI Pentest-Assessments anlegen, das Eigentum am Ziel verifizieren, Läufe beobachten und ihre Ergebnisse öffnen	Security Engineers
Findings	Befunde in den Tabs Repo, SCM, Cloud, Registry und App Pentest triagieren. Einen Befund öffnen, um Evidenz zu prüfen, ein Ticket zu erstellen oder die Behebung zu starten	Security Engineers, Entwickler
XBOM	Die Inventare Software (SBOM), Cryptography (CBOM) und AI Models (AIBOM) durchsuchen, VEX-Statements setzen und exportieren	Security Engineers, Compliance-Teams, Plattformverantwortliche
Automations	Flows erstellen, die Befunde an Fixes, Tickets und Freigaben weiterleiten	Admins erstellen und aktivieren Flows
Settings	Organization (Team, Rollen, Eigentumsverifizierung), Configuration (Integrationen, Plattformoptionen, Abrechnung) und My Account (Kontodaten, Authentifizierung, Tokens)	Admins und Plattformverantwortliche, außerdem alle für ihr eigenes Konto

Drei Arten von Nutzern

• Security Engineers (AppSec und DevSecOps) triagieren Befunde, konfigurieren Scans, führen AI Pentest-Assessments durch und übergeben verifizierte Arbeit an Entwickler.
• Entwickler arbeiten die ihnen zugewiesenen Befunde ab, prüfen von der KI vorbereitete Fixes und öffnen Pull Requests. Viele erledigen das lieber aus der IDE oder dem Terminal heraus, was Modul 9 behandelt.
• Plattformverantwortliche deployen und betreiben Plexicus, binden Quellcodeverwaltung und Identity Provider an und verwalten die Einstellungen der Organisation.

Integrierte Rollen im Überblick

Rolle	Wofür sie gedacht ist
Admin	Vollständige Administration der Organisation: Team, Rollen, Einstellungen, Integrationen, Abrechnung und Audit-Log. Admins können außerdem Behebungen generieren und Pull Requests öffnen.
Cyberoper	Die Rolle des Security-Operators. Triagiert Befunde, markiert False Positives, generiert Behebungen und weist über Send to Dev Team Arbeit zu. Öffnet standardmäßig keine Pull Requests.
Developer	Bearbeitet die ihm zugewiesenen Befunde und öffnet Pull Requests für Fixes mit dem Status Ready to Fix.

Die Aufteilung ist Absicht. Mit den Standardrollen kann die Person, die einen Fix vorbereitet, eine andere sein als die, die ihn der Codebasis vorschlägt. Ein Cyberoper generiert und prüft die Änderung, und ein Developer öffnet den Pull Request. Je nach Plan können Admins unter Settings Roles außerdem eigene Rollen anlegen. Integrierte Rollen lassen sich weder umbenennen noch löschen. Modul 10 behandelt Rollen, SSO und das Audit-Log im Detail.

Grundlagen zu Deployment und Vertrauen

Plexicus läuft als EU SaaS oder selbst gehostet, wobei Air-gapped eine Variante von Self-hosted ist. Das Produkt ist in allen Fällen dasselbe; nur Hosting und Netzwerkgrenzen ändern sich.

Option	Wo es läuft	Wann du es wählst
EU SaaS (Standard)	Von Plexicus gehostet unter app.plexicus.ai, betrieben mit einer Zusage zur EU-Datenresidenz (siehe trust.plexicus.ai)	Die meisten Teams. Du musst keine Infrastruktur verwalten, und Updates laufen automatisch
Self-hosted	Dein eigener Kubernetes-Cluster, On-Premises oder in einem Cloud-Konto unter deiner Kontrolle, installiert mit dem offiziellen Helm-Chart	Strenge Anforderungen an Datenresidenz, Compliance oder Netzwerkisolation
Air-gapped (Self-hosted-Variante)	Die Self-hosted-Installation per Helm, mit Images, die in eine interne Registry gespiegelt werden, und deinem eigenen internen Zertifikatsaussteller	Cluster ohne öffentlichen Internetzugang oder mit strengen Egress-Kontrollen

Was „Self-hosted“ bedeutet

Self-hosted und On-Premises sind dasselbe Produkt, derselbe Chart und dieselbe Lizenz, und ein selbst gehostetes Deployment sendet keine Telemetrie-, Analyse- oder Feedbackdaten nach außerhalb deines Clusters. Funktionen, die von den kommerziellen Diensten von Plexicus abhängen, etwa die Abrechnung, sind deaktiviert, und nur die Integrationen, die du selbst konfigurierst, etwa deine Quellcodeverwaltung und dein KI-Anbieter, kommunizieren mit externen Systemen. Modul 10 behandelt Helm, Air-gapped-Installationen und Backups.

Dein Code und KI

• Kundencode wird nicht zum Training von KI-Modellen verwendet.
• Plexicus SaaS wird mit einer Zusage zur EU-Datenresidenz betrieben (siehe trust.plexicus.ai). Der Rechtsträger, PLEXICUS, S.L., hat seinen Sitz in Bilbao, Spanien, und unterliegt der EU-Gerichtsbarkeit.
• KI-Funktionen senden den relevanten Code-Kontext an den konfigurierten Modell-Endpunkt. Standardmäßig sind das von Plexicus verwaltete Modelle oder, je nach Plan, der Endpunkt deines eigenen KI-Anbieters, den du unter Settings BYOAI konfigurierst.

Vertrauen und Nachweise

Plexicus ist nach SOC 2 Type II zertifiziert. Ein unabhängiges Unternehmen führt jedes Jahr einen Pentest der Plattform durch. Den SOC 2-Bericht, eine Vorlage für den Auftragsverarbeitungsvertrag (DPA), die Zusammenfassung des Penetrationstests und Antworten auf Sicherheitsfragebögen findest du zum Selbstabruf im Trust-Portal unter trust.plexicus.ai. Eine Schwachstelle in Plexicus selbst meldest du an info@plexicus.ai.

Sei präzise, wenn du über Compliance sprichst. Plexicus macht deine Organisation nicht konform mit NIS2, DORA Artikel 28, dem CRA oder dem EU AI Act. Es ordnet Befunde im Tab Compliance des Dashboards den Frameworks zu, die du auswählst, etwa NIS2, DORA und dem CRA, und XBOM-Attestierungen lassen sich gegen Profile wie den EU CRA und den EU AI Act bewerten. Deine Auditoren prüfen anschließend diese Nachweise. Modul 8 behandelt das im Detail.

Das Wichtigste in Kürze

• Alert-Volumen misst den Output von Tools, nicht Risiko. Tool-Wildwuchs, Rauschen, der Engpass bei der Behebung und die fehlende Sicht auf die Sicherheitslage halten Teams beschäftigt, ohne sie sicherer zu machen.
• Proof-Driven AppSec ist ein Kreislauf: Validieren mit AI Swarm Pentest, Verstehen mit Deep Code Analysis und Beheben mit Remediation. XBOM und Plexicus Automation arbeiten daneben.
• Ohne reproduzierbaren Nachweis kein verifizierter Befund. Ein Ergebnis, das ein zweiter Durchlauf nicht reproduzieren kann, wird als unverifiziert markiert oder verworfen.
• Bei einem AI Swarm Pentest-Auftrag gelten vier Leitplanken: schriftlich vereinbarter Scope, nachvollziehbare Evidenz, Auftragsgrenzen und menschliche Entscheidung. Plexicus nimmt keine automatischen Änderungen in der Produktion vor, und dein Team behält immer die Kontrolle über den Merge.
• Die Seitenleiste führt dich zu Dashboard, Assets, Pentest, Findings, XBOM, der Seite Automations und Settings. Die drei integrierten Rollen Admin, Cyberoper und Developer teilen die Aufgaben untereinander auf.
• EU SaaS ist der Standard, und Self-hosted-Installationen per Helm sowie Air-gapped-Installationen laufen mit demselben Produkt. Kundencode wird nicht für KI-Training verwendet, und Plexicus ist selbst SOC 2 Type II-zertifiziert und liefert für deine Frameworks Nachweise, keine Compliance.