bitcollector

bitcollector lit un hôte et publie ce qu'il y trouve. Il n'écrit jamais sur l'hôte.

Il répond à la question « qu'y a-t-il sur cette machine, et dans quel état est-elle ? » — en continu, sur tout un parc, sous une forme que vous pouvez remettre à un auditeur et défendre.

Version	0.1.0-ga, commit 8819759, compilée avec go1.25.12
Plateformes	Linux amd64/arm64, macOS amd64/arm64, Windows amd64 — voir plateformes
Chaîne d'approvisionnement	Compilation reproductible, SBOM CycloneDX, signature cosign, attestation du SBOM, SHA256SUMS signé
Surface réseau entrante	Aucune. Le seul service en écoute est restreint à la boucle locale
Écritures sur l'hôte	Son propre répertoire de données et son fichier de journal — plus tout fichier que vous demandez explicitement à export-pubkey d'écrire

Avant de l'exécuter, vérifiez le téléchargement.

Ce qu'il collecte et ce qu'il coûte à exécuter sont détaillés ci-dessous. Deux de ses aspects sont assez importants pour avoir leur propre page : la chaîne de preuves — la signature, le chaînage et la vérification hors ligne qui rendent la donnée défendable — et la confidentialité et les comptes locaux, ce qui le rend déployable en France sans discussion.

Ce qu'il collecte

Neuf collecteurs, chacun activable indépendamment et chacun sur son propre intervalle :

Collecteur	Ce qu'il rapporte
process	Processus en cours d'exécution. Les lignes de commande sont désactivées par défaut — voir Confidentialité
port	Ports en écoute
software	Paquets installés
system	Matériel et système d'exploitation
metrics	Métriques de ressources de l'hôte
network	Interfaces et pairs établis
posture	Posture de sécurité en temps réel — voir Posture
accounts	Comptes locaux privilégiés et dormants — voir Comptes
file	Entrées de journaux et de fichiers (sur activation explicite ; désactivé dans la configuration livrée)

Deux règles les traversent tous :

• Chaque enregistrement porte son horodatage de collecte et le collecteur qui l'a produit.
• « Absent » et « pas le droit de regarder » ne sont jamais la même réponse. Un collecteur qui ne peut pas s'exécuter rapporte pourquoi, comme une valeur de plein droit. Un agent non privilégié qui ne peut pas lire /etc/shadow rapporte unknown avec la raison — il ne délivre jamais un satisfecit qu'il n'a pas observé.

Cette seconde règle n'est pas une coquetterie. Un inventaire qui rapporte silencieusement « aucun résultat » alors qu'il s'est en réalité vu refuser la permission est pire que pas d'inventaire du tout, parce que vous allez agir dessus.

Posture : observée, jamais supposée

Le collecteur posture est l'entrée qui transforme des milliers de résultats en la poignée qui compte : « CVE présente, mais le contrôle Y est vérifié comme appliqué. »

Tout ce qu'il rapporte est un état d'hôte observé, jamais un fichier de configuration :

Contrôle	Lu depuis
SELinux	/sys/fs/selinux/enforce — le noyau en cours d'exécution
AppArmor	/sys/module/apparmor/…, /sys/kernel/security/apparmor/…
Pare-feu	Le jeu de règles nftables/iptables/ip6tables actif, pour les deux familles d'adresses
sshd	sshd -T (avec repli sur sshd -G) — l'analyse par le démon lui-même, qui suit les Include
Sysctls	/proc/sys/… — et non /etc/sysctl.conf

Cette distinction, c'est le produit. Un fichier de configuration dit ce que quelqu'un a voulu. sshd -T dit ce que sshd va réellement faire. Les deux divergent plus souvent que personne ne voudrait l'admettre, et c'est cet écart qui fait échouer les audits.

Il est en lecture seule : six commandes de listage à argv fixe passant par une liste d'autorisation, aucun shell, chaque fichier ouvert en O_RDONLY. Il s'exécute sans privilèges et rapporte, contrôle par contrôle, si le contrôle était absent ou si l'agent n'avait pas le droit de regarder. Une exécution en root (ou avec CAP_NET_ADMIN) fournit en plus le jeu de règles du pare-feu et l'inventaire des profils AppArmor.

Le flux de changements

Une télémétrie d'état complet à chaque cycle, c'est ce qui pousse un DBA à mettre son veto à votre déploiement. Le flux de changements (A4) n'envoie que ce qui a changé.

Mesuré sur un hôte de référence réel, publié avec la morphologie d'hôte qui a produit ces chiffres :

