Stack

La stack est la liste des éditeurs et des produits que TechWatchAlert surveille pour un projet. C’est elle qui décide quelles CVE deviennent des alertes : une CVE qui ne touche aucun élément de la stack ne produit rien. Plus la stack est juste (bons noms, versions exactes), plus les alertes le sont.

L’écran se trouve dans Surveillance › Stack. Il montre la stack du projet actif, celui choisi sous Projet actif en haut du menu ; le nom du projet est rappelé à côté du titre. Sans projet actif, la page affiche seulement « Sélectionnez un projet pour voir sa stack ».

1. Détecter depuis une URL, Importer un fichier et Ajouter à la stack : les trois façons d’alimenter la stack (voir Ajouter un élément à la main et Imports, connecteurs et scans).
2. Bandeau de politique : la règle d’alerte du projet en une phrase, et l’avertissement si des éléments s’en écartent.
3. Type : Tous, Éditeurs ou Produits, avec leur nombre.
4. Filtre de seuil d’alerte.
5. Recherche dans la stack, et nombre de résultats.
6. Filtre par tag (s’affiche quand l’organisation a des tags).
7. En-têtes de colonnes : un clic sur Nom, Type ou Seuil d’alerte trie la liste.
8. Badges d’un élément : ici 0 CVE et GLPI.

Une stack par projet, commune à l'équipe

La stack appartient au projet : tous ses membres voient les mêmes éléments et ceux qui en ont le droit la tiennent à jour ensemble. Les alertes qu’elle produit sont celles du projet, visibles de toute l’équipe. Les imports de fichier (SBOM, manifestes), la détection et le suivi automatique d’une URL, et les connecteurs d’inventaire (GLPI, Intune) alimentent tous cette même stack, quelle que soit la personne qui les lance. Retirer un membre du projet ne retire rien de la stack.

Ce qu’on met dans la stack

Un élément de stack est de l’un de deux types :

Produit

Un logiciel précis : nginx, openssl, postgresql, wordpress… C’est le cas le plus courant. Un produit peut porter une version : seules les CVE qui touchent cette version alertent.

Éditeur

Un éditeur entier : microsoft, apache… Toute CVE d’un produit de cet éditeur peut alerter. Un éditeur ne porte jamais de version (la colonne affiche « — »). À réserver aux éditeurs dont vous utilisez beaucoup de produits.

Les noms sont ceux des CVE (le vocabulaire des CPE du NVD) : http_server pour Apache HTTP Server, node.js, linux_kernel… La recherche d’ajout vous les propose ; vous n’avez pas à les connaître par cœur.

Pour qu’une CVE devienne une alerte, le moteur vérifie dans l’ordre :

1. le nom : le produit (ou l’éditeur) de l’élément figure parmi ceux de la CVE, sans tenir compte des majuscules ;
2. l’éditeur, quand l’élément en connaît un (import, détection d’URL, connecteur) : une CVE d’un produit homonyme chez un autre éditeur est écartée ;
3. la version, quand l’élément en porte une : la CVE n’est retenue que si l’une de ses plages de versions affectées couvre la vôtre (une CVE sans aucune plage est retenue par prudence) ;
4. le seuil d’alerte de l’élément (voir Seuil d’alerte).

Quand plusieurs éléments correspondent à la même CVE (par exemple l’éditeur microsoft et un produit Microsoft), une seule alerte est créée pour le projet, rattachée à l’élément le plus large (l’éditeur).

Seules les failles nouvelles deviennent des alertes

Une organisation n’est alertée que des CVE publiées depuis sa création (au jour près). Déclarer sa stack juste après l’inscription ne fait donc remonter aucune alerte pour les failles anciennes : elles restent consultables dans la Base CVE.

À l’ajout d’un élément dans un projet plus ancien, TechWatchAlert rattrape les CVE publiées depuis la création du projet qui le touchent : celles des 12 derniers mois, plus celles du catalogue des failles exploitées (KEV), 150 au plus par ajout, les exploitées d’abord. Elles apparaissent aussitôt dans les Alertes, marquées comme déjà publiées avant l’ajout, et un message l’annonce (« 3 failles déjà publiées touchent la stack du projet : elles sont dans ses alertes. »). Ce rattrapage n’envoie ni e-mail ni notification.

