Ressources · Intégration n8n

Intégration TheHive n8nAutomatiser TheHive avec n8n.

Une alerte tombe dans TheHive, et le workflow démarre tout seul. L'intégration TheHive n8n réunit un trigger, le nœud de départ qui écoute 14 événements sur les alertes, les cas, les tâches, les logs et les observables, et un nœud qui expose 4 opérations sur la ressource Log.

Tester l'intégration TheHive sur n8nVoir les 4 opérations

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

À quoi sert l'intégration TheHive n8n ?

L'intégration TheHive n8n relie ta plateforme de réponse à incident au reste de tes outils. Un nœud lit et écrit dans TheHive, un second lance un workflow dès qu'une alerte, un cas ou une tâche bouge. Les deux parlent à TheHive 3 et TheHive 4, via une clé d'API que tu crées dans ta propre instance, sans passer par le portail d'un éditeur.

Premier scénario : l'ouverture de cas. Un analyste transforme une alerte en investigation, case_create part, et le workflow prépare le terrain. Il écrit la première ligne de contexte dans la tâche de triage avec Create a log, puis alimente un registre partagé dans Google Sheets que la direction consulte sans jamais ouvrir TheHive.

Deuxième scénario : l'enrichissement d'observable. Une adresse IP ou un hash arrive dans le cas, case_artifact_create déclenche, n8n interroge tes sources de renseignement et reverse le verdict dans la chronologie de la tâche. Si le résultat est mauvais, un message part sur Slack pendant que l'analyste est encore dessus. Personne ne rafraîchit une page en attendant.

Troisième scénario : l'archivage. À la clôture, Get many logs récupère toutes les entrées d'une tâche, Return All parcourt les pages de l'API au lieu de s'arrêter au premier paquet, et l'ensemble atterrit dans une table MySQL qui sert de mémoire au service. Reconstituer une chronologie six mois plus tard devient une requête, pas une fouille.

Maintenant la partie honnête. Le catalogue expose 4 opérations, toutes sur la ressource Log. Le nœud couvre 5 ressources (Alert, Case, Log, Observable et Task), mais la liste que n8n t'affiche dépend de la version d'API choisie dans le credential, la connexion enregistrée une fois pour toutes : crée-le d'abord, choisis la version, reviens ensuite sur le nœud. Ce qui manque reste accessible avec HTTP Request, qui appelle n'importe quel endpoint de TheHive en réutilisant ce même credential.

Deux limites à garder en tête. Ce nœud vise les API version 3 et version 4 : un serveur TheHive 5 passe par le nœud TheHive 5, pas par celui-ci. Et le trigger n'enregistre pas son webhook tout seul, tu le déclares dans le fichier de configuration de ton serveur. Si tu compares encore les plateformes, l'Avis n8n traite le sujet, et la Formation n8n reprend la construction d'un workflow depuis zéro.

Connexion

Comment connecter TheHive à n8n ?

  1. 01

    Générer une clé d'API dans TheHive

    TheHive tourne sur ton serveur, donc la clé vient de ton instance et pas d'un portail éditeur. Va dans Organization > Create API Key et copie la valeur tout de suite. Cette clé porte les droits du compte qui la détient : un workflow qui écrit des logs dans des tâches n'a pas besoin d'un compte administrateur. Crée un compte de service avec les droits utiles, ton journal d'audit restera lisible.

  2. 02

    Remplir le credential côté n8n

    Dans n8n, ouvre le menu Credentials et ajoute un credential TheHive. Colle l'API Key, puis renseigne l'URL de ton serveur TheHive, celle que tes analystes ouvrent dans leur navigateur. Un credential se crée une fois et se réutilise dans tous les workflows : le nœud le propose dans sa liste déroulante. Le jour où tu tournes la clé, tu la changes à un seul endroit.

  3. 03

    Choisir la version d'API, puis rouvrir le nœud

    Le champ API Version propose TheHive 3 (api v0) et TheHive 4 (api v1), et ce choix commande ce que le nœud sait faire. Ignore SSL Issues autorise n8n à se connecter même si la validation du certificat échoue, le cas classique d'une instance interne en certificat auto-signé. Enregistre, retourne sur le nœud, sélectionne une ressource : les opérations de ta version apparaissent.

Déclencheurs

Qu'est-ce qui déclenche un workflow depuis TheHive ?

