Aller au contenu

Connecteurs

L’onglet Connecteurs de la page Stack rassemble tout ce qui alimente la stack du projet : les dépôts GitHub et GitLab, les images de conteneurs, les fichiers SBOM et manifestes importés, les sites web suivis, l’inventaire du parc et du cloud (GLPI, Intune, AWS, Azure, Wazuh, Jamf Pro) et la saisie manuelle. Les rapports de scanners y figurent aussi, avec un lien vers leur vue : ils n’ajoutent rien à la stack.

Où : Surveillance › Stack, onglet Connecteurs, à côté de l’onglet Composants (adresse /stack?vue=connecteurs). L’ancienne page Sources n’a plus d’entrée dans la barre latérale ; son adresse /sources mène à cet onglet, et la recherche (Ctrl K) propose toujours l’entrée Connecteurs. L’onglet montre les connecteurs du projet actif.

L’onglet se lit de haut en bas :

  • Répartition de la stack : le nombre total de composants, et une barre qui montre la part de chaque source (saisie manuelle, sites web, fichiers, GitHub, GitLab, conteneurs, inventaire) ;
  • un sélecteur de catégorie : Tous les connecteurs, Dépôts de code, Conteneurs, Fichiers, Sites web, Parc et cloud, Autres, chacune avec son nombre de connecteurs ;
  • la recherche Rechercher un connecteur, qui lit le nom et quelques mots-clés (« k8s » trouve Kubernetes, « trivy » les Rapports de scanners) ;
  • la grille, une case par connecteur. Si rien ne correspond, l’onglet affiche « Aucun connecteur ne correspond. »
Case Catégorie Un clic ouvre
GitHub Dépôts de code la page Dépôts GitHub (/sources/github)
GitLab Dépôts de code la page Dépôts GitLab (/sources/gitlab)
Docker Conteneurs la page Conteneurs (/sources/conteneurs), pour les images
Kubernetes Conteneurs la même page, pour les clusters
SBOM CycloneDX Fichiers la page Fichiers SBOM et manifestes (/sources/fichiers)
Manifestes et lockfiles Fichiers la même page
Sites web Sites web la page Sites web (/sources/sites)
GLPI, Microsoft Intune, AWS, Azure, Wazuh, Jamf Pro Parc et cloud la page Inventaire du parc et du cloud (/sources/inventaire), directement sur la configuration de cet outil
Saisie manuelle Autres la fenêtre d’ajout de la page Stack
Rapports de scanners Autres la vue Stack › Scans

Chaque case porte le logo de l’outil, son nom et son état : un point (vert : actif ; ambre : à regarder ; rouge : en erreur ; gris : non branché) et une ligne courte (« 3 dépôts suivis », « 2 images suivies », « Non connecté », « Non configuré », « Aucun site suivi »). Un connecteur branché indique aussi son dernier succès (« Dernier succès il y a 5 minutes », ou « Aucun succès enregistré »). En haut à droite, une pastille signale ce qui demande l’attention : Jeton expiré, Liste incomplète, À synchroniser, ou le nombre d’éléments en attente. Hors offre, les cases GLPI, Intune, AWS, Azure, Wazuh et Jamf Pro portent un cadenas Offre Pro ; elles ouvrent quand même leur page, qui présente l’offre.

Les pages de connecteur gardent leurs adresses. Un lien ‹ Connecteurs, au-dessus du titre, ramène à l’onglet.

Le connecteur GitHub lit les dépendances de vos dépôts dans leurs lockfiles et manifestes, et les tient à jour à chaque push sur la branche par défaut. Il ne demande que des droits en lecture : Contents et Metadata.

  1. Dans la section Dépôts GitHub, cliquez sur Connecter GitHub. GitHub s’ouvre et propose d’installer l’application TechWatchAlert sur votre compte ou votre organisation.

  2. Sur GitHub, choisissez Only select repositories et cochez seulement les dépôts à surveiller, puis validez.

  3. De retour dans TechWatchAlert, l’installation est rattachée au projet. Les dépôts autorisés apparaissent dans la carte du compte, à l’état En attente : rien n’est lu tant que vous n’avez pas activé un dépôt.

Si vous n’êtes pas propriétaire de l’organisation GitHub, GitHub envoie une demande d’installation à ses propriétaires ; une fois la demande approuvée, relancez la connexion depuis la case GitHub de l’onglet Connecteurs. Connecter un autre compte GitHub ajoute une deuxième installation (un autre compte ou une autre organisation).

