Technologies, un SBOM côté client avec détection des CVE
Les bibliothèques JavaScript que vos visiteurs chargent, avec version, statut et CVE connues, depuis les reports de hash CSP. Sans agent ni crawler.
Dernière mise à jour:
Technologies liste chaque bibliothèque JavaScript que les navigateurs de vos visiteurs chargent sur un site web. Chaque bibliothèque est accompagnée de sa version, d'une indication sur l'actualité de cette version, et des entrées Common Vulnerabilities and Exposures (CVE) qui la concernent. C'est un SBOM côté client (software bill of materials) : la liste des bibliothèques et des versions qui s'exécutent réellement dans les navigateurs de vos visiteurs, construite à partir de ce que de vrais navigateurs rapportent plutôt qu'à partir des paquets de votre build.
La page se trouve sous chaque site web, dans l'entrée Technologies. Tous les rôles du site web peuvent la consulter.
Technologies dépend de votre plan. Sur les plans qui ne l'incluent pas, l'entrée de la barre latérale est désactivée. Comparez les plans sur la page des tarifs ou dans Paramètres > Facturation.
Les questions auxquelles elle répond
Ouvrez la page quand vous cherchez l'une de ces réponses :
- Quelles bibliothèques tournent sur ce site, et dans quelle version.
- Lesquelles embarquent une vulnérabilité connue, et de quelle sévérité.
- Vers quelle version mettre à jour chacune, ou s'il faut la remplacer.
- Lesquelles sont en retard de version, sur une ancienne branche majeure, dormantes ou plus maintenues.
- Quels fichiers de script portent chaque bibliothèque, et depuis quelle URL.
- Quand une bibliothèque est apparue, a changé de statut ou a reçu un nouvel avis de sécurité.
La page Premiers pas vous mène d'une page vide à un inventaire passé en revue, avec des alertes.
Origine des données
Les navigateurs rapportent un hash de chaque script qu'ils exécutent quand votre politique de sécurité du contenu (CSP) contient 'report-sha256'. Pour chaque script rapporté, le moteur CentralCSP identifie la technologie, sa version, son statut de cycle de vie et les CVE connues qui la concernent. Pour vérifier une seule page publique sans compte, utilisez l'analyseur de technologies gratuit.
L'inventaire reflète ce que les navigateurs ont chargé, donc il inclut les tags tiers, les copies servies par un CDN et les scripts injectés par un gestionnaire de tags, que jamais une analyse de l'arborescence source ne liste. Deux conséquences en découlent, et une limite :
- Une bibliothèque apparaît peu de temps après le premier report de son script. Il n'y a aucun crawler à planifier, aucun agent à installer et aucun dépôt à connecter.
- CentralCSP revérifie régulièrement les technologies connues, donc un avis publié récemment ou un changement de statut apparaît de lui-même.
- Seuls les scripts chargés depuis une URL sont analysés. Les scripts inline ne font pas partie de l'inventaire.
Les mêmes reports csp-hash alimentent la page Hashes CSP et la file de revue PCI DSS (Payment Card Industry Data Security Standard), les deux moitiés de l'inventaire de scripts. Technologies ajoute par-dessus la couche bibliothèque, version et vulnérabilités.
Ce que contient une ligne
L'inventaire compte une ligne par version de bibliothèque, donc deux versions de la même bibliothèque font deux lignes. Chaque ligne a les colonnes suivantes :
| Colonne | Signification |
|---|---|
| Technologie | Le nom et l'icône de la bibliothèque |
| Version | La version identifiée par le moteur, ou Inconnu quand seule la bibliothèque a été reconnue |
| Statut | La place de cette version dans le cycle de vie de la bibliothèque |
| Vulnérabilités | Le nombre d'avis qui concernent cette version, avec la sévérité la plus haute parmi eux, ou Aucune vulnérabilité connue |
| Recommandé | La version vers laquelle mettre à jour, Trouver une alternative quand aucune version maintenue n'existe, ou un tiret quand rien n'est recommandé |
| Scripts | Le nombre de fichiers de script distincts du site qui portent cette version |
| Première apparition | La date du premier report d'un script portant cette version |
| Vu pour la dernière fois | La date du dernier report |
Les valeurs de statut sont décrites dans Statuts de version, et la recommandation dans Mise à jour recommandée.
Le tableau liste d'abord les versions vulnérables, de la plus sévère à la moins sévère, puis les autres du statut le plus urgent jusqu'à à jour, et en dernier les versions qu'il n'a pas pu identifier.
Les quatre cartes de synthèse résument le tableau : technologies détectées, technologies avec au moins une vulnérabilité connue, technologies pas à jour, dépassées ou obsolètes, et nombre de scripts distincts associés à une bibliothèque.
Sélectionner une ligne ouvre le panneau de la technologie avec ses avis, ses scripts et son historique. Consultez Examiner une technologie.
Statuts de version
Chaque ligne porte un statut de cycle de vie. Le statut décrit la version que vous utilisez, pas la bibliothèque dans son ensemble. Voici ce que signifie chaque statut :
| Statut | Signification | Que faire |
|---|---|---|
| À jour | La version est la dernière publiée | Rien |
| Pas à jour | Une version plus récente existe dans la même branche majeure | Planifier la mise à niveau, plus tôt si la ligne est aussi vulnérable |
| Dépassée | La version appartient à une branche majeure plus ancienne que celle que la bibliothèque publie encore | Planifier le passage à la branche majeure actuelle |
| Dormant | La bibliothèque n'a rien publié depuis longtemps | Vérifier qu'elle est encore maintenue avant d'en dépendre |
| Obsolète | La branche de cette version n'est plus maintenue et ne reçoit plus de correctifs de sécurité | Passer à une branche maintenue, ou remplacer la bibliothèque quand elle n'en a plus |
| Inconnu | La bibliothèque a été reconnue, pas sa version | Vérifier le script vous-même |
Une version obsolète ne recevra aucun correctif pour son prochain avis. Quand la bibliothèque maintient encore une branche plus récente, la mise à jour recommandée pointe vers elle. Quand plus aucune branche n'est maintenue, la recommandation est de trouver une alternative. Une version inconnue ne peut pas être confrontée aux avis, car la mise en correspondance des vulnérabilités a besoin d'une version à comparer.
Une ancienne branche majeure cesse généralement de recevoir des correctifs avant la branche actuelle, et l'écart se creuse à chaque version. Passer à la branche actuelle est une mise à niveau majeure : lisez d'abord les notes de version de la bibliothèque pour repérer les changements incompatibles.
La carte Pas à jour ou obsolètes compte les trois statuts qui appellent une action : Pas à jour, Dépassée et Obsolète. Dormant est un signal d'alerte plutôt qu'un constat, et Inconnu signifie que l'analyse n'a pas pu aller plus loin.
Mise à jour recommandée
Pour chaque version, CentralCSP recommande la version vers laquelle passer, vérifiée contre chaque avis connu de la bibliothèque, pour ne jamais pointer vers une version qu'un autre avis concerne encore. Le panneau indique pourquoi cette version a été choisie :
| Raison | Signification |
|---|---|
| Corrige toutes les vulnérabilités connues | La première version qu'aucun avis connu ne concerne |
| Dernière version de cette branche | La version la plus récente de la branche majeure que vous utilisez |
| Dernière version de la dernière branche | La version la plus récente de la branche que la bibliothèque maintient encore, pour une version sur une branche plus ancienne ou abandonnée |
| Dernière version publiée | La version la plus récente connue, quand la version ne correspond à aucune branche |
| Aucune version maintenue | Plus aucune branche de la bibliothèque n'est maintenue, donc aucune mise à jour ne la corrige. La recommandation est Trouver une alternative |
Le panneau montre aussi la dernière version de votre branche et de la dernière branche, et prévient quand la dernière branche commence une nouvelle version majeure, pour que vous lisiez ses changements incompatibles avant de mettre à jour. Rien n'est recommandé pour une version qui est déjà la dernière.
Sévérité
Chaque avis porte un niveau de sévérité : Faible, Moyen, Élevé ou Critique. La sévérité d'une technologie est la plus haute parmi les avis qui concernent sa version, et le tableau trie selon elle, donc la ligne qui compte le plus est la première.
Un avis sans sévérité attribuée compte quand même comme une vulnérabilité. Il s'affiche comme Sans sévérité dans le panneau et ne relève pas la sévérité de la ligne.
Combien de temps une technologie reste listée
Une technologie reste dans l'inventaire tant que les navigateurs continuent de rapporter un script qui la porte. Quand aucun script portant une version n'a été rapporté pendant sept jours, la version quitte l'inventaire. Son historique est conservé, donc une bibliothèque qui revient après un retour arrière de déploiement est de nouveau listée comme détectée, avec ses entrées précédentes toujours attachées.
Le plafond quotidien d'analyses
Chaque site web peut envoyer à l'analyse un nombre limité de scripts nouveaux, jamais vus, par jour. Un site qui sert des milliers de fichiers de script distincts en une journée, par exemple un build qui donne à chaque utilisateur une URL de bundle unique, atteint ce plafond. La page affiche alors Inventaire en pause pour aujourd'hui. Les bibliothèques déjà reconnues continuent d'être suivies. Les scripts au-delà du plafond sont analysés le lendemain.
Si la bannière apparaît chaque jour, les URL de script du site changent à chaque requête. Stabilisez les URL, ou acceptez que l'inventaire couvre le sous-ensemble stable.
Accès par l'API et le MCP
Tout ce que montre la page est disponible sur l'API REST sous la ressource technologies du site web : la liste avec les mêmes filtres, les compteurs de synthèse, l'export CSV, une technologie avec ses avis, sa mise à jour recommandée et ses scripts, son historique, et les technologies qu'embarque un script donné. Consultez la référence API.
Le serveur Model Context Protocol (MCP) expose la liste via l'outil en lecture seule list_technologies et une technologie via get_technology, donc un client IA peut répondre à « quelles bibliothèques de ce site ont une CVE critique, et vers quoi les mettre à jour » à partir des mêmes données.
Étapes suivantes
Inventaire de scripts
Chaque script que les navigateurs chargent sur votre site, internes et tiers, regroupés par origine, avec les hashes et la bibliothèque derrière chacun.
Démarrer
De la page Technologies vide à un SBOM côté client vérifié, avec alertes. Confirmez les reports de hash, traitez les lignes vulnérables, ajoutez deux règles.