Référence en état complet	284.57 KB/cycle (moyenne de 4 cycles consécutifs de 60 s, dispersion de 0.53 %)
Delta effectivement envoyé	6.55 KB en moyenne, 7.84 KB au p95, 10.57 KB au pire — dans le budget sur les 21 cycles
Morphologie de l'hôte	558 processus, 714 paquets, 45 ports en écoute, 71 connexions établies, 32 interfaces, 6 collecteurs, command_line: off, sans privilèges root

86.36 % des octets des collecteurs à structure de liste se répètent à l'identique à chaque cycle, et environ 13 % des enregistrements de processus « changent » à chaque cycle par les seules valeurs d'échantillonnage CPU et mémoire — c'est pourquoi il s'agit d'une séparation de schéma (faits de parc contre échantillons) plutôt que d'un algorithme de différentiel. Un différentiel naïf au niveau de l'enregistrement n'a mesuré que 7.4×, encore très au-dessus du budget.

Un flux delta se reconstruit exactement dans le même état qu'un instantané complet, et un instantané complet réancre le flux selon une périodicité (snapshot_interval: 6h par défaut), de sorte qu'un delta perdu ne puisse pas désynchroniser silencieusement la vue qu'a la plateforme d'un hôte.

Le flux de changements est livré DÉSACTIVÉ, et c'est délibéré

delta.enabled: false dans la configuration livrée, et l'activer est nécessaire mais pas suffisant : l'agent exige en outre que le plan de contrôle annonce qu'il comprend le protocole, et il continue d'envoyer l'état complet tant que ce n'est pas le cas.

Ce second verrou est dans le code plutôt que dans une procédure d'exploitation parce que le mode de défaillance est silencieux. Un delta envoyé à un récepteur qui ne le comprend pas est transmis en aval comme s'il s'agissait d'une charge utile complète — ce qui ne produit aucune erreur, mais corrompt silencieusement l'image que la plateforme a de votre parc. Activez-le lorsque votre tenant Cert-IX le prend en charge, et non comme effet de bord d'un autre changement.

Deux domaines ne circulent pas du tout par le chemin delta : posture et accounts ne sont publiés que sur le chemin complet, si bien qu'un agent avec le flux de changements activé ne les enverrait pas. Cette limite est énoncée dans le fichier de configuration livré, elle n'est pas laissée à la découverte.

Sûr à exécuter en production

L'objet de cette section est de vous donner l'autorisation d'installer sur une machine qui compte.

Les plafonds de ressources sont réellement appliqués, pas seulement documentés.

agent:
  max_memory_mb: 50
  max_cpu_percent: 80

• max_memory_mb est appliqué comme limite mémoire du runtime Go : le ramasse-miettes travaille donc progressivement plus dur pour rester en dessous. Il couvre le tas Go, les piles de goroutines et les structures du runtime. Ce n'est pas un OOM killer : le dépasser rend l'agent plus lent, jamais mort — un agent qui se tue sous la pression mémoire cesse d'être une preuve précisément au moment où il se passe quelque chose d'intéressant.
• max_cpu_percent est un plafond sur le propre cycle d'occupation de l'agent, exprimé en pourcentage d'un cœur (80 = 0.8 cœur). L'application se fait par report : lorsque la moyenne glissante dépasse le plafond, le prochain tick de collecte est sauté et compté. La livraison, les battements de cœur, la file de réémission et l'endpoint de santé local ne sont jamais reportés — un hôte sous charge doit rester capable d'expédier ce qu'il détient déjà.

Le report est visible lorsqu'il se produit :

Collection tick DEFERRED: this agent is above agent.max_cpu_percent. Delivery and
heartbeats are unaffected; the deferral is counted on the local health endpoint so a
permanently throttled agent cannot pass for a quiet host

Aucune surface réseau entrante. Le seul service en écoute est un endpoint local de santé/métriques, et il ne s'attache qu'à la boucle locale — 127.0.0.1 et [::1], sous forme de deux écouteurs explicites, avec les adresses d'attache en constantes de compilation. Il n'existe aucune clé de configuration pour l'élargir, parce qu'un service en écoute qu'un opérateur peut élargir finit par être élargi.

curl -s 127.0.0.1:9713/status

Un chien de garde (watchdog) redémarre un collecteur figé sans redémarrer l'agent. Lent et figé sont distingués par la mesure, pas par supposition : lent signifie que le collecteur répond en retard (déjà rapporté comme un dépassement de délai) ; figé signifie que son contexte a été annulé et qu'il n'a toujours pas rendu la main. La rotation des journaux élague à la fois par taille et par âge, de sorte que l'agent ne puisse pas remplir votre /var et vous offrir une panne.

Stockage et retransmission (store-and-forward). La télémétrie qui n'a pas pu être livrée est réessayée avec temporisation croissante et livrée dès le retour de la passerelle. Un 401 sur le chemin de télémétrie rafraîchit le jeton et réessaie. Ce qui n'a pas pu être livré est attribuable — un trou n'est jamais indiscernable d'un « il n'y avait pas de données ».