TheHive Trigger est le nœud qui démarre un workflow quand quelque chose se passe dans TheHive. Il écoute 14 événements, listés ci-dessous par famille. Tu en choisis un ou plusieurs, tu actives le workflow : n8n enregistre le webhook (l'URL que TheHive appelle) sur ton compte.

Ce que tu vois dans n8n

Tous les événements, par famille

Une ligne par objet, une puce par action. L'événement à cocher dans le nœud s'écrit objet.action ; survole une puce pour lire quand il se déclenche.

alert_create.*1
  • alert_create.
    • alert_create
alert_delete.*1
  • alert_delete.
    • alert_delete
alert_update.*1
  • alert_update.
    • alert_update
case_artifact_create.*1
  • case_artifact_create.
    • case_artifact_create
case_artifact_delete.*1
  • case_artifact_delete.
    • case_artifact_delete
case_artifact_update.*1
  • case_artifact_update.
    • case_artifact_update
case_create.*1
  • case_create.
    • case_create
case_delete.*1
  • case_delete.
    • case_delete
case_task_create.*1
  • case_task_create.
    • case_task_create
case_task_log_create.*1
  • case_task_log_create.
    • case_task_log_create
case_task_log_delete.*1
  • case_task_log_delete.
    • case_task_log_delete
case_task_log_update.*1
  • case_task_log_update.
    • case_task_log_update
case_task_update.*1
  • case_task_update.
    • case_task_update
case_update.*1
  • case_update.
    • case_update

Le trigger accepte aussi * (tout événement). Pratique pour du log, dangereux en production.

Notes de configuration

01Configure the TheHive TriggerLe TheHive Trigger lance un workflow quand ton instance signale une activité. Il fonctionne par webhook, c'est-à-dire une URL que TheHive appelle au moment où l'événement se produit : l'exécution part en quelques secondes, sans interrogation régulière de l'API.

Le TheHive Trigger lance un workflow quand ton instance signale une activité. Il fonctionne par webhook, c'est-à-dire une URL que TheHive appelle au moment où l'événement se produit : l'exécution part en quelques secondes, sans interrogation régulière de l'API.

Paramètres clés

  • Events : la liste de ce à quoi tu veux réagir, 14 entrées en tout. Garde le joker * pour tout capter et filtrer plus loin dans le workflow, ou coche uniquement ce qui te sert et ta liste d'exécutions reste lisible.
Quand l'utiliser
le nœud est en version 2 et n'enregistre pas le webhook à ta place. Copie les URL de test et de production depuis le trigger, ajoute-les dans notification.webhook.endpoints du fichier application.conf de ton serveur, nomme chaque endpoint, indique ton organisation, puis lance la commande cURL documentée sur /api/config/organisation/notification pour activer les notifications.
Cas d'usage
un workflow activé par réaction à automatiser, plutôt qu'un analyste qui surveille une file entre deux investigations.
02Alert Created, Alert Updated, Alert DeletedL'alerte, c'est ce qui arrive dans TheHive avant que quiconque décide d'en faire une investigation : une détection SIEM, un signalement de boîte mail, un flux. Trois événements couvrent toute sa vie, et c'est de là que partent la plupart des workflows.

L'alerte, c'est ce qui arrive dans TheHive avant que quiconque décide d'en faire une investigation : une détection SIEM, un signalement de boîte mail, un flux. Trois événements couvrent toute sa vie, et c'est de là que partent la plupart des workflows.

Paramètres clés

  • Events : coche Alert Created (alert_create) pour toute nouveauté, Alert Updated (alert_update) quand la gravité ou le statut change, Alert Deleted (alert_delete) quand une alerte est écartée.
Quand l'utiliser
la création est ton point d'accroche pour l'enrichissement, parce que c'est le seul moment où tu as encore le temps d'ajouter du contexte avant qu'un humain lise. La mise à jour sert à l'escalade : une gravité qui monte, c'est souvent quelqu'un qui vient d'apprendre quelque chose. La suppression, garde-la pour la traçabilité.
Cas d'usage
une alerte arrive, le workflow interroge tes sources de réputation et dépose ce qu'il a trouvé en log de tâche, lisible directement dans le cas.
03Case Created, Case Updated, Case DeletedLe cas, c'est l'investigation elle-même, le conteneur dans lequel les analystes travaillent pendant des heures ou des jours. Ses trois événements servent surtout à tenir le reste de l'entreprise au courant sans que personne rédige un point d'avancement.

Le cas, c'est l'investigation elle-même, le conteneur dans lequel les analystes travaillent pendant des heures ou des jours. Ses trois événements servent surtout à tenir le reste de l'entreprise au courant sans que personne rédige un point d'avancement.

Paramètres clés

  • Events : Case Created (case_create) ouvre l'histoire, Case Updated (case_update) couvre chaque modification en cours de route, Case Deleted (case_delete) la referme.
Quand l'utiliser
la création va bien avec tout ce qui doit exister en parallèle de l'investigation, un ticket, un canal, un dossier. La mise à jour part souvent : filtre-la tôt sur le champ qui t'intéresse au lieu de faire tourner un workflow complet à chaque édition. Ton historique d'exécutions te remerciera.
Cas d'usage
un cas s'ouvre, le workflow crée le ticket correspondant dans l'outil de gestion et renvoie la référence en log de tâche, pour que les deux systèmes se pointent l'un l'autre.
04Task, Log and Observable eventsSous les cas se trouvent les objets que les analystes manipulent vraiment : les tâches à faire, les logs qui racontent ce qui a été fait, les observables qui portent les indicateurs techniques. Huit événements les couvrent.

Sous les cas se trouvent les objets que les analystes manipulent vraiment : les tâches à faire, les logs qui racontent ce qui a été fait, les observables qui portent les indicateurs techniques. Huit événements les couvrent.

Paramètres clés

  • Events : Task Created (case_task_create) et Task Updated (case_task_update) ; Log Created (case_task_log_create), Log Updated (case_task_log_update) et Log Deleted (case_task_log_delete) ; Observable Created (case_artifact_create), Observable Updated (case_artifact_update) et Observable Deleted (case_artifact_delete).
Quand l'utiliser
la création d'observable est la plus rentable des trois, parce qu'un indicateur frais est exactement ce que tu veux envoyer en analyse avant qu'un analyste le demande. Les événements de tâche suivent qui fait quoi. Attention avec les logs : un workflow qui écrit des logs et écoute les événements de log peut se nourrir lui-même, filtre sur l'auteur.
Cas d'usage
un observable apparaît, le workflow le compare à ta liste de blocage et rend son verdict dans la chronologie de la tâche.
Actions

Que sait faire le nœud TheHive ?

Le nœud TheHive expose 4 opérations sur 5 ressources. Pour chacune : le nœud tel que tu le configures dans n8n, les champs obligatoires, et nos notes de terrain.

Matrice ressources × opérations
RessourceCreateGetGet ManyExecute Responder
Alert
Case
Log✓✓✓✓
Observable
Task

Alert

0 opérations

Case

0 opérations

Log

4 opérations
01

Create a log

log.create

Ce que tu vois dans n8n

Notes & cas d'usage

Ajoute une entrée dans la chronologie d'une tâche TheHive. C'est comme ça qu'une étape automatique laisse une trace qu'un analyste relira.

Paramètres clés

  • Task ID : l'identifiant de la tâche concernée, souvent {{ $json.id }} repris d'un événement Task Created.
  • Message : le contenu du log, le texte assemblé par les nœuds précédents.
  • Start Date : la date de soumission, déjà réglée sur maintenant ; on n'y touche que pour rattraper un historique.
  • Status : Ok ou Deleted, Ok par défaut.
  • Attachment : dans la collection Options, joint un fichier à l'entrée.
Cas d'usage
un bac à sable rend son verdict, le workflow le dépose dans la tâche d'investigation. L'analyste lit une chronologie au lieu de trois onglets.
02

Execute a responder

log.executeResponder

Ce que tu vois dans n8n

Notes & cas d'usage

Lance un des responders configurés sur ton instance contre une entrée de log précise. L'action se joue dans TheHive, pas dans le workflow.

Paramètres clés

  • Log ID : l'identifiant de l'entrée visée, récupéré d'un événement Log Created ou d'un Get many logs.
  • Responder Name or ID : à choisir dans la liste que ton instance expose, ou à fournir sous forme d'identifiant via une expression, une valeur comme {{ $json.id }} reprise d'un nœud précédent, quand le choix dépend de la donnée.
Cas d'usage
une validation arrive depuis l'outil de ticketing, et le workflow déclenche le responder correspondant sur le log qui l'avait demandée. La décision s'applique sans que personne retourne dans l'interface.
03

Get many logs

log.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Lit les entrées rattachées à une tâche et les renvoie en items séparés, un par log, prêts pour le nœud suivant.

Paramètres clés

  • Task ID : la tâche dont tu veux lire la chronologie.
  • Return All : activé, n8n enchaîne les pages de l'API jusqu'à récupérer toutes les entrées.
  • Limit : le plafond quand Return All est désactivé, pratique en phase de test pour qu'une tâche bavarde ne noie pas l'exécution.
Cas d'usage
en fin d'investigation, le workflow rassemble la chronologie complète de chaque tâche et la range dans une table de reporting. Plus besoin de reconstituer l'enchaînement des faits à la main.
04

Get a log

log.get

Ce que tu vois dans n8n

Notes & cas d'usage

Récupère une seule entrée et renvoie son contenu actuel, ce qui compte quand le log a été écrit il y a dix minutes et a pu changer depuis.

Paramètres clés

  • Log ID : l'identifiant de l'entrée, pas son message. Un événement Log Updated te le donne directement, un appel précédent dans le même workflow aussi.
Cas d'usage
un workflow attend qu'un collègue complète une entrée avant de continuer, et la relit pour confirmer que le contenu est bien là. C'est aussi le moyen le plus rapide de vérifier une écriture : le même identifiant renvoie exactement ce que TheHive a stocké.

Observable

0 opérations

Task

0 opérations
Besoin d'aide

Besoin d'aide pour automatiser TheHive avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

TheHive et n8n, les questions qui reviennent

01L'intégration TheHive n8n est-elle gratuite ?
Oui. Le nœud TheHive et le TheHive Trigger sont livrés avec n8n : rien à installer, aucun coût supplémentaire côté n8n. C'est vrai sur n8n Cloud, l'offre hébergée par n8n, comme sur une instance auto-hébergée en Community Edition sous licence Sustainable Use. Un workflow se comporte de la même façon dans les deux cas, donc tu peux prototyper d'un côté et faire tourner de l'autre sans tout réécrire. TheHive, lui, tourne sur ton propre serveur : ce qu'il te coûte dépend de ton installation, pas de n8n.
02Quels credentials faut-il pour connecter TheHive à n8n ?
Une clé d'API, créée dans ton instance via Organization puis Create API Key. Le credential n8n demande cette clé, l'URL de ton serveur TheHive, et la version d'API : TheHive 3 en api v0 ou TheHive 4 en api v1. Un interrupteur Ignore SSL Issues existe pour les instances en certificat auto-signé. La clé porte les droits du compte qui la détient, donc un compte de service limité à ce dont le workflow a besoin vaut mieux qu'une clé administrateur. Tu remplis le credential une fois, tous tes workflows le sélectionnent ensuite.
03Quelles sont les limites du nœud TheHive dans n8n ?
Le catalogue expose 4 opérations, toutes sur la ressource Log, alors que le nœud couvre 5 ressources au total : Alert, Case, Log, Observable et Task. La liste réellement affichée dépend de la version d'API enregistrée dans le credential, donc crée le credential avant de rouvrir le nœud. En lecture, c'est Return All qui va chercher toutes les pages de résultats ; sans lui, tu t'arrêtes au Limit que tu as fixé. Ce que le nœud ne propose pas reste atteignable avec HTTP Request, qui appelle n'importe quel endpoint de TheHive avec le même credential.
04Le TheHive Trigger réagit-il en temps réel ?
Oui, parce qu'il fonctionne par webhook et non par interrogation régulière. TheHive appelle une URL n8n au moment où l'événement se produit, l'exécution démarre donc en quelques secondes au lieu d'attendre le prochain passage. Un point à prévoir : ce trigger ne s'enregistre pas tout seul. Tu copies les URL de test et de production depuis le nœud, tu les déclares comme endpoints de webhook dans le fichier application.conf de ton serveur avec le nom de ton organisation, puis tu lances la commande cURL de la documentation n8n pour activer les notifications. Ensuite, les 14 événements arrivent seuls.
05n8n ou Make pour TheHive ?
Tout se joue sur l'endroit où vivent les données. Si TheHive est auto-hébergé, c'est rarement un hasard, et n8n s'auto-héberge aussi, en Docker ou en npm : le contenu des alertes et des cas ne sort jamais de ton infrastructure. Make est uniquement hébergé, et facturé à l'opération, ce qui se calcule quand un trigger bavard tourne toute la journée. Les deux offrent un éditeur visuel. n8n ajoute un nœud de code et le repli HTTP Request, utile ici puisque le nœud couvre une ressource sur 5. Si ta politique de sécurité le permet et que tu ne veux aucune infrastructure, Make reste une réponse valable.
Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations