Zabbix Threat Control (ztc)

Transformez le Zabbix que vous exécutez déjà en console de gestion des vulnérabilités.

ztc lit l'inventaire logiciel de chaque hôte via le zabbix-agent2 standard (aucun agent supplémentaire à déployer), l'audite auprès de Vulners, et renvoie dans Zabbix des résultats notés, par hôte — problèmes, tableaux de bord et graphiques CVSS. Un binaire statique, installé en une seule commande.

Pourquoi ztc

• Aucun nouvel agent, aucune RCE. Les hôtes remontent leur inventaire via les UserParameters standard de zabbix-agent2. La remédiation passe par une seule clé autorisée + un sudoers restreint — jamais de system.run arbitraire.
• Linux et Windows. Paquets Linux via Vulners audit/linux ; logiciels du registre Windows via Smart Audit et KB installés via audit/kb (avec CVSS par CVE). Smart Audit est indépendant de la version de Zabbix.
• Zabbix 6.0, 7.0, 7.4 et 8.0. Détection automatique de la version de l'API ; aucune branche par version à maintenir de votre côté.
• Exploitable, pas juste une liste. Les résultats deviennent des problèmes Zabbix notés par sévérité CVSS, filtrables par hôte, avec des graphiques de CVSS médian et de distribution des scores sur un tableau de bord prêt à l'emploi.
• Un seul binaire. Installation en une commande ; il se met à jour tout seul.

Démarrage rapide

Sur votre serveur Zabbix (ou tout hôte Linux pouvant atteindre Zabbix + Vulners) :

curl -fsSL https://raw.githubusercontent.com/vulnersCom/zabbix-threat-control/master/deploy/install.sh | sudo sh

L'installateur demande votre clé API Vulners et la connexion Zabbix, installe un service systemd, et propose de créer les entités Zabbix (ztc provision --all). Ensuite, liez le modèle de collecte aux hôtes que vous voulez auditer — voir docs/guide.md.

Autres options (Docker, manuel, réseau isolé, bootstrap-via-Zabbix) : deploy/README.md.

Comment ça marche

 hosts: zabbix-agent2  UserParameter
   Linux   → vulners.os / version / arch / packages
   Windows → vulners.os / version / win.software / win.kb
        │   (polled into Zabbix items)
        ▼
   ztc scan ─► collect (Zabbix API) ─► audit (Vulners) ─► aggregate ─► sender ─► Zabbix
                                                                           │
        problems (CVSS severity) · dashboard · graphs · vulners.host tags ◄┘

ztc scan --daemon exécute la boucle selon un planning ; ztc provision crée le modèle Zabbix, les hôtes de rapport, les déclencheurs et le tableau de bord.

Ce que vous obtenez dans Zabbix

• Hôtes de rapport : Vulners - Hosts, - Bulletins, - Packages, - Statistics.
• Tableau de bord avec une vue d'ensemble Problèmes par sévérité, des listes de problèmes par rapport, une tendance Score CVSS médian et un camembert de distribution des scores CVSS.
• Problèmes notés par sévérité — chaque résultat déclenche en Catastrophique / Élevé / Moyen / Avertissement selon son CVSS, donc Problèmes par sévérité est pertinent.
• Filtre par hôte — chaque résultat porte une balise vulners.host. Dans Monitoring → Problems, filtrez Tags: vulners.host Equals <host> pour voir les vulnérabilités d'un hôte. (Un résultat = un couple (vulnérabilité, hôte).)

Tendance du CVSS médian et distribution des scores sur l'ensemble du parc :

Répartition par sévérité — de vrais compteurs Catastrophique / Élevé / Moyen / Avertissement, pas une barre grise « Non classé » :

Vulnérabilités d'un hôte via le filtre par balise vulners.host :

Un résultat unique — noté par CVSS, balisé avec son hôte, lié à vulners.com :

Configuration

Tout a une valeur par défaut ; fournissez les secrets via des variables d'environnement (elles surchargent le fichier YAML). Exemple complet : config.example.yaml.

ztc --help liste l'ensemble complet.

Commandes

ztc scan --daemon                 # run the scan loop on a schedule
ztc scan --once                   # a single cycle
ztc provision --all               # create/reconcile templates, report hosts, dashboard
ztc fix --host H --package P      # remediate a package (whitelisted, opt-in)
ztc upgrade                       # self-update, then re-run `provision --all`
ztc version --check               # print version and check for updates

Remédiation

ztc fix met à niveau un paquet vulnérable via une clé agent autorisée vulners.fix[<pkg>] consommée par un worker côté hôte — aucune exécution de commande arbitraire. Il peut être exécuté manuellement ou, avec scan --daemon --auto-fix, être piloté par un utilisateur de confiance qui reconnaît le problème dans Zabbix. Justification : docs/adr/0001-remediation-mechanism.md.

Matrice de prise en charge

Migration depuis la version Python

L'implémentation Python d'origine reste dans l'historique git de ce dépôt (les commits antérieurs à la réécriture Go) et dans les tags de version antérieurs à Go. Elle partage les mêmes noms côté Zabbix (groupe, hôtes de rapport, tableau de bord), mais collecte via les clés agent standard au lieu d'un report.py fourni, divise le modèle en deux, et supprime l'Action de correction. Procédure pas à pas (mapping de configuration, nettoyage des objets, ré-instrumentation des hôtes, bascule de remédiation) : docs/MIGRATION.md.

Développement

go build ./...     # compile
go test ./...      # unit tests (no network)
go vet ./... && gofmt -l .
make build         # -> bin/ztc

Un banc de test Docker (Zabbix + agent + ztc) se trouve dans deploy/docker/README.md. La CI (build/test/lint) s'exécute à chaque push ; taguer un commit v* publie les binaires et une image GHCR.

Licence

Voir LICENSE.