L'exécuter

bitcollector est un binaire statique unique. Vérifiez-le d'abord (comment), puis :

# Check what you have
bitcollector --version
# bitcollector 0.1.0-ga (commit: 8819759, built: 2026-08-09T12:08:13Z)

# Run with a configuration file
bitcollector -config /etc/bitcollector/bitcollector.yaml

# Turn up the detail while you are setting it up
bitcollector -config /etc/bitcollector/bitcollector.yaml -log-level debug

Les variables d'environnement priment sur les valeurs du fichier de configuration :

Variable	Objet
CERTIX_TENANT_ID	Votre tenant, depuis Settings → Organization
CERTIX_ENROLLMENT_TOKEN	Jeton d'enrôlement à usage unique, émis dans le tableau de bord. Requis sauf si des certificats client mTLS sont configurés
CERTIX_GATEWAY_URL	Agent Gateway (enregistrement, rafraîchissement de jeton, politique)
CERTIX_INGEST_URL	Agent Ingestion Gateway (battement de cœur, télémétrie)
CERTIX_TLS_CA_CERT / CERTIX_TLS_CLIENT_CERT / CERTIX_TLS_CLIENT_KEY	Éléments mTLS

L'agent refuse de démarrer plutôt que de fonctionner sans une identité qu'il peut prouver :

ERROR: Failed to load configuration: missing required configuration:
control_plane.enrollment_token (CERTIX_ENROLLMENT_TOKEN) required when mTLS client
certificates are not configured

Ajuster ce qu'il coûte

Les valeurs interval: et timeout: définies par collecteur sont respectées. Chaque collecteur activé s'exécute sur son propre intervalle et remplit un cache ; un tick de publication distinct, à agent.collection_interval, envoie un lot unique portant les domaines qui ont produit de nouvelles données.

Part mesurée de chaque collecteur dans un lot, pour que vous puissiez régler sur des chiffres réels plutôt qu'au jugé (5 cycles à 60 s, sans privilèges root, command_line: off) :

Collecteur	Part du lot
process	89.79 %
software	6.85 %
port	1.86 %
system	1.20 %
network	0.27 %
metrics	0.01 %

Le collecteur dont il faut allonger l'intervalle si vous voulez moins d'octets, c'est process, pas software.

Aucune valeur ne signifie « sans limite »

timeout: 0s signifie « non configuré » : la valeur par défaut intégrée est utilisée et l'agent journalise un avertissement nommant la clé. Ce n'est pas une façon de dire « prends tout le temps qu'il te faut » — tous les collecteurs partagent une seule goroutine d'ordonnancement, donc une exécution que rien ne peut annuler arrête aussi la publication, le battement de cœur et tous les autres collecteurs. Réglez sur la durée la plus longue d'une exécution saine sur cet hôte, avec de la marge.

Plateformes

0.1.0-ga publie cinq binaires signés, et rien n'est retenu — bitcollector est le seul bit livré sur toutes les plateformes visées par la famille :

Plateforme	Publiée	Remarques
Linux amd64	Oui
Linux arm64	Oui
macOS amd64	Oui
macOS arm64	Oui
Windows amd64	Oui	Livré sous le nom bitcollector-windows-amd64.exe

Il le peut parce qu'il lit, et que chaque collecteur possède une implémentation par système d'exploitation, avec une réponse explicite « indisponible ici » là où une plateforme n'a pas d'équivalent. Les trois autres bits retiennent chacun au moins une plateforme, et chacune de leurs pages dit laquelle et pourquoi — bitscanner, bitenforcer, bitmapper.

Être livré sur une plateforme n'est pas la même chose que tout y observer. Les contrôles que l'agent ne lit pas sur un système donné sont rapportés avec un statut distinct — non pris en charge par l'agent sur cette plateforme — portant la plateforme comme source et une consigne explicite de ne pas considérer le contrôle comme absent. C'est une affirmation sur l'agent, jamais un constat sur l'hôte.

C'est la même règle que partout ailleurs sur cette page : absent, pas le droit de regarder et non observé sur cette plateforme sont trois réponses différentes, et aucune n'est un certificat de bonne santé.

Étapes suivantes

• La chaîne de preuves — comment un lot est signé, chaîné et vérifié hors ligne par quelqu'un qui ne nous fait pas confiance.
• Confidentialité et comptes locaux — ce qui est collecté au sujet des personnes, ce qui ne l'est pas, et ce que vous devez activer explicitement.
• Vérifier vos téléchargements — à faire avant la première installation.
• bitenforcer — l'autre moitié de la paire.
• Gestion des actifs — là où atterrit la télémétrie.