La liste des éléments

Chaque ligne décrit un élément de la stack. Par défaut, la liste est triée par nom, de A à Z.

Colonne	Ce qu’elle montre
Case à cocher	Sélection pour les actions de masse (seulement si vous pouvez retirer des éléments). La case de l’en-tête Tout sélectionner coche les éléments visibles.
Nom	Logo (ou initiale), nom de l’élément et badges. Le nom est un lien vers la Base CVE filtrée sur ce produit ou cet éditeur.
Type	Produit ou Éditeur.
Version	La version surveillée, ou Toutes versions. Cliquable pour la changer.
Seuil d’alerte	La politique du projet ou le seuil propre à l’élément.
Criticité	Seulement quand NIS2 est activée pour le projet (voir Criticité).
Tags	Les tags de l’élément, et le + pour en ajouter.
×	Retire l’élément de la stack.

La stack ne montre ni CPE ni alertes liées : le CPE et l’éditeur apportés par un import ou une détection d’URL sont conservés et servent au rapprochement, sans être affichés ; les alertes se consultent dans Alertes, où chacune dit quel élément l’a déclenchée.

Les badges

• 0 CVE : aucune CVE ne mentionne encore ce nom. Ce n’est pas une erreur : la surveillance reste active et vous serez alerté dès la première. Le badge est recalculé à chaque affichage ; il disparaît le jour où une CVE cite le produit. S’il reste affiché pour un logiciel très connu, vérifiez l’orthographe (le nom attendu est souvent différent du nom commercial).
• GLPI ou Intune : l’élément est tenu à jour par un connecteur d’inventaire. Sa version suit l’inventaire, et il disparaît si le logiciel est désinstallé.

Filtrer, chercher, trier

• Tous / Éditeurs / Produits limite la liste à un type.
• La liste Tous les seuils propose : Politique du projet (éléments qui héritent de la politique), Seuils affinés (éléments qui ont leur propre seuil), puis un seuil précis (Critique, Élevée, Moyenne, Faible, Toutes).
• Rechercher un vendor ou un produit dans cette stack… cherche le texte tapé dans le nom des éléments (majuscules ignorées). La croix vide le champ.
• Les tags : un clic active ou désactive un tag ; plusieurs tags actifs montrent les éléments qui portent au moins un d’entre eux. Réinitialiser désactive tous les tags.

Les filtres se cumulent. Si plus rien ne correspond, la page affiche « Aucun résultat » et un bouton Effacer les filtres.

Le tri se fait par un clic sur Nom, Type ou Seuil d’alerte ; un second clic inverse l’ordre. Le tri par seuil range les éléments selon leur seuil effectif (le leur, sinon celui de la politique), du plus large au plus strict ; à seuil égal, un élément qui hérite passe avant un élément qui affine.

Ajouter un élément à la main

Le bouton Ajouter à la stack ouvre une fenêtre de recherche. Elle sait ajouter plusieurs éléments d’un coup : on les met d’abord dans une file À ajouter, on les règle, puis on valide.

1. Cliquez sur Ajouter à la stack.

2. Choisissez au besoin la portée de la recherche : Éditeurs, Les deux (par défaut) ou Produits. Restreindre la portée sert quand la liste de résultats est trop longue.

3. Tapez un nom dans le champ (au moins un caractère). La liste de suggestions se remplit : les produits et les éditeurs sont groupés, chaque résultat indique les éditeurs qui le publient et le nombre de CVE déjà recensées (« 12 CVE », ou « 0 CVE »). Un résultat déjà présent dans la stack ou déjà dans la file est grisé et marqué déjà ajouté.

   

4. Cliquez sur un résultat, ou choisissez-le avec les flèches et Entrée. Il rejoint la file À ajouter et le champ se vide pour l’élément suivant.

5. Si le nom cherché n’existe dans aucune CVE, la dernière ligne propose Ajouter « … » (saisie libre) : c’est le seul moyen de surveiller un produit avant sa toute première CVE.

6. Réglez chaque élément de la file : son seuil d’alerte (jauge) et, pour un produit, sa version (voir plus bas). La croix retire l’élément de la file.

   

