AiSOC unifie l'investigation des alertes et récolte 436 étoiles en une journée

Une équipe de sécurité manque rarement de signaux. C'est généralement l'inverse : la messagerie signale une connexion suspecte, le journal cloud un nouveau jeton, l'EDR le lancement d'un processus étrange. Chaque alerte vit dans son propre panneau, et l'ingénieur doit déterminer manuellement si elles relèvent d'une même attaque. AiSOC propose de centraliser cette analyse : regrouper les événements, confier à un agent le tri initial et conserver l'explication de chacune de ses étapes.

Le dépôt beenuar/AiSOC est entré dans le top quotidien de GitHub Trending et a gagné 436 étoiles en une journée. Le projet en compte 5 862 au total. Ce n'est pas encore une preuve de maturité, mais c'est une bonne raison d'examiner l'approche : un centre d'opérations de sécurité ouvert, que l'on peut déployer chez soi, dont on peut étudier le code et qu'on peut adapter sans acheter de plateforme propriétaire.

À quoi ressemble une investigation

Imaginons trois événements. À 10:02, un employé se connecte au cloud depuis une nouvelle adresse. À 10:05, un jeton d'accès est créé pour son compte. À 10:11, une lecture massive de fichiers commence. Pris isolément, le premier peut correspondre à un déplacement, le deuxième au travail normal d'un développeur, le troisième à une sauvegarde. Ensemble, ils ressemblent déjà à une séquence d'actions d'un attaquant.

AiSOC regroupe ces signaux dans une seule investigation. L'agent rapproche le comportement observé des techniques MITRE ATT&CK, formule une évaluation préliminaire et laisse un journal des décisions. Cette dernière partie est essentielle : l'ingénieur ne voit pas seulement le verdict final, mais aussi les événements qui ont influencé la conclusion. L'investigation peut être rejouée après une modification des règles ou du modèle, et les résultats comparés.

Le projet se présente comme autonome : il peut être déployé en local, sans clé d'API externe. La licence MIT permet de modifier le code et de l'intégrer à son propre périmètre. Un serveur MCP distinct permet de connecter les fonctions d'AiSOC à Claude, Cursor et Continue, par exemple pour analyser un incident depuis une interface d'agent familière.

Où se situe l'intérêt réel

Pour une petite équipe, c'est un moyen de tester un scénario agentique sans des mois de développement d'un SOC maison. On peut prendre une archive d'incidents anonymisés, les rejouer et mesurer trois choses : combien d'alertes liées le système a réellement regroupées, combien d'épisodes dangereux il a manqués et combien de fausses alertes il a générées. Ce n'est qu'après un tel test qu'il est raisonnable de lui donner accès au flux de production.

Pour les développeurs, le journal reproductible est intéressant. Un système agentique sans historique de décisions devient vite une boîte noire : le modèle a changé, la réponse a changé, et la cause reste inconnue. Enregistrer les événements d'entrée, les outils appelés et les conclusions intermédiaires facilite le débogage et l'audit.

Ce qu'il faut vérifier avant le déploiement

GitHub Trending mesure l'attention, pas la fiabilité. Avant un pilote, il convient d'étudier le modèle de menaces d'AiSOC lui-même, le schéma de stockage des journaux, la séparation des accès et la gestion des secrets. Le serveur MCP élargit lui aussi la surface d'attaque : ses outils doivent fonctionner avec des droits minimaux, et les données entrantes ne doivent jamais être traitées comme des instructions de confiance.

Il ne faut pas autoriser d'emblée l'agent à bloquer des utilisateurs, révoquer des jetons ou modifier des règles réseau. Un premier mode sûr est la lecture seule avec recommandations et confirmation humaine obligatoire. Les résultats doivent ensuite être comparés aux décisions des analystes sur des données historiques.

La conclusion pratique est simple : AiSOC est intéressant non pas pour la promesse de « remplacer le SOC par l'intelligence artificielle », mais pour sa tentative de réunir, dans un projet ouvert, des alertes dispersées, une analyse agentique et un historique de décisions vérifiable. Le développeur gagnera à étudier l'architecture du journal et l'intégration MCP. Le responsable produit devrait lancer un pilote limité et définir à l'avance des métriques pour les alertes manquées, les fausses alertes et la durée d'investigation.