Agentic SOC Platform: Alarmflut in Fälle verwandeln, mit Agenten statt mit Schichtplänen
Agentic SOC Platform: A powerful, flexible, open-source, and agent-centric automated security operations platform (AI SOC)
Auf einen Blick
- Was ist das?
- FunnyWolf/agentic-soc-platform verbindet SIEM-Anbindung, Playbooks und LLM-Agenten in einer Python- und TypeScript-Anwendung. Der README beschreibt viel, die Lizenzangabe widerspricht sich, und die Betriebskosten tauchen nirgends auf.
- Für wen ist es gedacht?
- Wer bereits Splunk oder ELK betreibt, einen kleinen Analystenstab hat und Python-Module selbst schreiben kann, findet hier eine lokal betreibbare Klammer um Alarmtriage, Anreicherung und Wissensablage. Wer eine fertig konfigurierte Plattform mit Supportvertrag sucht, oder wer LLM-Ausgaben ohne eigene Prüfschicht in Entscheidungen überführen will, sollte nicht damit anfangen.
- Darf ich es kommerziell nutzen?
- Nicht ohne Erlaubnis. GitHub findet in diesem Repository keine Lizenzdatei, und ohne Lizenz sind standardmäßig alle Rechte vorbehalten: Sie dürfen den Code lesen, aber nicht wiederverwenden. Prüfen Sie die README oder fragen Sie die Autoren, bevor Sie ihn nutzen.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 41 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Alarmmengen, die kein Team mehr lesen kann
Der Ausgangspunkt ist ein Mengenproblem, kein Erkenntnisproblem. Module nehmen SIEM- oder Webhook-Alarme entgegen, ziehen IOCs heraus, korrelieren verwandte Signale und erzeugen daraus Cases, Alerts und Artifacts. Der README formuliert das Ziel so, dass große Logmengen auf eine kleine Zahl bearbeitbarer Fälle zusammenlaufen. Adressat sind Blue-Team-Teams, die bereits ein SIEM betreiben und dort mehr Alarme erzeugen, als Analysten abarbeiten können. Die Plattform ersetzt das SIEM nicht, sie setzt sich davor. Wer noch kein Logmanagement hat, löst mit diesem Projekt kein Problem, weil die Eingangsdaten fehlen. Interessant ist der Zuschnitt auf Fälle statt auf Alarme: Ein Fall bündelt mehrere Signale und wird zur Einheit, an der gearbeitet und diskutiert wird.
Vom Alarm zum Fall: Module, Playbooks, Agenten
Die Architektur besteht laut README aus drei beweglichen Teilen. Python-Module übernehmen die Anpassung an neue SIEM-Regeln und Alarmquellen. Playbooks orchestrieren LLM-Analyse und automatisierte Aktionen und liegen nach Angaben des Projekts im selben System wie klassische SOAR-Abläufe. Agenten bearbeiten Triage, Untersuchung, Anreicherung und Wissensablage. Ein Fall ist der Knoten, um den herum sich LLM-Untersuchung, Knowledge Extraction, Threat-Intelligence-Anreicherung und CMDB-Anreicherung mit einem Klick starten lassen. Für die Anbindung an Splunk und ELK nennt der README eine einheitliche Logsuche und Webhook-Ingestion, sodass LLMs, Agenten und Analysten auf denselben Kontext schauen. Das ist eine sinnvolle Entscheidung: Wer Anreicherung und Analyse in getrennten Werkzeugen laufen lässt, verbringt die Zeit mit Kontextwechsel statt mit Bewertung. Die konkrete Datenhaltung, also welche Komponente welchen Zustand speichert und wie die Korrelation technisch aussieht, lässt sich aus dem vorliegenden Material nicht ableiten.
Installation: was der Quick-Start verlangt und was nicht im README steht
Der README verweist für den Einstieg auf die Seite asp.viperrtp.com/asp/quick-start/deployment/ und nennt selbst keine Befehle, keine Container-Images und keine Konfigurationsdatei. Wer die Plattform aufsetzen will, muss diese Seite lesen; aus dem Repository-Text allein lässt sich kein Installationsablauf rekonstruieren. Bekannt ist nur die Form: eine Anwendung mit Backend, Frontend und Erweiterungsskripten, geschrieben in Python und TypeScript, mit Unterstützung für lokale Bereitstellung. Für die Zugangskontrolle nennt der README lokale und LDAP-Anmeldung, Benutzerrollen, API Keys, Inbox-Benachrichtigungen und ein Audit Log. Diese Punkte sind relevant, weil sie in vielen kleinen SOC-Werkzeugen fehlen und dann nachträglich als Bastellösung entstehen. Wer eine Umgebung ohne LDAP betreibt, muss die lokale Anmeldung nutzen und die Rollen von Hand pflegen. Wie die API Keys gespeichert und widerrufen werden, sagt das Material nicht.
Die Lizenzangabe widerspricht sich
Der README schreibt an einer Stelle MIT licensed. Die Metadaten des Repositorys führen als Lizenz unknown. Das ist kein Detail, sondern der erste Punkt, der vor einem Produktiveinsatz zu klären ist, weil davon abhängt, ob und unter welchen Bedingungen der Code in eigene Abläufe eingebettet werden darf. Eine rechtliche Bewertung kann dieser Text nicht leisten. Praktisch heißt es: die LICENSE-Datei im Repository öffnen, nicht die README-Zeile glauben, und bei Unklarheit beim Maintainer nachfragen. Wer die Plattform nur intern als Werkzeug einsetzt, hat ein anderes Risiko als jemand, der Module und Playbooks weitergeben will.
Wissensablage: der interessanteste und der am schlechtesten belegte Teil
Der README verspricht, dass aus geschlossenen Fällen, Antwortprozessen und Diskussionen wiederverwendbares Wissen extrahiert wird und die organisationale Erfahrung mit jeder Reaktion wächst. Das ist der Punkt, an dem sich dieses Projekt von einem reinen Automatisierungswerkzeug unterscheidet, und zugleich der Punkt, an dem die Beschreibung am dünnsten ist. Es bleibt offen, in welcher Form dieses Wissen abgelegt wird, ob es versioniert ist, wie ein Analyst einen falsch extrahierten Eintrag korrigiert und ob die Extraktion an ein bestimmtes Modell gebunden ist. Genau diese Fragen entscheiden aber, ob die Ablage nach einem Jahr eine Hilfe oder eine Last ist. Solange das nicht dokumentiert ist, sollte man den Nutzen der Wissensablage nicht als Argument für die Einführung verwenden, sondern als Prüfpunkt für einen Testaufbau.
Harness-Agenten: Kopplung an Claude Code, Codex und OpenCode
Bemerkenswert ist die Richtung der Integration. Statt nur ein eigenes Webinterface anzubieten, exponiert die Plattform ihre Fähigkeiten über CLI und Plugins an Harness-Agenten wie Claude Code, Codex oder OpenCode. Diese Agenten können dann Fälle bearbeiten, Logs durchsuchen, Threat Intelligence abfragen und Module sowie Playbooks direkt schreiben. Das verlagert einen Teil der Bedienung aus der Plattform heraus in die Werkzeuge, die Entwickler ohnehin offen haben. Der Preis dafür ist eine zweite Angriffs- und Fehlerfläche: Wer einem Agenten Schreibzugriff auf Module und Playbooks gibt, muss entscheiden, was dieser Agent ohne Rückfrage ändern darf. Der README beschreibt die Fähigkeit, nicht die Absicherung. Wer diesen Weg geht, sollte die Schreibrechte zuerst auf eine Testinstanz begrenzen.
Wo das Werkzeug nicht passt, und was daneben steht
Zwei Grenzen sind im Material sichtbar. Erstens die Modellabhängigkeit: Ein erheblicher Teil des Nutzens hängt an LLM-Ausgaben, und der README nennt weder Standardmodell noch Bewertungsmaßstäbe für die erzeugten Einschätzungen zu Schweregrad, Konfidenz und Verdikt. Ohne eigene Prüfschicht bleibt unklar, wie verlässlich diese Felder sind. Zweitens die Anpassungslast: Neue Alarmquellen erfordern Python-Module, neue Abläufe erfordern Playbooks. Das ist Flexibilität, aber auch dauerhafte Entwicklungsarbeit, die jemand leisten muss. Eine Alternative mit anderem Ansatz ist ein klassisches SOAR wie Shuffle oder ein Fallmanagement in einem kommerziellen SIEM. Deren Automatisierung folgt festen Regeln und Schwellwerten, ist dadurch reproduzierbar und prüfbar, deckt aber die unscharfen Fälle nicht ab, in denen ein Mensch erst Kontext aufbauen müsste. Der Unterschied liegt nicht im Umfang, sondern in der Entscheidungslogik: Regelwerk gegen Modellausgabe. Wer Nachvollziehbarkeit über jede Automatisierung stellt, ist mit einem regelbasierten Playbook besser bedient. Umgekehrt gilt: Wer ohnehin mit Agenten arbeitet, bekommt hier eine Anbindung an den eigenen Fallbestand, die ein reines SOAR nicht bietet.
Wartung, Releases und was vor dem Einsatz zu prüfen ist
Das Projekt wird aktiv gepflegt. Die letzten drei Releases liegen laut Repository bei v0.5.0, v0.5.1 und v0.5.2, wobei v0.5.2 vom 28. Juli 2026 stammt und der letzte Push auf den master-Zweig vom 5. August 2026 datiert. Die Versionsnummern im 0.5er-Bereich sagen, dass die API und die Modulschnittstellen noch nicht eingefroren sind. Wer Module gegen die aktuelle Version schreibt, sollte damit rechnen, sie bei einem Minor-Release anzupassen. Upgrade-Aufwand entsteht an drei Stellen: an den eigenen Python-Modulen, an den Playbooks und an der Kopplung der Harness-Agenten, die auf CLI und Plugins zugreifen. Ein Betrieb ohne jemanden, der diese drei Teile liest und nachzieht, ist nicht sinnvoll. Vor dem Aufbau einer Testinstanz gehören drei Dinge auf die Liste: die LICENSE-Datei im Repository, die Deployment-Anleitung unter asp.viperrtp.com/asp/quick-start/deployment/ und eine Antwort auf die Frage, welches Modell die Analyse übernimmt und wer seine Ausgaben prüft.
Redaktionelles Fazit
Wer bereits Splunk oder ELK betreibt, einen kleinen Analystenstab hat und Python-Module selbst schreiben kann, findet hier eine lokal betreibbare Klammer um Alarmtriage, Anreicherung und Wissensablage. Wer eine fertig konfigurierte Plattform mit Supportvertrag sucht, oder wer LLM-Ausgaben ohne eigene Prüfschicht in Entscheidungen überführen will, sollte nicht damit anfangen. Vor dem Aufbau einer Testinstanz zuerst die LICENSE-Datei im Repository prüfen, weil die README MIT nennt, die Repository-Metadaten aber keine Lizenz ausweisen, und danach die Deployment-Seite unter asp.viperrtp.com/asp/quick-start/deployment/ gegen die tatsächlich verfügbaren Container-Images abgleichen.
Community-Notizen