7. Choisissez au besoin le Seuil des éléments ajoutés : il s’applique d’un coup à toute la file (par défaut, la politique du projet).

8. Cliquez sur Ajouter N élément(s).

Quelques raccourcis, rappelés par le i à droite du champ (« Comment ça marche ») :

• Coller une liste : « nginx, openssl, redis » (séparés par des virgules, points-virgules, retours à la ligne ou tabulations) crée trois entrées d’un coup. Taper une virgule ou un point-virgule valide aussi l’entrée en cours. Les noms collés sont ensuite rattachés au catalogue en tâche de fond (« Résolution… ») pour récupérer leur éditeur ; ceux qui ne correspondent à rien sont signalés 0 CVE.
• Au clavier : ↑ ↓ pour parcourir, Origine et Fin pour aller au premier ou au dernier résultat, Entrée pour ajouter, Échap pour fermer la liste, Retour arrière sur un champ vide pour retirer la dernière entrée de la file.

Après l’envoi :

• les éléments déjà présents sont refusés un par un (« “nginx” est déjà dans la stack (la casse ne compte pas). ») ; les autres sont ajoutés ;
• un message confirme le nombre d’éléments ajoutés, et un second annonce les failles rattrapées, s’il y en a (publiées depuis la création du projet) ;
• si l’envoi échoue (droits, quota de l’offre, réseau), un message l’explique et la file reste intacte pour réessayer.

Un élément sans CVE connue est ajouté quand même ; la fenêtre le signale sous la file (« 1 élément(s) sans CVE connue à ce jour. Ils sont ajoutés quand même »).

Les alertes comparent les noms exactement : « httpd » ou « http » dans la stack ne déclenchent jamais rien, alors que les CVE d’Apache portent http_server. Quand un nom n’apparaît dans aucune CVE, la file propose donc les noms proches qui en ont, sous l’élément : « Aucune CVE ne porte ce nom. Vouliez-vous dire : http_server (3 CVE) ». Un clic remplace l’élément. Les propositions viennent des noms courts d’usage (httpd, sshd, postgres…), de l’orthographe proche (une lettre manquante) et des noms des CVE qui contiennent la saisie.

La proposition de suivi des fins de vie

Quand vous ajoutez à la main des produits qui figurent au catalogue des fins de vie (PHP, PostgreSQL, HAProxy…), une fenêtre Suivre les fins de vie ? s’ouvre juste après l’ajout.

• Suivre les nouvelles versions abonne le projet au produit entier : une alerte à chaque nouvelle version publiée.
• La liste Versions montre chaque version du produit avec sa Fin de support et sa Fin de vie. Cochez celles que vous faites tourner pour être prévenu avant leurs échéances. Les versions dont la fin de vie approche (moins de 180 jours) et que vous ne suivez pas encore sont cochées d’avance. Une version déjà dépassée est marquée DÉPASSÉE mais reste cochable : sa fin de support peut être encore à venir.
• Ce qui est déjà suivi est coché et grisé (Déjà suivi).
• Suivre (N) enregistre les abonnements ; Plus tard (ou Échap) ferme sans rien enregistrer.

Cette proposition n’apparaît pas pour les imports de fichier ni pour la détection d’URL. Le détail des abonnements est expliqué dans Fin de vie.

La version : pourquoi elle compte

Un produit sans version surveille toutes ses versions : chaque CVE du produit peut alerter, y compris celles corrigées depuis longtemps chez vous. Avec la version exacte, seules les CVE qui touchent réellement cette version alertent. C’est le réglage qui retire le plus de bruit.

Pour choisir ou changer une version, cliquez sur la pastille de la colonne Version (ou de la file d’ajout) :

• La liste montre les versions connues des CVE pour ce produit, de la plus récente à la plus ancienne (40 au plus). Tapez le début d’un numéro pour la filtrer : le filtre interroge le serveur et trouve aussi des versions plus anciennes que celles affichées.
• Toutes revient à la surveillance de toutes les versions.
• Si votre version n’est pas dans la liste, tapez-la : elle est proposée avec la mention saisie, cliquez dessus (ou Entrée).
• La ligne du bas rappelle l’effet du réglage : « Seules les CVE affectant la version 1.24.0 déclencheront une alerte. »

