Imports, connecteurs et scans

Saisir la stack du projet élément par élément convient à quelques produits. Pour un inventaire réel, TechWatchAlert sait lire ce que vous avez déjà : un SBOM ou un manifeste de dépendances, les technologies servies par une URL, l’inventaire de GLPI ou d’Intune. Et un scan de vulnérabilités importé montre ce qui est réellement installé, face à ce qui est déclaré.

Vous avez…	Où	Ce que ça fait
Un SBOM CycloneDX ou un manifeste (package.json, requirements.txt…)	Surveillance › Stack › Importer un fichier	Propose chaque composant à l’ajout, avec sa version.
Un site en production	Surveillance › Stack › Détecter depuis une URL	Propose les technologies détectées, avec éditeur et version quand ils sont identifiables.
GLPI ou Microsoft Intune	Réglages du projet › Inventaire	Tient la stack à jour chaque nuit, ajouts et retraits compris.
Un rapport Trivy, Grype ou CycloneDX avec vulnérabilités, ou l’export d’un scanner réseau (Nessus, Greenbone/OpenVAS, Qualys, Rapid7 InsightVM)	Réglages du projet › Scans, ou l’API depuis la CI	Confronte les CVE trouvées aux fiches de suivi du projet, hôte par hôte pour un scanner réseau. Ne remplit pas la stack.

Note

Les imports de fichier et d’URL, le suivi automatique d’une URL et les connecteurs ajoutent tous les composants à la stack du projet, commune à l’équipe (voir Stack), quelle que soit la personne qui les lance ou les a configurés. Les alertes qui en découlent sont celles du projet.

Importer un SBOM ou un manifeste

Le bouton Importer un fichier de la page Stack ouvre la fenêtre Importer un inventaire. Rien n’est ajouté avant votre validation : le fichier est d’abord analysé, puis vous choisissez les composants.

Formats reconnus (5 Mo au plus, 5 000 composants au plus) :

• SBOM CycloneDX, en JSON ou en XML ;
• manifestes de dépendances, reconnus à leur nom de fichier : package.json, package-lock.json, requirements.txt, Pipfile.lock, poetry.lock, go.mod, composer.json, composer.lock, pom.xml, Gemfile.lock, Cargo.lock.

Tout autre nom de fichier est lu comme un SBOM CycloneDX. Le format SPDX n’est pas reconnu : exportez votre SBOM en CycloneDX.

1. Cliquez sur Importer un fichier, puis glissez le fichier dans la zone ou cliquez sur Choisir un fichier. L’analyse s’affiche (« Analyse du fichier… »).

2. L’écran de revue liste chaque composant du fichier.

   

   1. Résumé : nombre de composants, dont surveillables (déjà cités par une CVE) et non référencés.
   2. Tout cocher / décocher : agit sur tous les composants sélectionnables.
   3. Un composant déjà dans la stack est grisé et ne peut pas être coché.
   4. Un composant non référencé (aucune CVE ne le cite encore) est décoché mais reste cochable.
   5. Seuil d’alerte : un seul seuil pour tout l’import, la politique du projet par défaut.
   6. Ajouter N à la stack : lance l’ajout des composants cochés.

3. Vérifiez la sélection. Au départ, sont cochés les composants surveillables qui ne sont pas déjà dans la stack. Cocher un composant non référencé est permis : un avertissement le rappelle, et c’est le seul moyen d’être alerté sur sa première CVE.

   

4. Réglez au besoin le Seuil d’alerte, puis cliquez sur Ajouter N à la stack. Un message confirme le nombre de composants ajoutés, puis les failles rattrapées, s’il y en a (publiées depuis la création du projet).

La flèche en haut à gauche revient au dépôt pour choisir un autre fichier ; fermer la fenêtre abandonne l’import.

Comment chaque composant est reconnu. Le CPE du composant est lu en premier, puis son identifiant de paquet (purl : pkg:npm/jquery@3.7.1), et à défaut son nom. Le composant est enregistré comme produit si ce produit est cité par une CVE, sinon comme éditeur si c’est l’éditeur qui est connu, sinon comme produit non référencé. La version du fichier est conservée, ainsi que l’éditeur et le CPE quand ils sont connus : c’est ce qui rend les alertes précises.

« Déjà dans la stack » ne regarde pas la version

Un composant est marqué déjà dans la stack dès qu’un élément du même nom y figure, quelle que soit sa version. Dans l’exemple ci-dessus, log4j-core 2.17.1 est grisé parce que log4j 2.14.1 est déjà dans la stack : l’import ne met pas à jour la version. Après une mise à jour, changez la version à la main dans la stack.

Sur un projet où NIS2 est activée, l’import d’un SBOM ou d’un manifeste est aussi inscrit au registre des revues d’inventaire du projet (voir Registres NIS2).

Détecter depuis une URL

Détecter depuis une URL analyse une page publique et propose les technologies qu’elle sert (serveur web, langage, CMS, bibliothèques JavaScript…). C’est le chemin le plus rapide quand un site est en ligne.

1. Cliquez sur Détecter depuis une URL.
2. Saisissez l’adresse (https://…) et cliquez sur Analyser.
3. L’écran de revue est le même que pour un fichier : cochez les technologies à ajouter, réglez le seuil, puis Ajouter N à la stack.

La détection lit les en-têtes et le HTML de la page. Éditeur et version sont pré-remplis quand ils sont identifiables ; une technologie sans équivalent dans les CVE (un outil de mesure d’audience, par exemple) apparaît comme non référencée. Rien n’est enregistré avant votre validation : ni l’URL, ni les technologies.

Règles appliquées :

• l’adresse doit être publique : les adresses internes sont refusées ;
• 10 analyses au plus par période de 5 minutes et par personne (« Trop de scans d’URL — patientez quelques minutes. ») ;
• si la page ne répond pas ou ne révèle rien, un message l’indique (« Aucune technologie détectée sur cette URL. »).

Astuce

Pour surveiller un site dans la durée (certificat, technologies détectées toutes les 3 heures, ajout automatique à la stack), utilisez plutôt la page URLs surveillées. La détection depuis la page Stack est ponctuelle.

Connecteurs d’inventaire (GLPI et Intune)

Une stack saisie à la main vieillit : une version est montée, un logiciel est retiré, et les alertes deviennent fausses. Les connecteurs relisent chaque nuit les logiciels réellement installés, là où votre équipe les inventorie déjà, et tiennent la stack à jour.

Ils se configurent dans les réglages du projet : Espace de travail › Organisations, votre organisation, page Projets, le projet, puis sa page Intégrations. Ils sont inclus dans les offres Pro et Business ; sur une autre offre, la carte porte un cadenas et la section affiche « Les connecteurs d’inventaire se débloquent avec l’offre Pro » et un connecteur déjà configuré reste en lecture seule.

1. La section Inventaire de la page Intégrations du projet.
2. Le résultat de la dernière synchronisation : date, logiciels lus, logiciels suivis (produits connus des CVE), ajoutés, retirés. En cas d’échec, un bandeau ambre l’indique à la place (« Échec de la synchronisation du … : » suivi de la raison).
3. Adresse de GLPI et, dessous, les deux jetons.
4. Synchroniser chaque nuit : décoché, le connecteur est En pause.
5. Synchroniser maintenant lance une synchronisation immédiate ; Retirer supprime le connecteur.
6. La carte Microsoft Intune, pas encore configurée.

Configurer GLPI

1. Dans GLPI : Configuration › Générale › API, activez l’API REST et la connexion par jeton ; créez un client d’API (il donne le jeton d’application), puis un jeton d’API dans les préférences d’un compte en lecture seule sur le parc.
2. Dans TechWatchAlert, saisissez l’Adresse de GLPI (elle doit commencer par https:// ; /apirest.php est ajouté s’il manque), le Jeton d’application (App-Token) et le Jeton d’API de l’utilisateur (obligatoire).
3. Cliquez sur Enregistrer, puis sur Synchroniser maintenant pour une première lecture.

Configurer Microsoft Intune

1. Dans Microsoft Entra ID : inscrivez une application, ajoutez la permission d’application Microsoft Graph DeviceManagementManagedDevices.Read.All avec consentement administrateur, puis créez un secret.
2. Dans TechWatchAlert, saisissez le Locataire (tenant ID ou domaine) (un identifiant ou un domaine comme entreprise.onmicrosoft.com), l’Identifiant de l’application (client ID) et le Secret de l’application.
3. Cliquez sur Enregistrer, puis sur Synchroniser maintenant.

Intune fournit les applications détectées sur les appareils gérés.

Ce que fait une synchronisation

• Chaque nom d’inventaire est rapproché d’un produit des CVE : « Mozilla Firefox (x64 fr) » devient firefox, « Apache HTTP Server » devient http_server, « openssh-server » devient openssh. Seuls les produits connus des CVE sont gardés : un parc compte des centaines de pilotes et d’outils sans aucune CVE. L’éditeur n’est renseigné que s’il est le seul connu pour ce produit.
• Les nouveaux couples produit-version sont ajoutés à la stack, avec le badge GLPI ou Intune. Les failles publiées depuis la création du projet sont rattrapées dans les alertes, sans notification ; les plus anciennes n’en créent pas.
• Les éléments que ce connecteur avait ajoutés et qui ont disparu de l’inventaire sont retirés. Une montée de version se traduit donc par le retrait de l’ancienne ligne et l’ajout de la nouvelle.
• Les éléments saisis à la main ne sont jamais modifiés.
• 2 000 ajouts au plus par synchronisation ; le plafond d’éléments de l’offre s’applique (« Quota de la stack atteint » s’affiche alors comme erreur).

La synchronisation automatique a lieu chaque nuit pour les connecteurs actifs qui n’ont pas été relus depuis 20 heures.

Secrets et retrait

Les jetons et le secret sont chiffrés et ne sont jamais réaffichés : une fois enregistrés, le champ montre « •••••••• (enregistré — laisser vide pour le garder) ». Laissez-le vide pour conserver la valeur, ou saisissez-en une nouvelle pour la remplacer. L’adresse GLPI est revérifiée avant chaque appel ; les redirections sont refusées.

Retirer efface les secrets et le connecteur, après confirmation. Les éléments déjà ajoutés restent dans la stack et redeviennent des éléments manuels.

Scans de vulnérabilités

L’inventaire d’un projet est déclaré (stack, SBOM, technologies détectées). Un scan dit ce qui est réellement installé. TechWatchAlert ne scanne rien lui-même : il lit les rapports des outils que vous avez déjà, et les confronte aux fiches de suivi du projet. Il devient la couche de pilotage au-dessus de vos scanners.

Outil	Format à importer	Ce que le scan apporte
Trivy, Grype	rapport JSON (--format json, -o json)	composants et versions d’une image, d’un dépôt
CycloneDX avec vulnérabilités (VEX/VDR)	JSON	idem
Tenable Nessus (Nessus, Tenable.sc, Tenable Vulnerability Management)	export .nessus (XML v2), ou CSV	hôtes, ports, plugins
Greenbone / OpenVAS	rapport au format XML (GSA : Download › XML, ou get_reports en GMP)	hôtes, ports, tests (OID)
Qualys VMDR	résultats de scan en XML ou CSV, ou rapport Asset Data Report XML	hôtes, ports, QID
Rapid7 InsightVM / Nexpose	XML Export 2.0, ou CSV	hôtes, services, tests

Le format est reconnu au contenu du fichier, pas à son extension : JSON, XML, puis CSV en dernier recours (reconnu à sa ligne d’entête). Le XML est lu avec un analyseur qui refuse les entités et les références externes : un fichier piégé (XXE, « billion laughs ») est rejeté sans être interprété.

Stack › Scans

Les scans se gèrent dans la vue Scans de la page Stack (bouton Scans de son en-tête, adresse /stack?vue=scans), pour le projet actif. Ce sont des données de la stack, pas un réglage : l’ancien onglet Scans des réglages du projet y mène, comme la carte Importer un rapport de scan de la page Intégrations du projet.

• L’en-tête donne la date du dernier scan, son ancienneté et l’outil ; Importer un scan ouvre le choix d’un fichier.
• Dessous, le détail du scan choisi (le plus récent par défaut ; une liste permet d’en choisir un autre), avec en tête, en rouge, les correctifs non confirmés.
• En bas, la commande pour que la CI dépose les rapports seule (voir Brancher la CI).

Les liens « Importer un scan » de la mise en route NIS2 et « correctifs non confirmés » d’À faire maintenant mènent à cette vue.

Importer un rapport

1. Produisez le rapport, par exemple trivy image --format json -o trivy.json <image>, ou exportez le dernier scan de votre scanner réseau (voir le tableau ci-dessus).
2. Cliquez sur Importer un scan et choisissez le fichier .json, .xml, .nessus ou .csv (20 Mo au plus).
3. La vue affiche le scan importé ; un message donne le nombre de CVE trouvées.

Seules les vulnérabilités à identifiant CVE sont suivies ; une vulnérabilité GHSA qui cite sa CVE lui est rattachée, les autres sont comptées à part. Les doublons (même CVE, même hôte, même composant, même version) sont fusionnés ; 20 000 vulnérabilités au plus par rapport. Un fichier CycloneDX sans vulnérabilités est refusé : c’est un inventaire, il s’importe par Importer un fichier.

Pour un scanner réseau :

• un constat qui cite plusieurs CVE (un plugin Nessus Apache < 2.4.58, un QID Qualys…) donne une ligne par CVE ;
• le composant est le produit détecté quand le rapport le donne (CPE, empreinte de service), sinon le nom du test ; la version installée et la version corrigée sont reprises quand le scanner les écrit ;
• les constats purement informatifs sans CVE (Nessus « None », Greenbone « Log », Qualys « Information gathered ») sont ignorés ; les faux positifs déclarés dans Greenbone aussi ; les autres vulnérabilités sans CVE sont comptées à part ;
• le même constat sur deux ports d’un même hôte (Apache sur 443 et 8443) ne compte qu’une fois.

Note

Un scan importé ne se modifie pas et ne se supprime pas : c’est une preuve datée.

Lire la confrontation

Le bloc Scan rappelle la date d’import et son auteur (ou « par l’API (CI) »), l’Outil (la source : Trivy, Tenable Nessus, Qualys VMDR…), la Cible (image, ou nom du scan pour un scanner réseau), le Fichier, le nombre d’Hôtes pour un scanner réseau, et le nombre de CVE détectées. Quand plusieurs scans existent, une liste en haut de la vut permet de choisir le Scan affiché.

Pour un scanner réseau, le bloc Par hôte liste chaque machine (nom DNS ou NetBIOS, adresse IP, système, ports concernés) avec son nombre de CVE distinctes, dont les correctifs non confirmés et les CVE non suivies ; les hôtes qui démentent un correctif viennent en tête, puis les plus exposés. Un clic sur un hôte filtre la liste de la confrontation sur ses seules CVE ; Tout afficher la rend entière.

Le bloc Confrontation avec le suivi donne, pour chaque CVE trouvée, son état au regard de la fiche du projet. Les lignes sont triées par état, dans cet ordre :

État	Signification
Correctif non confirmé	La CVE est déclarée corrigée, mais le scan la trouve encore : le correctif n’a pas pris.
Écartée	La CVE est déclarée non applicable, et le scan la trouve.
Non suivie	Aucune fiche : le composant manque à la stack, ou la politique d’alerte l’a filtré. L’inventaire déclaré a un trou.
Suivie	Une fiche est ouverte (à traiter, en analyse, en remédiation).
Acceptée	Risque accepté : sa présence est attendue.

Chaque ligne donne la CVE (lien vers sa fiche), le composant et sa version, la version corrigée quand le scanner la connaît (« corrigée en 1.6.7 »), et la sévérité donnée par le scanner ; pour un scanner réseau, l’hôte et le port (« srv-web01.exemple.fr (10.0.0.5) · 443/tcp »). L’état est celui de la fiche du projet : une CVE déclarée corrigée et trouvée sur trois hôtes est un correctif non confirmé sur les trois, compté une fois. Sous la liste, un dépliant énumère les CVE suivies que ce scan ne retrouve pas : peut-être corrigées, ou hors de ce que le scan couvre.

Le dernier scan de chaque projet alimente aussi la posture NIS2 : projets scannés récemment et correctifs non confirmés (voir Conformité NIS2).

Brancher la CI

Le bas de la vue donne de quoi faire déposer les rapports par la CI, par l’API publique, en deux formes prêtes à copier :

• GitHub Actions : un fichier complet à placer dans .github/workflows/techwatchalert.yml. Il lance Trivy (en conteneur, aucune action tierce) sur le dépôt et envoie le rapport à chaque push sur main, chaque lundi et à la demande. Ajoutez la clé d’API comme secret TWA_API_KEY du dépôt (Settings › Secrets and variables › Actions). Pour scanner une image plutôt que le dépôt, remplacez fs . par image registre/app:tag.
• Autre CI / terminal : la commande trivy puis curl, à reprendre dans GitLab CI, Jenkins ou un script.

Un scanner réseau se branche de la même façon : la tâche planifiée qui exporte le dernier scan (API de Nessus, de Qualys, d’InsightVM, gvm-cli pour Greenbone) envoie le fichier XML ou CSV avec Content-Type: application/xml ou text/csv.

Rien n’est à autoriser côté GitHub : la CI pousse avec une clé d’API de l’organisation.

Il faut une clé d’API d’organisation qui porte le droit Dépôt de scans (Organisation › API) ; ce droit n’est jamais donné par défaut. Le détail de la requête est dans la référence POST …/scans.

Qui peut faire quoi

Action	Utilisateur	Analyste	Admin	Propriétaire
Importer un fichier, détecter depuis une URL		✓	✓	✓
Voir les connecteurs d’inventaire	✓	✓	✓	✓
Configurer, synchroniser, retirer un connecteur			✓	✓
Voir les scans	✓	✓	✓	✓
Importer un scan		✓	✓	✓

La détection depuis une URL demande le droit d’ajouter à la stack ; l’import d’un fichier (SBOM, manifeste) et celui d’un scan demandent en plus le droit Importer (SBOM / lot), accordé par défaut aux Analystes, Admin et au Propriétaire du projet : sans lui, le bouton Importer un fichier de la page Stack n’apparaît pas. Sans droit de configuration, la vue Inventaire l’indique : « Seuls les administrateurs du projet peuvent configurer ou lancer un connecteur. »

Tous les ajouts à la stack (import, URL, connecteur) comptent dans le plafond d’éléments de l’offre (voir Stack).

Disponible selon votre offre

L’import des rapports de scanners réseau (Nessus, Greenbone/OpenVAS, Qualys, InsightVM) a sa propre fonction d’offre, incluse dans toutes les offres par défaut. Hors offre, la vue Scans le dit dans un bandeau, et déposer un tel fichier (interface ou API) est refusé avec un message clair et l’offre qui l’ouvre. Les rapports Trivy, Grype et CycloneDX restent importables quelle que soit l’offre. Voir aussi : Abonnement › pages, vues et éléments.

Questions fréquentes

Mon SBOM est au format SPDX. Il n’est pas reconnu. La plupart des générateurs (Syft, Trivy, cdxgen) savent produire du CycloneDX.

Mon scanner réseau a plusieurs projets en un seul scan. Un scan importé appartient à un projet : exportez le rapport par périmètre (groupe d’actifs, tâche, site) et importez chacun dans son projet.

Un scan remplit-il la stack ? Non. Il la confronte à ce qui est installé. Une CVE Non suivie indique justement un composant à ajouter à la stack.

Le connecteur a retiré un élément que je voulais garder. Il ne retire que ce qu’il a lui-même ajouté et qui a disparu de l’inventaire. Ajoutez l’élément à la main : il ne sera plus jamais touché par le connecteur.

StackVersions, seuils, criticité et tags des éléments.

URLs surveilléesSurveiller un site dans la durée.

POST …/scans (API)Pousser un rapport depuis la CI.

Alimenter sa stackComparer les chemins d'alimentation.