Glossaire
Chaque terme est suivi de l’endroit où vous le rencontrez dans l’application et de la page du guide qui en parle.
Vulnérabilités et signaux
Section intitulée « Vulnérabilités et signaux »Common Vulnerabilities and Exposures. L’identifiant public d’une vulnérabilité, de la forme CVE-2021-44228 (année, puis numéro). Une CVE décrit une faille, les produits et versions touchés, et les versions qui la corrigent.
Où : la Base CVE (Surveillance › CVEs), chaque alerte, la recherche (Ctrl K). Voir Base CVE.
Common Vulnerability Scoring System. Une note de gravité de 0 à 10, calculée à partir de la façon dont la faille s’exploite (à distance ou non, avec ou sans droits, avec ou sans action de l’utilisateur) et de ses conséquences. L’application la traduit en niveaux : Critique, Élevée, Moyenne, Faible, Aucune.
Où : sur chaque CVE (propriété Score CVSS et section repliable Détail CVSS), les pastilles de gravité, le widget Exposition ouverte du tableau de bord, et la priorisation (« Alerte dès CVSS 7 »). Voir Base CVE.
Exploit Prediction Scoring System, publié par FIRST.org. La probabilité qu’une faille soit exploitée dans les 30 jours, de 0 à 100 %. Là où le CVSS dit « à quel point c’est grave », l’EPSS dit « à quel point c’est probable ».
Où : la pastille EPSS 94 % des listes, la fiche CVE, la distribution EPSS des Statistiques, les conditions de workflow, le modèle de priorisation Exploitation d’abord.
Exploitation avérée
Section intitulée « Exploitation avérée »Une faille dont on sait qu’elle est déjà utilisée par des attaquants. TechWatchAlert réunit pour cela plusieurs sources : le catalogue KEV, l’EUVD, le CERT-FR et VulnCheck.
Où : la pastille Exploitée, les modèles de priorisation (« exploitation avérée d’abord »), le déclencheur de workflow correspondant. Une faille exploitée alerte même sous le seuil de CVSS avec le modèle par défaut.
Known Exploited Vulnerabilities, le catalogue de la CISA (l’agence de cybersécurité américaine) qui recense les failles exploitées dans la réalité.
Où : l’exploitation avérée (pastille Exploitée), le déclencheur de workflow Ajout au KEV, le filtre « KEV » de la Base CVE, le graphique « KEV ajoutées par mois » des Statistiques.
European Union Vulnerability Database, la base européenne de vulnérabilités tenue par l’ENISA. Elle signale aussi les failles exploitées.
Où : les sources de l’exploitation avérée, le lien « Voir … sur le site de l’EUVD » d’une fiche CVE.
Le centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques, rattaché à l’ANSSI. Il publie des avis et des alertes de sécurité.
Où : la pastille CERT-FR sur une CVE citée par le CERT-FR, les Sources nationales de l’espace Conformité NIS2, les sources de l’exploitation avérée.
Rançongiciel
Section intitulée « Rançongiciel »Logiciel malveillant qui chiffre les données pour exiger une rançon. Une faille utilisée par des rançongiciels (selon les catalogues KEV de la CISA ou de VulnCheck) est signalée à part : elle est à corriger en priorité.
Où : la pastille rançongiciel d’une CVE et l’explication « pourquoi cette alerte ».
Proof of Concept, preuve de concept : un code public qui démontre comment exploiter une faille. Sa publication rend l’attaque plus facile, donc plus probable.
Quatre sources sont suivies : les dépôts GitHub recensés par nomi-sec/PoC-in-GitHub, Exploit-DB, les modules Metasploit et les modèles de détection Nuclei. Elles donnent la maturité de l’exploit : Exploitée (exploitation avérée), Exploit outillé (un module Metasploit ou un modèle Nuclei permet l’attaque sans écrire de code), Preuve de concept publique (GitHub, Exploit-DB) ou aucune.
Où : la pastille PoC 3 (ou Outillé pour un exploit outillé), la section Exploitation d’une fiche CVE (bouton Voir les PoCs), le déclencheur de workflow PoC publié et la condition PoC disponible ?.
Stakeholder-Specific Vulnerability Categorization, une méthode de décision de la CISA : plutôt qu’une note, elle qualifie l’exploitation, l’impact et l’automatisation possible de l’attaque.
Où : la section Exploitation d’une fiche CVE, quand la CISA l’a publiée.
Common Weakness Enumeration. Le catalogue des types de faiblesses (injection SQL, dépassement de tampon…). Une CVE est une faille précise ; sa CWE dit de quelle famille elle relève.
Où : la propriété Faiblesses d’une fiche CVE, le « Top 15 faiblesses (CWE) » des Statistiques.
CVE Numbering Authority. L’organisme (éditeur, CERT, chercheur) qui a attribué l’identifiant CVE et publié la fiche d’origine, avec souvent son propre score CVSS.
Où : la mention Attribuée par de l’en-tête d’une fiche CVE ou d’une fiche d’alerte ; le Détail CVSS présente un onglet par source quand plusieurs scores existent.
NVD, GHSA, OSV
Section intitulée « NVD, GHSA, OSV »Des bases publiques qui complètent les CVE : la NVD (base américaine), les avis de sécurité GitHub (GHSA) et la base OSV des écosystèmes open source.
Où : les sources des Versions corrigées et des Références d’une fiche CVE ; une fiche « pré-publiée via des advisories externes (GHSA/OSV) » quand la CVE n’est pas encore dans la base officielle.
Inventaire
Section intitulée « Inventaire »L’inventaire d’un projet : les éditeurs et les produits qu’il utilise, avec leur version si vous la connaissez. La stack appartient au projet et elle est commune à toute son équipe ; imports, connecteurs et suivi automatique des URL l’alimentent aussi. C’est elle qui décide des alertes : une CVE qui ne touche rien de la stack n’alerte pas.
Où : Surveillance › Stack, l’assistant de démarrage. Voir Stack.
Common Platform Enumeration. L’identifiant normalisé d’un produit (éditeur:produit:version), utilisé par les CVE pour dire ce qu’elles touchent. Chaque élément de la stack est rattaché au catalogue CPE : c’est ce rattachement qui permet de reconnaître vos produits dans les CVE. Un élément non rattaché (en orange) n’émet aucune alerte.
Où : la saisie assistée de la stack (suggestions « Produits » et « Éditeurs »), le filtre « Avec CPE » de la Base CVE, l’explication d’une alerte écartée (« les références CPE de la CVE désignent un autre éditeur »).
Software Bill of Materials, nomenclature logicielle : la liste des composants d’un logiciel, produite par les outils de build. TechWatchAlert lit le format CycloneDX (JSON ou XML).
Où : Importer un fichier sur la page Stack et Imports, connecteurs et scans ; l’essai sans compte.
Manifeste
Section intitulée « Manifeste »Le fichier de dépendances d’un projet logiciel (package.json, requirements.txt, go.mod…). TechWatchAlert en extrait les composants.
Où : les imports de la Stack, l’essai sans compte.
Fin de vie (EOL)
Section intitulée « Fin de vie (EOL) »End of Life. La date à partir de laquelle l’éditeur ne publie plus aucun correctif pour une version. La fin de support actif, qui la précède souvent, est la fin des évolutions et corrections ordinaires. Un composant hors support peut garder des failles connues sans correction possible.
Où : Surveillance › Fin de vie, les notifications « fin de vie dans N jours », le widget des échéances, les workflows par défaut de fin de vie. Voir Fin de vie.
URL surveillée
Section intitulée « URL surveillée »Un site que TechWatchAlert visite régulièrement pour détecter les technologies exposées (et alimenter la stack) et suivre l’expiration de son certificat HTTPS.
Où : Surveillance › URLs. Voir URLs surveillées.
Organisation du travail
Section intitulée « Organisation du travail »Organisation
Section intitulée « Organisation »L’espace de travail d’une entreprise ou d’une équipe : membres, rôles, abonnement, politique de priorisation, SSO, clés API. Voir Organisations.
Un périmètre surveillé dans une organisation (une application, un site, un parc). Tout le travail de veille y est rattaché et partagé par son équipe : la stack, les alertes et leurs dossiers, les workflows et webhooks, les rapports de veille et les réglages du projet (politique de priorisation, délais de fin de vie, envoi des webhooks). Le projet actif se choisit en haut de la barre latérale. Voir Projets.
Politique de priorisation
Section intitulée « Politique de priorisation »Les règles de l’organisation qui fixent l’ordre des alertes et ce qui déclenche une alerte. Quatre modèles sont proposés (Risque combiné, Exploitation d’abord, CVSS + exploitation avérée, CVSS seul), ou des réglages personnalisés.
Où : l’assistant de démarrage, les réglages de l’organisation, le rappel en tête de la page Stack. Voir Premiers pas et Organisations.
Le signal qu’une CVE touche la stack d’un projet et passe la politique de priorisation. Il y a une alerte par projet et par CVE, commune à l’équipe : un nouveau membre voit les alertes existantes. Seul l’état lu ou non lu est propre à chacun. Seules les CVE publiées depuis la création du projet deviennent des alertes : une faille plus ancienne se consulte dans la base CVE, sans alerte. Quand une faille publiée depuis cette date touche un composant qu’on vient d’ajouter, l’alerte est créée aussitôt (« failles déjà publiées… : elles sont dans ses alertes »).
Où : Vue d’ensemble › Alertes et son badge. Voir Alertes.
Dossier (suivi)
Section intitulée « Dossier (suivi) »Le traitement d’une CVE dans un projet, que l’application appelle aussi suivi. Ses statuts : À traiter, En analyse, En remédiation, Risque accepté, Résolu, Non applicable. Il y a un dossier par projet et par CVE, partagé par l’équipe : statut, notes internes, fil de commentaires, historique (qui a fait chaque changement), personne assignée, tags et ticket sont les mêmes pour tous ; seule la lecture (alerte et commentaires lus) est propre à chacun. Chaque action sur le dossier suit un droit précis : sans droit d’écriture, la fiche s’affiche en lecture seule.
Où : la fiche d’une alerte (barre de suivi, colonne Dossier), le widget Dossiers du projet et les indicateurs de traitement du tableau de bord. Voir Traiter une alerte.
Assigné à (affectation)
Section intitulée « Assigné à (affectation) »Les personnes qui portent un dossier pour l’équipe : une ou plusieurs par dossier, choisies parmi les membres du projet qui voient les dossiers. Chacune est prévenue dans sa cloche et par e-mail (préférence Assignations) ; leurs initiales apparaissent dans la liste des alertes, dont le filtre Mes assignations retrouve vos dossiers. Les indicateurs en portée Assignés à moi ne comptent que les dossiers dont la CVE vous est assignée. Un membre qui quitte le projet perd ses affectations.
Où : la ligne Assigné à de la section Dossier et le bouton Assigner de la barre de suivi d’une fiche d’alerte, la barre d’actions et la colonne d’initiales de la liste des alertes, la roue crantée des indicateurs de traitement. Voir Assigner le dossier.
Un libellé coloré, défini par l’organisation (« Production », « Exposé Internet »…), qu’on pose sur le dossier d’une CVE dans un projet, sur un élément de stack ou sur un projet. Les tags d’un dossier sont communs à l’équipe ; ils servent à filtrer les alertes, dans les rapports et dans les workflows (action « Ajouter un tag »).
Où : la ligne Tags de la section Dossier d’une fiche d’alerte, le filtre Tags de la liste des alertes, la page Étiquettes des réglages de l’organisation. Voir Organisations.
Le premier tri des alertes : décider lesquelles analyser, corriger, accepter ou écarter.
Où : le widget Dossiers du projet (« À traiter », « En analyse », « En remédiation », « Rien à trier »). Voir Traiter une alerte.
Non applicable
Section intitulée « Non applicable »Le statut d’un dossier pour une CVE qui ne concerne pas le projet : faux positif, composant non exposé, fonction désactivée. C’est ainsi qu’on écarte une CVE, avec un motif facultatif publié dans les commentaires ; le dossier passe dans l’Historique pour toute l’équipe et peut être rouvert. Pour tout un composant, on règle la stack (seuil d’alerte ou retrait).
Où : le bouton Non applicable de la barre de suivi de la fiche d’alerte. Voir Traiter une alerte.
Risque accepté
Section intitulée « Risque accepté »La décision formelle de ne pas corriger une faille (ou pas tout de suite), avec analyse, mesures compensatoires, approbation et date de revue. Plus engageant que Non applicable : la CVE vous concerne, mais vous ne la corrigez pas.
Où : le statut Risque accepté d’un dossier et le Registre des risques acceptés de l’espace NIS2. Voir Registres.
Workflow
Section intitulée « Workflow »Une automatisation « déclencheur → conditions → actions » (créer un suivi, notifier, envoyer un e-mail, appeler un webhook…). Toute notification passe par un workflow ; chaque projet en reçoit cinq par défaut.
Où : Espace de travail › Workflows. Voir Workflows.
Une adresse web (la vôtre ou celle d’un outil comme Slack ou Teams) que TechWatchAlert appelle pour transmettre un événement, au format JSON ou au format attendu par l’outil. Chaque appel est signé (en-têtes X-TWA-Timestamp et X-TWA-Signature), pour que le destinataire vérifie qu’il vient bien de TechWatchAlert.
Où : les réglages du projet (Webhooks du projet, et l’interrupteur Envoyer les webhooks de la carte Notifications de l’équipe), l’action « Appeler les webhooks » des workflows. Voir Notifications et canaux.
Comptes et accès
Section intitulée « Comptes et accès »Rôle, groupe
Section intitulée « Rôle, groupe »Le rôle fixe ce qu’un membre peut faire dans une organisation ou un projet ; un groupe attribue des rôles à plusieurs membres d’un coup. Voir Équipe, rôles et groupes.
Double authentification (2FA)
Section intitulée « Double authentification (2FA) »Un code à 6 chiffres, produit par une application d’authentification, demandé après le mot de passe. Des codes de récupération à usage unique servent si l’application est perdue.
Où : Paramètres › Sécurité, l’écran Vérification en 2 étapes. Voir Compte et connexion.
Single Sign-On, authentification unique : la connexion passe par le fournisseur d’identité de l’entreprise (OIDC). Une organisation peut l’imposer à ses domaines.
Où : le bouton Se connecter via le SSO de votre organisation de l’écran de connexion, les réglages de l’organisation. Voir Organisations.
Un secret qui permet à un programme d’interroger TechWatchAlert sans mot de passe.
Où : les réglages de l’organisation (Clés API de l’organisation) ; l’usage est décrit dans la partie API de la documentation.
Plan (offre)
Section intitulée « Plan (offre) »L’abonnement de l’organisation : Free (gratuit), Team, Pro, Business. Il fixe les modules inclus et les limites (projets, membres, éléments de stack, URLs). Un module non inclus est signalé par un cadenas.
Où : Abonnement dans le menu utilisateur, les cadenas de la barre latérale. Voir Abonnement et facturation.
Conformité et prestataires
Section intitulée « Conformité et prestataires »La directive européenne (UE) 2022/2555 sur la sécurité des réseaux et des systèmes d’information. L’espace Conformité NIS2 outille la partie qui touche aux vulnérabilités, à l’inventaire, aux fournisseurs et aux incidents, et produit les preuves à présenter ; il ne rend pas « conforme » à lui seul.
Où : Conformité › Conformité NIS2, activé projet par projet. Voir Conformité NIS2.
Managed Service Provider, prestataire de services infogérés : il administre l’informatique de plusieurs clients. Avec l’offre Partner, il dispose de l’Espace partenaire, qui réunit tous ses clients.
Où : sélecteur Contexte › Espace partenaire, en haut de la barre latérale. Voir Espace partenaire.
Marque blanche
Section intitulée « Marque blanche »Le logo du prestataire à la place de celui de TechWatchAlert : sur les rapports PDF de ses clients (veille, NIS2, registres, fiches d’incident) et dans leur barre latérale. Selon l’offre du prestataire, la mention « via TechWatchAlert » reste affichée.
Où : Espace partenaire › Marque pour le logo du partenaire ; réglages de l’organisation d’un client pour son propre logo. Voir Équipe, facturation et marque.
Le nom de l’assistant IA. On lui parle en conversation privée par l’entrée Vigie du sélecteur de canaux des Discussions (rail des discussions au bord droit de l’écran, Ctrl J). Elle n’entre pas dans les discussions d’équipe (canal de l’organisation, messages privés).