Tenir la version à jour

Une version déclarée mais dépassée fait manquer les CVE de la version réellement installée, et inversement. Après une mise à jour, changez la version dans la stack. Les connecteurs d’inventaire et les imports de manifeste renseignent des versions exactes ; les scans de vulnérabilités montrent ce qui tourne vraiment.

La version sert aussi au suivi de fin de vie : c’est elle qui rattache un produit à son cycle (« 3.0.13 » appartient au cycle « 3.0 »). Un produit sans version ne peut pas être jugé.

Seuil d’alerte : la politique du projet, affinée par élément

Ce qui alerte se décide d’abord dans la politique de priorisation du projet (réglages du projet, page Alertes ; voir Projets). Le bandeau en haut de la page la résume, par exemple : « Alertes selon la politique du projet (Risque combiné) : à partir de CVSS 7, ou en dessous si la CVE est exploitée. » Le lien Modifier la politique ouvre ce réglage ; sans le droit de régler le projet, il s’intitule Voir la politique et l’ouvre en lecture.

Chaque élément peut affiner ce seuil, dans la colonne Seuil d’alerte :

• la pastille Politique : l’élément hérite de la politique du projet (réglage recommandé). Les cubes montrent alors en atténué l’équivalent de la politique, et le texte à droite dit « CVSS ≥ 7 » ;
• les cinq cubes, de gauche à droite : Toutes (toute CVE), Faible (CVSS ≥ 0,1), Moyenne (CVSS ≥ 4), Élevée (CVSS ≥ 7), Critique (CVSS ≥ 9). Cliquer un cube fixe le seuil de l’élément ; la couleur part du seuil vers la droite : ce qui est coloré déclenchera une alerte. Au clavier, les flèches déplacent le seuil.

Le seuil de l’élément remplace seulement le CVSS minimal de la politique ; le reste de la politique s’applique toujours (par exemple l’alerte sous le seuil pour une CVE exploitée, si la politique la prévoit).

Un élément qui s’écarte de la politique le signale par un triangle ambre, dont l’infobulle chiffre l’écart ; la même phrase s’affiche quelques secondes sous la jauge au moment du choix :

• plus strict : « des CVE de cet élément qui alerteraient pour le projet n’alerteront pas » ;
• plus large : « attendez-vous à davantage d’alertes » ;
• identique mais figé : l’élément ne suivra plus les changements de la politique.

Rien n’est bloqué. Tant qu’au moins un élément affine son seuil, le bandeau l’annonce (« 1 élément s’écarte de la politique du projet. ») avec :

• Les afficher : applique le filtre Seuils affinés ;
• Garder ces affinages (ou la croix) : ferme ce message pour tous les utilisateurs du projet, après confirmation. Les triangles restent sur les lignes ;
• Modifier la politique : pour changer la règle de tous les éléments plutôt que d’affiner un par un.

Pour qu’un élément revienne à la politique, cliquez sur sa pastille Politique.

Criticité (projets sous NIS2)

Quand NIS2 est activée pour le projet et que le module des échéances fait partie de l’offre, une colonne Criticité apparaît. Elle indique ce que chaque élément représente pour l’activité ; elle module les délais de correction de ses vulnérabilités (voir Conformité NIS2).

Par défaut, un élément hérite de la criticité du projet (« Projet : Importante »). La liste permet de choisir Vitale, Importante, Standard ou Faible pour cet élément, ou de revenir à la criticité du projet. Chaque changement est journalisé.

Sur ces projets, un bandeau s’ajoute en haut de la page : la revue d’inventaire, seulement quand elle approche (7 jours avant l’échéance), le jour même ou en retard (échéance, Historique, Attester la revue ; le reste du temps, l’historique est dans l’onglet Revues d’inventaire de l’espace conformité ; voir Registres NIS2). Les scans de vulnérabilités se gèrent dans les réglages du projet, onglet Scans (voir Imports, connecteurs et scans).

Revue d’inventaire

Là où la revue d’inventaire tourne (projets sous NIS2), elle se fait sur la page Stack, là où l’inventaire se tient. L’inventaire de chaque projet doit être revu et la revue attestée à intervalle fixe ; l’historique en garde la preuve.

