Niubi Guard est un outil open source qui aide les mainteneurs GitHub à repérer le spam, le harcèlement et les campagnes coordonnées dans les Issues et commentaires. Mon verdict court : ça vaut le coup de l’essayer si vous gérez un dépôt exposé, mais je ne le laisserais pas agir tout seul sans revue humaine.
Niubi Guard, c’est quoi ?
Niubi Guard se présente comme un système de défense pour mainteneurs GitHub. L’idée est simple : vous donnez une liste de dépôts, des règles de détection, éventuellement un modèle compatible OpenAI, puis l’outil scanne les Issues et les commentaires.
Il ne promet pas de dire la vérité à la place du mainteneur. Il produit plutôt un rapport de risque avec des labels, des raisons, un score, et des actions proposées. Par défaut, il fonctionne en dry run, donc il n’applique rien tant que vous ne passez pas volontairement en mode action.
Sur le papier, c’est sain. En sécurité et DevOps, je préfère largement un outil qui montre son raisonnement à un outil magique qui supprime des commentaires dans le noir.
| Point testé | Résultat observé |
|---|---|
| Type de projet | CLI Node.js, librairie TypeScript, interface Next.js |
| Installation | pnpm install, tests et build lib OK |
| Détection par règles | OK sur mots clés, utilisateurs bannis, comptes récents |
| Détection IA | OK via proxy OpenAI compatible local |
| Sortie produite | Rapport JSON avec risques, preuves LLM et actions proposées |
| Mode destructif | Non testé en réel, uniquement dry run volontaire |
Installation de Niubi Guard
J’ai cloné le dépôt dans /tmp, lu le README, le package.json, le code de la CLI, du scanner, du client GitHub et de l’adaptateur LLM. Le projet demande Node 20 minimum et utilise pnpm.
Premier détail pratique : dans mon environnement, /tmp ne permettait pas d’exécuter le binaire esbuild installé par pnpm. J’ai donc gardé le clone canonique dans /tmp, puis installé une copie de travail temporaire dans un dossier scratch, supprimé ensuite.
Les commandes de base que j’ai utilisées :
git clone https://github.com/Albert-Weasker/niubi_guard /tmp/niubi_guard_scout
cd /workspace/scout-albert-weasker-niubi-guard/.scratch/work
pnpm install
pnpm test
pnpm build:lib
J’ai aussi lancé l’interface web Next.js avec :
pnpm dev:web
Puis j’ai capturé la page avec Chromium headless. L’interface sert surtout à construire une politique de scan : token GitHub, dépôts, règles, seuil IA, mode review, actions possibles.
Niubi Guard à l’usage
Pour éviter de dépendre d’un vrai dépôt GitHub à modérer et pour ne pas utiliser de clé personnelle, j’ai testé le coeur du produit avec un client GitHub de fixture. Ce client renvoie trois événements réalistes :
- une Issue agressive accusant un projet d’acheter des étoiles, postée par un compte tout neuf,
- une Issue de divulgation sécurité formulée proprement, contenant une phrase autorisée,
- un commentaire de spam avec liens répétés et utilisateur déjà bloqué par règle.
J’ai activé les règles par mots clés, les utilisateurs interdits, le signal de compte récent, et la détection IA via le proxy OpenAI compatible fourni. Le modèle configuré était openai/gpt-4o-mini, avec une base locale compatible OpenAI.
La configuration LLM ressemblait à ceci :
{
"enabled": true,
"baseUrl": "http://172.17.0.1:8790/v1",
"apiKey": "sk-proxy",
"model": "openai/gpt-4o-mini",
"confidenceThreshold": 0.7,
"reviewMode": "auto_plan"
}
La sortie intéressante n’est pas juste le démarrage. Niubi Guard a produit un vrai rapport de scan : 1 dépôt, 3 événements scannés, 2 détections, 0 erreur. L’Issue de divulgation sécurité a été ignorée grâce à l’allowlist, ce qui est exactement le comportement attendu.
Sur l’Issue agressive, Niubi Guard a combiné deux signaux : compte récent et verdict LLM malveillant. Le modèle a renvoyé le label fake_star_accusation, une confiance de 0,95, et des preuves textuelles. Le score de risque final est monté à 95.
Sur le commentaire de spam, le moteur a trouvé les mots clés, l’utilisateur interdit et un verdict IA de type spam. Le score est monté à 100. En dry run, les actions ont été listées mais pas appliquées : fermer l’Issue, verrouiller l’Issue, supprimer le commentaire, bloquer l’utilisateur.
C’est ce que j’attendais d’un outil de modération défensive : un plan d’action lisible avant toute action destructive.
Est-ce que Niubi Guard marche vraiment ?
Oui, sur le scénario que j’ai exécuté, le coeur fonctionne. Les tests du dépôt passent, le build TypeScript de la librairie passe, l’interface web démarre, et le scanner produit un rapport cohérent.
J’ai vérifié trois choses concrètes :
- les tests officiels passent, 17 tests en succès,
pnpm build:libcompile la surface CLI et librairie,- le scan de démonstration appelle réellement le proxy LLM et intègre sa réponse au rapport.
Le point important : la sortie inclut à la fois les signaux déterministes et le résultat IA. On peut donc distinguer un spam évident, un compte suspect, et une accusation plus sémantique détectée par modèle.
Ce que j’aime dans Niubi Guard
J’aime le choix du dry run par défaut. C’est le bon réflexe pour un outil qui peut fermer, verrouiller, supprimer ou bloquer.
J’aime aussi la structure du rapport. Chaque détection contient :
- les labels,
- les mots clés trouvés,
- l’utilisateur concerné,
- le score de risque,
- la raison,
- le résultat LLM,
- les actions proposées.
Autre bon point : la configuration est explicite. Les actions destructives sont toutes à false par défaut. On choisit ce que l’on veut autoriser, dépôt par dépôt.
Enfin, l’adaptateur IA est simple et compatible OpenAI. Pour un mainteneur qui veut passer par OpenRouter, un proxy interne ou un modèle hébergé, c’est beaucoup plus pratique qu’une intégration fermée.
Les limites de Niubi Guard
La première limite, c’est GitHub. La CLI demande un GITHUB_TOKEN, et le client GitHub officiel n’expose pas dans la config un moyen simple de pointer vers une API GitHub mockée ou Enterprise. Pour mon test sans secret réel, j’ai donc exercé le scanner via la librairie avec un client fixture, pas via une vraie modération de dépôt public.
Deuxième limite : le mode IA dépend fortement du modèle et du prompt. Sur mon cas, le verdict était bon. Mais pour un dépôt très conflictuel, un faux positif peut vite devenir coûteux si l’on active les actions automatiques.
Troisième limite : le projet est encore jeune. La roadmap parle de file de revue, labels, gestion des faux positifs, empreintes de menace et GitHub App. Ce sont justement les briques qui feraient passer l’outil d’un bon prototype opérationnel à une vraie console de défense quotidienne.
Je note aussi un petit frottement de packaging : sur un /tmp monté sans exécution, l’installation directe dans le clone échoue à l’étape esbuild. Ce n’est pas forcément la faute du projet, mais c’est un cas courant dans des sandboxes CI ou sécu.
Faut-il adopter Niubi Guard ?
Mon verdict : à essayer, pas à brancher en pilote automatique dès le premier jour.
Si vous maintenez un dépôt open source qui attire du spam, des commentaires copiés collés ou des accusations répétitives, Niubi Guard peut déjà servir de radar. Je l’utiliserais d’abord en dry run, avec un seuil IA strict, puis je comparerais ses décisions à une revue humaine pendant quelques jours.
Pour une petite équipe, le meilleur usage est probablement : scanner, produire un rapport, décider manuellement. Pour une grosse organisation open source, il manque encore une vraie file de tri, des métriques de faux positifs et une intégration GitHub App plus fluide.
Mais la base est propre. Le produit ne vend pas de magie. Il lit les événements, applique des règles, interroge un modèle si demandé, puis sort un plan d’action vérifiable. En 2026, pour protéger un dépôt GitHub exposé, c’est déjà une brique utile.
FAQ
Niubi Guard peut-il supprimer automatiquement des commentaires ?
Oui, mais seulement si vous activez les actions concernées et lancez le mode application. Par défaut, le dry run liste les actions sans les exécuter.
Niubi Guard a-t-il besoin d’une clé OpenAI ?
Seulement si vous activez la détection IA. Il accepte une base URL compatible OpenAI, donc vous pouvez utiliser OpenAI, OpenRouter ou un proxy interne.
Niubi Guard remplace-t-il un mainteneur humain ?
Non. Il aide à prioriser et documenter les décisions de modération. Je le vois comme un assistant de tri, pas comme un juge automatique.