La carte d’un compte indique combien de dépôts sont suivis (« 2 / 5 dépôts suivis ») et propose :

  • Choisir les dépôts sur GitHub : ajouter ou retirer des dépôts autorisés, côté GitHub ;
  • Rafraîchir : relire la liste des dépôts autorisés ;
  • Déconnecter (voir Ne plus suivre un dépôt, déconnecter).

Chaque dépôt autorisé a un interrupteur Suivre ce dépôt. L’activer lance l’analyse de sa branche par défaut ; le dépôt passe par Analyse…, puis Suivi, ou Erreur si la lecture a échoué. Un message confirme le nombre de composants ajoutés à la stack. Une fois suivi, la ligne du dépôt indique le nombre de composants et de fichiers lus, et la date de la dernière lecture ; Relire relance une analyse immédiate. Un dépôt privé porte la mention Dépôt privé.

Ce qui est lu :

  • les lockfiles et manifestes reconnus par l’import de fichier (package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, requirements.txt, go.mod, composer.lock, pom.xml, Gemfile.lock, Cargo.lock…) et les SBOM CycloneDX ou SPDX (bom.json, sbom.json, *.cdx.json, *.spdx.json…), partout dans le dépôt ;
  • en complément, le graphe de dépendances que GitHub tient pour le dépôt (son SBOM) : ce qu’il a résolu lui-même, notamment par la soumission automatique (Maven, Gradle, NuGet, pip). Seules les versions exactes y sont retenues ; un graphe désactivé ne bloque rien ;
  • sauf dans les dossiers qui ne décrivent pas l’application : node_modules, vendor, dist, build, environnements virtuels Python, tests (test, tests, __tests__, fixtures, testdata), exemples (examples, samples) et docs ;
  • dans un même dossier, le lockfile est préféré au manifeste : package-lock.json plutôt que package.json, composer.lock plutôt que composer.json ;
  • 50 fichiers au plus par dépôt, d’1 Mo chacun au plus ; les fichiers en trop sont écartés, les moins profonds d’abord retenus.

Au survol du badge GitHub d’un élément, la page Stack indique le fichier d’où il vient (par exemple api/poetry.lock).

  • Chaque push sur la branche par défaut qui touche un fichier de dépendances déclenche une nouvelle lecture du dépôt.
  • Une passe planifiée, toutes les 15 minutes, traite les lectures en attente ; un filet quotidien relit chaque dépôt suivi, au cas où un push aurait été manqué.
  • Si les webhooks GitHub ne sont pas configurés sur l’instance, la section l’indique : les dépôts ne sont alors relus qu’une fois par jour.

À chaque lecture, les composants qui ont disparu des fichiers du dépôt quittent la stack, les nouveaux y entrent ; une montée de version remplace l’ancienne ligne. Les failles déjà publiées sur les nouveaux composants sont rattrapées dans les alertes, comme pour un import.

Si l’installation est suspendue ou retirée côté GitHub, la carte l’indique (« L’installation est suspendue ou a été retirée sur GitHub : plus rien n’est lu. »).

  • Ne plus suivre (l’interrupteur, désactivé) : le dépôt n’est plus lu. La confirmation propose Retirer aussi ses composants de la stack ; sans cette case, ses composants restent dans la stack, figés.
  • Déconnecter retire l’installation du projet : TechWatchAlert ne lit plus ces dépôts. La confirmation propose Retirer aussi de la stack les composants venus de ces dépôts.
  • Pour retirer aussi l’accès côté GitHub, désinstallez l’application depuis Choisir les dépôts sur GitHub.

La saisie manuelle n’est jamais touchée.

Chaque dépôt suivi compte pour une application SBOM dans l’offre, comme un fichier importé : avec les réglages par défaut de l’instance, 1 en Free, 5 en Team, illimité en Pro et Business. Les relectures d’un dépôt ne comptent pas dans les imports quotidiens. Voir Abonnement et facturation.

