SecSuite

Plattform für Sicherheitsberater — 10 Module

Erstellt von Rogue AI · Eine Plattform für den gesamten Beratungs-Lebenszyklus · Selbst gehostet

Allein als Portfolio-Projekt gebaut, Modul für Modul weiterentwickelt.

SecSuite — Plattform für Sicherheitsberater — 10 Module

Das Problem

Ein unabhängiger Sicherheitsberater durchläuft bei jedem Auftrag denselben Ablauf — Umfang abstecken, Findings erfassen, Nachweise verwalten, den Bericht schreiben, die Rechnung stellen — doch die Werkzeuge sind über Tabellen, Notizdateien und unverbundene SaaS-Abos verstreut. Jedes Tool besitzt nur einen Ausschnitt der Daten, kein Werkzeug teilt einen Kundendatensatz, und dasselbe Finding wird dreimal abgetippt, bevor es in ein Liefergut gelangt. SecSuite ist eine Plattform, die den gesamten Lebenszyklus hinter einem einzigen Login hält, sodass ein Kunde, ein Auftrag, dessen Findings, die Nachweise und der daraus entstehende Bericht und die Rechnung alle auf dieselben Datensätze verweisen.

Was ich gebaut habe

Eine einzige Next.js-16-/React-19-Anwendung mit einer einzigen PostgreSQL-Datenbank im Rücken. Das Schema ist groß — 47 Prisma-Modelle —, weil der Beratungs-Lebenszyklus tatsächlich so viele Entitäten hat: Kunden, Aufträge, Findings, Nachweise, Recon-Ziele, Phishing-Kampagnen, Compliance-Bewertungen, Angebote, Rechnungen, Zeiteinträge. Zehn Module sitzen auf diesem Schema, jedes besitzt einen Ausschnitt des Ablaufs, liest und schreibt aber dieselben gemeinsamen Datensätze. Die Authentifizierung ist ein eigenes HS256-JWT (jose) in einem httpOnly-Cookie statt NextAuth, was das Session-Modell klein und explizit hält und vermeidet, die Meinungen eines Frameworks in ein Einzelnutzer-Werkzeug zu ziehen.

Architektur

Zehn Lebenszyklus-Module, ein Schema

Auftragsverwaltung, Findings + Berichte, Recon, Phishing-Simulation, Compliance-Tracking, KI-Sicherheitstests, Angriffsflächen-Überwachung, eine Wissensdatenbank, Angebote/SOWs sowie Rechnungsstellung + Zeit. Es sind keine getrennten Apps — es sind Sichten auf ein einziges Prisma-Schema, sodass ein während eines Auftrags erfasstes Finding ohne Kopieren in den Bericht und das Angebot fließt.

47 Prisma-Modelle auf Prisma 7 + Postgres

Das Datenmodell ist die eigentliche Oberfläche der Plattform. Prisma 7 verlangt den PrismaPg-Adapter und eine prisma.config.ts (kein url im datasource-Block), und jeder PrismaClient läuft darüber. Der Datenbank-Nutzer der App hat minimale Rechte, nicht die des postgres-Superusers.

Eigenes JWT statt NextAuth

Ein secsuite_session-httpOnly-Cookie trägt ein 24-Stunden-HS256-Token, signiert mit jose; bcryptjs mit Kosten 12 für das Passwort-Hashing. Die Middleware prüft das Token, setzt einen x-user-id-Header für API-Routen und erzwingt eine Origin-Prüfung (CSRF) bei jeder verändernden Anfrage. Seiten-Routen leiten auf /login um; API-Routen geben 401-JSON zurück.

Kundenspezifisches RAG über einen gemeinsamen Wissensdienst

Die Dokumentation jedes Kunden wird über einen gemeinsamen Wissensdienst (ein Qdrant-Vektorspeicher, erreicht über eine lokale Bridge) für den Abruf indexiert, sodass Antworten und Entwürfe im eigenen Material dieses Kunden verankert sind und nicht im gesamten Korpus. Die Collections sind pro Kunde namensbasiert getrennt, damit der Kontext eines Auftrags nicht in einen anderen gelangt.

Lokal-erstes LLM mit Provider-Umschalter

LLM-Aufrufe gehen standardmäßig an ein lokales Ollama-Modell und können über eine einzige LLM_PROVIDER-Umgebungsvariable, geroutet über eine lokale Bridge, auf ein gehostetes Modell umschalten. Die lokale Voreinstellung hält Kundenmaterial auf der Maschine und das Werkzeug offline nutzbar; der Umschalter existiert für den Fall, dass ein schwereres Modell sich lohnt.

Isolierte, gehärtete Docker-Bereitstellung

App, Postgres, Redis und ein separater, nur ausgehender Scanner-Worker laufen in einem eigenen Bridge-Netzwerk, alle Ports an 127.0.0.1 gebunden. Container legen alle Capabilities ab, laufen mit no-new-privileges, schreibgeschütztem Root-Dateisystem und tmpfs-Scratch und pinnen Basis-Images per Digest. Der Active-Scan-Worker hat keine eingehenden Ports und wird vor jeder Berührung eines Ziels durch eine explizite In-Scope-Autorisierungsprüfung abgesichert.

Tech-Stack

Next.jsPrisma 7PostgreSQLOllamaCustom JWT

Was zuerst gebrochen ist

▸
Ein breites Schema ist ehrlich, kein Ballast — der Beratungs-Lebenszyklus hat wirklich Dutzende eigenständiger Entitäten, und sie durch ein gemeinsames Datenmodell zu zwingen ist genau das, was das Abtippen beseitigt, das verstreute Werkzeuge verursachen.
▸
Eigenes JWT war für ein Einzelnutzer-Werkzeug die richtige Wahl: ein kleines, explizites Session-Modell lässt sich leichter durchdenken und härten als ein vollständiges Auth-Framework zu verdrahten, von dem ich nur einen Pfad nutzen würde.
▸
Die kundenweise RAG-Trennung zählt bei dieser Größe mehr als die Abruf-Qualität — zu verhindern, dass der Kontext eines Kunden in den eines anderen sickert, ist der Teil, den man nicht falsch machen darf.

Ergebnis

Das Ergebnis ist eine Anwendung, in der ein Kundendatensatz, dessen Aufträge, Findings, Nachweise, Berichte und Rechnungen dieselben Datensätze teilen, wobei kundenspezifisches RAG jede KI-Unterstützung im eigenen Material des Kunden verankert — vollständig auf selbst gehosteter Infrastruktur mit lokal-erster LLM-Inferenz betrieben.

Ehrliche Grenzen

Dies ist ein selbst gehostetes Einzelnutzer-Werkzeug, allein als Portfolio-Projekt gebaut, kein mandantenfähiges SaaS. Es läuft in einem lokalen Docker-Labor; der alte VPS, auf den es einst zielte, wurde stillgelegt. Es steht kein Team dahinter, es gibt kein gehostetes Angebot und keine Verfügbarkeitszusage — es zeigt, wie der gesamte Beratungs-Lebenszyklus hinter einem Schema und einem Login leben kann, und die KI-Funktionen sind nur so gut wie das lokale Modell und die zugeführten Dokumente.