• Quand une revue est due, en retard ou attendue dans les 7 jours, un bandeau l’annonce en tête de liste : « Revue d’inventaire à faire (dernière le 10 sept.) », avec Historique et Attester la revue.
• Le reste du temps, une ligne discrète rappelle la dernière revue et la prochaine, avec le lien Historique.
• L’adresse /stack#revue (liens des avis et de l’ancienne page Revues d’inventaire) amène au bandeau et ouvre l’historique ; ?projet= choisit le projet.

Les règles :

• prochaine revue = jour de la dernière revue attestée (à défaut, de la création du projet) + l’intervalle (90 jours par défaut, de 7 à 365, réglé dans la politique de correction) ;
• Due le jour même, En retard dès le lendemain ;
• seule une revue attestée remet le compteur à zéro. Un import SBOM est enregistré comme preuve que l’inventaire vit, mais personne n’y atteste avoir retiré ce qui n’existe plus.

Le panneau Historique donne la criticité du projet, ses dates, le dernier import SBOM, puis l’historique : chaque revue attestée et chaque import, avec ce qui a changé depuis la précédente (éléments ajoutés, retirés, versions changées) et le commentaire. En pied : Attester la revue.

1. Relisez la stack du projet.
2. Cliquez sur Attester la revue, dans le bandeau ou le panneau Historique.
3. Cochez les quatre contrôles : éléments obsolètes retirés, versions à jour, composants nouveaux ajoutés, criticités vérifiées. Trois sur quatre n’attestent rien : le bouton reste inactif.
4. Ajoutez un commentaire si besoin (périmètre, sources, écarts), puis Attester la revue.

L’attestation est datée, signée de votre nom et conservée. Attester demande le droit de projet « Attester une revue d’inventaire » (analyste et au-delà par défaut).

Rappels : quand la revue devient due, les administrateurs et le propriétaire du projet ainsi que le responsable de la sécurité sont prévenus, une fois par échéance (workflow NIS2 · Revues d’inventaire).

Tags

Les tags de l’organisation (créés dans les réglages de l’organisation, page Étiquettes) servent à classer les éléments : exposé à Internet, données de santé, production…

• Le + de la colonne Tags ouvre la liste des tags ; un clic ajoute ou retire un tag (coche = posé).
• La croix d’une pastille retire le tag.
• Sans aucun tag dans l’organisation, la liste le dit (« Aucun tag — créez-en dans Réglages de l’organisation → Tags. »).

Modifier et retirer des éléments

• Version et seuil se changent directement dans la ligne ; l’enregistrement est immédiat.
• La × en bout de ligne retire l’élément, sans confirmation. Les alertes déjà créées pour cet élément restent dans les alertes.

Actions de masse

Cochez des éléments (ou Tout sélectionner, qui coche les éléments visibles avec les filtres en cours) : une barre apparaît au-dessus de la liste.

• Seuil d’alerte… applique un seuil aux éléments sélectionnés, ou Revenir à la politique du projet ; un message résume l’écart obtenu.
• Criticité… (projets sous NIS2) applique une criticité, ou celle du projet.
• Ajouter un tag… pose un tag sur toute la sélection (les tags déjà posés sont conservés).
• Retirer retire tous les éléments sélectionnés, sans confirmation.
• Désélectionner vide la sélection.

Seuil d’alerte… et Ajouter un tag… ne sont proposés qu’avec le droit de modifier la stack ; Criticité… suit le droit de régler la criticité ; Retirer suit le droit de retirer de la stack.

Stack vide et préréglages

Quand la stack du projet est vide, la page propose de Partir d’une base : six préréglages qui ajoutent chacun cinq ou six produits courants, à ajuster ensuite.

Préréglage	Produits ajoutés
Web PHP / LAMP	http_server, php, mysql, openssl, wordpress, linux_kernel
Node & front	node.js, next.js, express, nginx, openssl, postgresql
Python	django, flask, requests, urllib3, postgresql, redis
Java / JVM	tomcat, spring_framework, log4j, openjdk, jenkins
Conteneurs & K8s	kubernetes, docker, containerd, traefik, grafana, prometheus
Poste de travail	windows_11, office, edge, acrobat_reader, firefox, 7-zip