Le connecteur GitLab lit les dépendances de vos projets GitLab, sur gitlab.com ou sur votre propre instance, avec les mêmes règles que GitHub. Il est en lecture seule (scopes read_api et read_repository) et n’installe aucun webhook : chaque dépôt suivi est vérifié toutes les 15 minutes, et relu seulement si son dernier commit a changé.

  1. Dans l’onglet Connecteurs de la page Stack, ouvrez la case GitLab.

  2. Choisissez gitlab.com, ou Instance auto-hébergée. Pour une instance auto-hébergée, son administrateur crée d’abord une application OAuth (Admin › Applications, ou Préférences › Applications) avec la Redirect URI affichée dans le formulaire, les scopes read_api et read_repository, et l’option Confidential cochée. Saisissez ensuite l’Adresse de l’instance (en https://), l’Application ID et le Secret.

  3. Cliquez sur Connecter GitLab, puis autorisez l’application sur GitLab.

  4. De retour dans TechWatchAlert, les projets auxquels vous avez accès (rôle Reporter ou plus) apparaissent à l’état En attente : rien n’est lu tant que vous n’avez pas activé un dépôt.

Connecter un autre compte ou une autre instance ajoute une deuxième connexion. La carte d’une connexion indique le compte, l’instance et le nombre de dépôts suivis, et propose :

  • Autorisations sur GitLab : la page GitLab où l’autorisation peut être révoquée ;
  • Rafraîchir : relire la liste des projets accessibles (un nouveau projet arrive en attente) ;
  • Déconnecter.

Suivre un dépôt, Relire, ne plus suivre et l’offre fonctionnent comme pour GitHub : chaque dépôt suivi compte pour une application SBOM. Si l’autorisation a été révoquée ou a expiré, la carte l’indique (« L’autorisation GitLab a été révoquée ou a expiré : plus rien n’est lu. ») : reconnectez GitLab.

Déconnecter fait oublier la connexion et ses jetons à TechWatchAlert. Pour retirer aussi l’autorisation côté GitLab, ouvrez Autorisations sur GitLab.

La source Conteneurs ajoute à la stack les paquets du système de base de vos images Docker : paquets apt (Debian, Ubuntu), apk (Alpine) et rpm (Red Hat, Rocky, Alma, Fedora). Ce sont les composants que les fichiers de dépendances ne voient pas : OpenSSL, la glibc, curl… Elle est en lecture seule.

Ouvrez la case Docker de l’onglet Connecteurs, puis saisissez une référence d’image (nginx:1.27, ghcr.io/acme/api:prod) puis Suivre l’image. Les couches sont téléchargées puis lues : la ligne passe par Analyse…, puis Suivie. Elle indique le système (« Debian GNU/Linux 12 (bookworm) »), le nombre de paquets et de composants, et la date de la dernière lecture.

Les images publiques (Docker Hub, GHCR, Quay…) se lisent sans identifiants. Pour une image privée, ajoutez le registre dans Registres privés : son adresse (ghcr.io, registry.gitlab.com, harbor.entreprise.fr), un identifiant et un jeton en lecture seule (GHCR : read:packages ; GitLab : read_registry ; Harbor : compte robot « pull » ; Docker Hub : jeton d’accès en lecture). Le jeton est chiffré et n’est plus jamais affiché.

  1. Dans Clusters Kubernetes, donnez un nom au cluster (par exemple prod-eu), puis Générer le manifeste.

  2. Téléchargez techwatchalert.yaml. Il contient le jeton du cluster, qui ne sera plus affiché.

  3. Appliquez-le avec un compte administrateur du cluster : kubectl apply -f techwatchalert.yaml. Il crée un compte de service qui ne peut que lister les pods, et une tâche qui envoie chaque heure la liste des images. Rien d’autre ne sort du cluster.

  4. Au premier envoi, les images qui tournent apparaissent En attente, avec les espaces de noms où elles tournent. Rien n’est téléchargé tant que vous n’activez pas Suivre cette image.

Une image qui ne tourne plus dans le cluster est marquée Ne tourne plus et n’est plus relue. Déconnecter un cluster révoque son jeton : retirez aussi la tâche avec kubectl delete namespace techwatchalert.

Toutes les 6 heures, chaque image suivie compare l’empreinte de son étiquette : elle n’est relue que si une nouvelle version a été publiée sous la même étiquette (nginx:1.27, latest…). Relire force une lecture. Les paquets qui disparaissent quittent la stack, les nouveaux y entrent.

Chaque image suivie compte pour une application SBOM dans l’offre. Les images en attente ne comptent pas.

Un fichier par application : le nom de l’application, saisi à l’import (par défaut, le nom du fichier), regroupe ses composants. La section liste les applications importées, avec leur nombre de composants et la date du dernier import.

  • Importer un fichier ouvre la fenêtre d’import (SBOM CycloneDX ou manifeste), décrite dans Imports, connecteurs et scans.
  • Nouvelle version rouvre la même fenêtre, sous le nom de l’application : le fichier en remplace la version précédente.
  • Retirer retire l’application, après confirmation : ses composants quittent la stack et sa place dans l’offre est libérée. La saisie manuelle n’est pas touchée.

Dans la fenêtre d’import, la case Remplacer la version précédente de cette application : ce qui n’est plus dans le fichier quitte la stack. est cochée par défaut. Décochée, l’import ne fait qu’ajouter.

Les applications tenues par un dépôt GitHub ou GitLab se gèrent depuis la page du dépôt (Dépôts GitHub ou Dépôts GitLab).

Les sites publics du projet, scannés toutes les 3 heures : technologies détectées, code HTTP, certificat HTTPS. Le Suivi auto ajoute à la stack les technologies détectées. Cette section reprend l’ancienne page URLs, dont l’adresse (/urls) mène désormais ici. Tout est décrit dans URLs surveillées.

Les logiciels réellement installés sur vos postes et serveurs, relus chaque nuit par les connecteurs GLPI, Microsoft Intune, AWS (Systems Manager), Azure (Change Tracking & Inventory), Wazuh (Syscollector) et Jamf Pro. Cette section remplace l’ancienne section Inventaire de la page Intégrations du projet. Configuration, synchronisation et retrait sont décrits dans Imports, connecteurs et scans.

Au retrait d’un connecteur, la confirmation propose Retirer aussi de la stack ce que ce connecteur avait ajouté. Sans cette case, les éléments restent dans la stack, figés : plus rien ne les met à jour.

Un produit ou un éditeur, et sa version, ajoutés à la main. Le bouton Ajouter à la main ouvre la fenêtre d’ajout de la page Stack (voir Stack › Ajouter un élément à la main). Aucune source automatique ne modifie ces éléments.

Trivy, Grype, Nessus, Greenbone, Qualys, InsightVM : leurs résultats sont confrontés aux alertes du projet, ils n’ajoutent rien à la stack. Le bouton Importer un rapport de scan ouvre la vue Stack › Scans (voir Rapports de scanners).

Action Utilisateur Analyste Admin Propriétaire
Voir l’onglet Connecteurs et les pages de connecteur ✓ ✓ ✓ ✓
Importer un fichier, nouvelle version, retirer une application ✓ ✓ ✓
Ajouter, supprimer un site, activer le suivi auto ✓ ✓ ✓
Connecter GitHub ou GitLab, suivre un dépôt, déconnecter ✓ ✓
Suivre une image, connecter un cluster, gérer les registres ✓ ✓
Configurer, synchroniser, retirer un connecteur d’inventaire ✓ ✓

Sans droit d’administration du projet, la section GitHub affiche « Seuls les administrateurs du projet peuvent connecter GitHub. » L’import d’un fichier demande le droit Importer (SBOM / lot) ; retirer une application demande en plus le droit Supprimer de la stack.

Où sont passés les boutons « Détecter depuis une URL » et « Importer un fichier » de la page Stack ? Ils sont remplacés par l’onglet Connecteurs de la page Stack. Pour un site, ajoutez-le dans Sites web ; pour un fichier, utilisez Importer un fichier dans Fichiers SBOM et manifestes. L’ajout à la main reste sur la page Stack.

Où est passée l’entrée « Sources » de la barre latérale ? La page Sources s’appelle maintenant Connecteurs et c’est un onglet de la page Stack. Le bouton Sources de l’en-tête de Stack a disparu avec elle. L’adresse /sources et les favoris qui y pointent mènent à l’onglet ; les adresses des pages de connecteur (/sources/github, /sources/sites…) n’ont pas changé.

TechWatchAlert lit-il tous mes dépôts dès la connexion ? Non. Les dépôts autorisés arrivent En attente et rien n’est lu tant que vous n’avez pas activé Suivre ce dépôt. Limitez de plus l’accès aux seuls dépôts utiles (Only select repositories).

Un outil externe peut-il savoir quand la stack change ? Oui, sur les offres Pro et Business : un webhook de type Inventaire reçoit l’événement inventory.changed à chaque changement apporté par GitHub, GitLab, un connecteur ou un import (voir Les webhooks du projet).