CISO Assistant : un référentiel GRC auto-hébergé, avec ISO 27001 et NIS2 fournis en standard

Le problème : un contrôle ISO 27001 recopié dans quatre classeurs

Le README part d'un constat que beaucoup d'équipes sécurité reconnaissent : la fragmentation des outils, la duplication des données et l'absence de solutions intégrées et lisibles. Concrètement, un même contrôle se retrouve saisi une fois pour l'audit ISO 27001, une deuxième pour un questionnaire client SOC 2, une troisième pour un dossier NIS2, et une quatrième pour le registre de risques. Chaque mise à jour doit être répétée autant de fois. CISO Assistant vise à faire de cette base de contrôles un objet unique, réutilisé par plusieurs référentiels. Le projet se présente comme un « one-stop-shop » pour la gestion de la cybersécurité, avec une ambition de simplification et d'interopérabilité. Le public visé est nommé sans détour : les équipes cybersécurité et IT, ainsi que les responsables conformité qui pilotent audits, plans d'action et évaluations de risques. Le README précise que l'outil est conçu comme un « hub central » reliant plusieurs concepts de cybersécurité entre eux. C'est un choix de conception, pas un argument marketing : il détermine tout le reste, à commencer par la manière dont les référentiels sont modélisés.

Un contrôle réutilisé par plusieurs référentiels, via le mapping automatique

Le mécanisme central tient en une phrase du README : la conformité est explicitement découplée des contrôles de cybersécurité, ce qui permet leur réutilisation dans toute la plateforme. Autrement dit, un contrôle de sécurité est un objet de premier niveau, et un référentiel réglementaire ne fait que pointer vers lui. Le mapping automatique fait le reste : quand vous évaluez un contrôle une fois, les référentiels qui le référencent héritent du résultat. Le dépôt annonce plus de 200 référentiels pris en charge, dont ISO 27001, NIST CSF, SOC 2, CIS, PCI DSS, NIS2, DORA, GDPR, HIPAA et CMMC. Le README évoque aussi un « format ouvert » permettant de personnaliser et de réutiliser ses propres objets et référentiels, avec une syntaxe simple pour les référentiels maison. La promesse est claire, mais elle a un prix : la qualité du mapping entre référentiels devient un point de dépendance. Si la correspondance entre deux cadres est discutable, l'automatisation propage l'erreur au lieu de la signaler. Le README mentionne un « mapping explorer » dans la liste des fonctionnalités, ce qui suggère que la correspondance reste consultable, sans que l'on puisse en déduire le niveau de détail. Sur ce point, la documentation publique ne permet pas de trancher.

API-first, CLI et Kafka : l'intégration comme surface d'attaque principale

Le projet revendique une approche API-first, avec une API qui sert à la fois l'interface et l'automatisation externe. Un portail de documentation d'API est lié depuis le README, et un badge Swagger y figure. Les capacités d'import et d'export sont décrites comme disponibles par plusieurs canaux : interface, CLI, Kafka et rapports. Pour une équipe qui veut synchroniser un CMDB, un scanner de vulnérabilités ou un outil de ticketing, c'est la partie qui compte le plus. Deux réserves, tirées du matériel fourni. D'abord, le README ne documente pas de schéma d'authentification ni de politique de versionnement de l'API : il faudra consulter le portail d'API pour le savoir. Ensuite, l'intégration Kafka n'est mentionnée qu'en tant que canal d'import/export, sans indication de garanties de livraison. Sur un flux d'événements de conformité, la différence entre « au moins une fois » et « exactement une fois » change la conception du consommateur. Rien dans le README ne permet de conclure, et c'est un point à vérifier avant de brancher un pipeline automatisé sur cette plateforme.

Installation : deux scripts, des images préconstruites, et une branche à éviter

Le démarrage local tient en deux étapes. On clone d'abord le dépôt sur une seule branche : git clone --single-branch -b main https://github.com/intuitem/ciso-assistant-community.git. On lance ensuite le script fourni, ./docker-compose.sh sous Linux ou macOS, ./docker-compose.ps1 sous Windows. Le README précise que le script utilise des images Docker préconstruites couvrant la plupart des architectures matérielles standard. Sous Windows, Docker Desktop avec WSL2 est requis, et le script PowerShell alimente Docker Desktop pour vous. Trois avertissements méritent d'être lus avant de déployer. Le premier concerne les erreurs de correspondance de plateforme entre l'image et l'hôte : le README demande d'ouvrir un ticket avec les détails, et propose en alternative docker-compose-build.sh pour compiler pour votre architecture. Le deuxième, plus important, interdit d'utiliser directement le code de la branche main en production, car elle reçoit les fusions et peut contenir des changements cassants. Il faut passer par les tags ou les images préconstruites. Le troisième indique que le fichier docker compose peut être ajusté pour transmettre des paramètres supplémentaires, par exemple les réglages du mailer. Pour d'autres options d'auto-hébergement, le README renvoie vers le répertoire config/ et la documentation GitBook. Aucun prérequis de version n'est donné pour Docker ou Docker Compose.