Les trois boutons Ajouter à la stack, Détecter depuis une URL et Importer un fichier restent proposés sous les préréglages. Les préréglages ajoutent des produits sans version : pensez à renseigner les versions ensuite.

Sur téléphone

La liste devient une suite de cartes (nom, type, version, jauge de seuil en grand, criticité, tags). L’ajout se fait par le bouton + flottant ; le bouton … de l’en-tête regroupe la détection d’URL, l’import de fichier et le mode Sélectionner ; les filtres sont dans une feuille qui s’ouvre depuis l’icône de réglage, à droite de la recherche.

Qui peut faire quoi

Les droits sont ceux du rôle de chacun dans le projet (voir Équipe, rôles et groupes), réglables finement par l’administration.

Action	Utilisateur	Analyste	Admin	Propriétaire
Voir la stack	✓	✓	✓	✓
Ajouter (à la main, préréglage, URL)		✓	✓	✓
Importer un fichier (SBOM, manifeste)		✓	✓	✓
Changer version et seuil, gérer les tags		✓	✓	✓
Retirer des éléments, actions de masse		✓	✓	✓
Changer la criticité (projets NIS2)		✓	✓	✓
Fermer l’avertissement des seuils affinés		✓	✓	✓

Chaque action suit un droit précis, le même dans l’interface et sur le serveur :

• Ajouter (droit « Ajouter à la stack », colonne Créer de la matrice) : sans lui, l’en-tête affiche « Vous pouvez consulter cette stack, mais vous n’avez pas le droit d’y ajouter d’éléments sur ce projet. » ;
• Importer un fichier (droit « Importer (SBOM / lot) ») : sans lui, le bouton Importer un fichier n’apparaît pas ;
• Modifier la version, le seuil et les tags d’un élément : droit « Modifier un élément » ou « Ajouter à la stack » ; sans l’un ni l’autre, ces valeurs s’affichent en lecture ;
• Retirer (droit « Supprimer de la stack ») : sans lui, la mention Lecture seule s’affiche à côté du nombre de résultats et les boutons de retrait disparaissent.

Ce qui dépend de l’offre

• La page Stack elle-même doit être comprise dans l’offre de l’organisation ; si elle ne l’est pas, son entrée de menu est verrouillée et ouvre le choix des offres.
• Le nombre d’éléments de stack est plafonné par l’offre, pour toute l’organisation (les stacks de tous ses projets réunies). Avec les réglages par défaut de l’instance : 10 éléments en Free, 200 en Team, illimité en Pro et Business. La page Abonnement et facturation montre la consommation.
• Un ajout qui dépasserait le plafond est refusé en entier ; un message l’indique et la fenêtre de choix des offres s’ouvre.

Questions fréquentes

Un collègue voit-il les éléments que j’ajoute ? Oui : la stack est celle du projet (voir l’encadré en haut de page). Un élément ajouté par l’un est surveillé pour toute l’équipe, et les alertes qu’il déclenche apparaissent dans la liste de tous les membres.

Un membre quitte le projet : ses éléments disparaissent-ils ? Non. Les éléments appartiennent au projet, pas à la personne qui les a ajoutés : ils restent dans la stack, de même que les connecteurs et les URL suivies.

J’ai ajouté un produit, mais il affiche « 0 CVE ». Aucune CVE ne cite encore ce nom. Si le produit est connu, cherchez-le à nouveau dans la fenêtre d’ajout : le nom attendu (celui des CVE) diffère souvent du nom commercial (http_server pour Apache).

Puis-je surveiller deux versions du même produit ? Pas depuis la fenêtre d’ajout, qui refuse un nom déjà présent quelle que soit sa version. Les connecteurs d’inventaire et le suivi automatique d’une URL, eux, peuvent ajouter une ligne par couple produit-version.

Retirer un élément supprime-t-il ses alertes ? Non. Les alertes restent ; simplement, aucune nouvelle alerte ne viendra de cet élément.

Imports, connecteurs et scansSBOM, manifestes, détection d'URL, GLPI, Intune, scans Trivy et Grype.

Fin de vieSuivre les dates de fin de support des produits de la stack.

AlertesLes CVE qui touchent la stack.

Alimenter sa stack (API)Les chemins d'alimentation et leur précision.