Agentic SOC Platform : le triage d'alertes confié à des agents, sous conditions
Agentic SOC Platform: A powerful, flexible, open-source, and agent-centric automated security operations platform (AI SOC)
En bref
- De quoi s’agit-il ?
- ASP relie SIEM, enrichissement CTI et playbooks dans un même dossier d'investigation, avec des agents LLM et des agents externes type Claude Code. Le mécanisme est lisible dans le dépôt, les conditions d'exploitation beaucoup moins.
- À qui s’adresse-t-il ?
- ASP convient à une équipe SOC qui ingère déjà du SIEM ou du webhook et veut un point d'entrée unique pour l'investigation, sans sortir ses données de son réseau. Il ne convient pas à qui cherche un parseur de logs ou un SIEM : la plateforme consomme des alertes, elle n'en produit pas.
- Puis-je l’utiliser commercialement ?
- Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 41 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que la plateforme prend en entrée, et ce qu'elle en fait
ASP ne collecte pas de télémétrie. Le README décrit des modules qui reçoivent des alertes depuis un SIEM ou par webhook, en extraient les IOC, corrèlent les signaux liés et produisent des Cases, des Alerts et des Artifacts. Toute la valeur se joue donc en aval de la détection : si votre règle Splunk ou votre pipeline ELK ne remonte pas un signal exploitable, ASP n'a rien à corréler. C'est une distinction que le vocabulaire marketing du projet masque un peu. La formulation « massive log volumes converge into a small number of actionable cases » laisse entendre un traitement du volume brut, alors que la réduction se fait sur des alertes déjà qualifiées par un tiers. Pour un analyste, la promesse concrète est ailleurs : un dossier unique où l'alerte, ses IOC et son contexte d'actif sont réunis, au lieu de trois onglets et d'un ticket. Le public visé est une équipe blue team qui a déjà un SIEM en production et qui perd du temps à recoller manuellement le contexte autour de chaque alerte. Une équipe sans SIEM n'a rien à brancher.
Le Case comme unité de travail, pas l'alerte
La granularité retenue est le Case, pas l'alerte. Les alertes et les Artifacts y sont rattachés, et c'est autour du Case que se déclenchent les actions : investigation LLM, extraction de connaissance, enrichissement en threat intelligence, enrichissement CMDB. Ce choix a une conséquence pratique : la corrélation doit être suffisamment bonne pour que le regroupement ait un sens. Le README ne documente pas la logique de rattachement, ni les clés utilisées pour décider que deux alertes appartiennent au même Case. C'est la zone la plus floue du projet, et c'est aussi celle qui détermine si la plateforme réduit la charge ou ajoute une couche de dossiers mal fusionnés. Un analyste qui hérite d'un Case contenant des signaux sans rapport perd plus de temps qu'avec des alertes séparées. À l'inverse, un Case bien constitué concentre l'historique, la réputation des IOC et le contexte d'actif au même endroit, ce qui est exactement ce que le triage manuel coûte cher à reconstituer.
Deux familles d'agents dans le même dépôt
Le projet distingue ce que le README appelle les Harness Agents (Claude Code, Codex, OpenCode) et les agents internes qui exécutent l'investigation LLM. Les premiers sont exposés aux capacités d'ASP par une CLI et des plugins : un agent externe peut opérer des Cases, chercher dans les logs, interroger la threat intelligence et écrire des modules et des playbooks. Les seconds tournent dans la plateforme et alimentent les verdicts. Cette séparation est le point de conception le plus intéressant du dépôt, parce qu'elle déplace la surface de risque. Autoriser un agent à écrire des playbooks revient à lui donner un chemin vers l'exécution automatisée de contre-mesures. Le README mentionne des rôles utilisateurs, des API Keys et un journal d'audit, sans détailler les permissions attachées aux clés utilisées par les agents. C'est exactement l'endroit où une équipe doit poser ses propres règles avant d'ouvrir la CLI à un agent : la documentation publique ne permet pas de savoir ce qu'une clé d'agent peut déclencher comme action de remédiation.
Installation et premiers fichiers à regarder
Le README ne contient aucune commande d'installation : il renvoie à la page Quick Start du site officiel, sous le chemin asp/quick-start/deployment/. C'est une lacune pour un lecteur qui évalue le projet depuis GitHub, parce que la procédure de déploiement, les dépendances et la configuration initiale ne sont pas versionnées avec le code. Deux éléments sont en revanche identifiables dans le dépôt. D'abord le fichier LICENSE à la racine : le README annonce une licence MIT, mais la fiche du dépôt indique une licence inconnue. Cette contradiction doit être tranchée avant toute réutilisation, en lisant le fichier lui-même. Ensuite le répertoire img/, qui contient les captures référencées dans le README (img.png, img_1.png à img_10.png) et le logo du projet. Pour le reste, la configuration se fait par modules Python, un par source d'alerte ou par règle SIEM, et par playbooks qui orchestrent analyse LLM et actions. Aucun nom de fichier de configuration, aucune variable d'environnement et aucun exemple de playbook ne figure dans le README. Il faut passer par la documentation en ligne pour obtenir ne serait-ce qu'un squelette fonctionnel.
Les playbooks mélangent SOAR classique et analyse LLM
L'argument du projet est que les workflows SOAR traditionnels et l'analyse par LLM vivent dans le même système de playbooks, plutôt que dans deux outils reliés par des appels HTTP. Sur le papier, cela évite la rupture de contexte entre l'action déterministe (bloquer une IP, ouvrir un ticket) et l'analyse probabiliste (résumer, qualifier, proposer un verdict). En pratique, la fiabilité des deux moitiés n'est pas de même nature. Une action de playbook qui échoue se voit dans les logs ; une analyse LLM qui produit un verdict faux mais bien rédigé ne se voit pas, surtout si l'analyste lit le rapport au lieu de vérifier les IOC. Le README ne décrit aucun mécanisme d'évaluation des verdicts produits, ni de comparaison avec une décision humaine. La sortie structurée annoncée (severity, confidence, impact, priority, verdict) donne un cadre, mais un champ confidence renseigné par le modèle n'est pas une mesure de fiabilité. C'est la limite principale de ce type d'outil, et le projet ne l'aborde pas dans le matériel disponible.
Enrichissement CTI et capitalisation : ce qui reste à prouver
L'enrichissement automatique des IOC et des Artifacts est décrit comme apportant réputation, pulses, contexte d'actif, d'identité et historique. Le README ne nomme aucune source de threat intelligence, aucun format d'échange et aucun connecteur précis. Impossible donc de savoir si l'enrichissement s'appuie sur des flux commerciaux, des flux ouverts ou une API interne. Même remarque pour l'accumulation de connaissance : le projet annonce extraire de la connaissance réutilisable depuis les dossiers clos, les processus de réponse et les discussions. Aucun détail sur le stockage, l'indexation ou la manière dont cette connaissance est réinjectée dans les investigations suivantes. Ces deux briques sont celles qui justifient le plus l'adoption sur la durée, et ce sont précisément celles que la documentation résume en une phrase. Un évaluateur sérieux doit les tester en premier, sur ses propres dossiers clos, avant de considérer le reste.
Alternatives : SOAR classique, SIEM natif, ou orchestration maison
La comparaison la plus directe est un SOAR classique, par exemple Shuffle ou TheHive avec Cortex. La différence d'approche est nette : un SOAR exécute des playbooks déterministes, avec des étapes dont le résultat est prévisible et vérifiable, et l'analyste reste l'auteur du verdict. ASP insère un modèle entre l'alerte et la décision, ce qui permet de traiter des cas que personne n'a eu le temps de modéliser en playbook, mais déplace la question de la confiance vers la qualité du modèle et du prompt. Une équipe qui a déjà investi dans des playbooks matures n'a pas grand-chose à gagner à les réécrire pour y ajouter du LLM. La deuxième alternative est de rester dans le SIEM et d'y construire des tableaux de bord de triage : c'est moins ambitieux, mais cela évite d'ajouter un composant qui détient une copie des alertes et des IOC. Le choix dépend surtout de la contrainte de résidence des données : ASP se déploie entièrement en local, ce qui est l'argument décisif pour les équipes qui ne peuvent pas envoyer leurs alertes à un service tiers.
Coût de maintenance et questions de licence
Le rythme de publication est soutenu : trois versions en un mois environ, v0.5.0 le 4 juillet, v0.5.1 le 11 juillet, v0.5.2 le 28 juillet, avec un dernier push en août. En dessous de la version 1.0, cela signifie que les interfaces de modules et de playbooks peuvent bouger entre deux releases mineures. Toute équipe qui écrit ses propres modules Python doit prévoir de les retester à chaque montée de version, et c'est un coût récurrent, pas un coût d'installation. Le README annonce une licence MIT, ce qui autorise en principe la modification et la redistribution, y compris dans un contexte commercial. Mais la fiche du dépôt indique une licence inconnue, et le fichier LICENSE n'est pas reproduit dans le matériel fourni. Tant que cette divergence n'est pas levée, la prudence s'impose : lisez le fichier LICENSE à la racine du dépôt et, si la réutilisation en interne ou la redistribution est envisagée, faites confirmer la situation. Aucun conseil juridique ici, seulement le constat d'une incohérence documentaire à vérifier avant de s'engager.
Conclusion éditoriale
ASP convient à une équipe SOC qui ingère déjà du SIEM ou du webhook et veut un point d'entrée unique pour l'investigation, sans sortir ses données de son réseau. Il ne convient pas à qui cherche un parseur de logs ou un SIEM : la plateforme consomme des alertes, elle n'en produit pas. Avant tout déploiement, vérifiez trois choses : le fichier LICENSE à la racine du dépôt, la version exacte du schéma de module Python attendue par la release visée, et la manière dont votre flux Splunk ou ELK est normalisé en amont, puisque le format d'entrée conditionne toute la chaîne d'extraction d'IOC.
Notes de la communauté