Licence NOASSERTION : le point à éclaircir avant tout déploiement

GitHub affiche l'identifiant de licence NOASSERTION pour ce dépôt, ce qui signifie que la plateforme n'a pas su reconnaître un texte de licence standard. Le README, lui, met en avant un essai gratuit d'une instance cloud et renvoie vers intuitem.com. Cette combinaison, code public et offre hébergée commerciale, est fréquente, mais elle empêche toute conclusion automatique sur ce que vous avez le droit de faire. La question n'est pas théorique : si votre organisation revend un service bâti sur cet outil, ou l'intègre dans une offre destinée à des tiers, la réponse dépend d'un texte que GitHub n'a pas su identifier. Le README ne tranche pas non plus sur la gouvernance du projet ni sur un éventuelCLA. Ce texte ne constitue pas un conseil juridique : la seule action utile est d'ouvrir le fichier LICENSE à la racine du dépôt et de le faire lire par qui de droit. Tant que ce point n'est pas clos, l'évaluation technique reste secondaire.

Le rythme de publication impose une politique de mise à jour

Les versions récentes montrent une cadence soutenue : v3.21.3 le 26 août, v3.21.4 le 1er septembre, puis v4.0.1 le 5 septembre. Le passage de 3.21 à 4.0 signale une rupture de compatibilité, même si le README ne détaille pas laquelle. Pour une plateforme qui stocke des évaluations de conformité et des registres de risques, ce rythme a deux conséquences pratiques. La première est que la procédure de mise à jour doit inclure une sauvegarde vérifiée de la base avant chaque saut de version mineure ou majeure, et un test de restauration. La deuxième est qu'il faut lire les notes de version avant de suivre les tags, en particulier autour d'un changement de majeure. Le README ne décrit ni procédure de migration ni politique de support des versions antérieures. Rien n'indique non plus de fenêtre de maintenance recommandée. Ce sont des éléments à demander à la communauté avant de placer l'outil au centre d'un processus d'audit.

Face à un tableur GRC, la vraie différence est le découplage

L'alternative la plus courante n'est pas un autre logiciel : c'est un classeur partagé, ou une suite bureautique enrichie de macros. La différence d'approche est structurelle. Dans un tableur, chaque référentiel est une feuille, et la correspondance entre deux cadres vit dans une colonne tenue à la main. CISO Assistant place le contrôle au centre et fait pointer les référentiels vers lui, ce qui rend la réutilisation native plutôt que déclarative. Le README insiste sur ce point : la conformité et les contrôles sont découplés pour permettre leur réutilisation. Un tableur ne sait pas faire cela sans duplication, et c'est précisément la duplication que le projet cible. L'autre différence tient à l'API. Un classeur n'expose pas d'interface programmable stable, donc toute automatisation finit en scripts fragiles. Cela dit, le tableur a un avantage que CISO Assistant n'annonce pas : il ne demande ni Docker, ni sauvegarde de base, ni gestion de versions. Pour une équipe de deux personnes suivant un seul référentiel, l'écart de coût d'exploitation joue en faveur du tableur.

Ce qu'il faut vérifier avant d'installer

Trois vérifications préalables, toutes traçables dans le matériel fourni. D'abord, ouvrir le fichier LICENSE et faire trancher la question juridique, puisque GitHub affiche NOASSERTION. Ensuite, choisir explicitement entre un tag stable et la branche main : le README interdit la seconde en production, et la cadence des versions montre que ce n'est pas une précaution de principe. Enfin, tester le mapping automatique sur vos propres référentiels avant de généraliser, car c'est lui qui porte la valeur du produit et aussi son principal risque d'erreur silencieuse. Si votre périmètre se limite à un référentiel unique et à un inventaire de contrôles, l'outil est probablement surdimensionné. S'il couvre plusieurs cadres réglementaires et que vous voulez brancher vos scanners et votre ticketing par API, la question devient celle de la licence, pas celle des fonctionnalités.

Conclusion éditoriale

CISO Assistant s'adresse aux équipes qui doivent croiser plusieurs référentiels (ISO 27001, NIS2, SOC 2) sans multiplier les tableurs, et qui acceptent d'exploiter elles-mêmes une stack Docker. À éviter si vous cherchez un service managé ou un simple inventaire d'actifs. Avant d'engager quoi que ce soit, lisez le fichier LICENSE du dépôt : l'identifiant affiché est NOASSERTION, et le README oriente vers une offre cloud.

Sources officielles

1. intuitem/ciso-assistant-community on GitHub
2. Issues
3. Project website
4. README
5. Releases