Comment une équipe sécurité garde les scripts tiers sous contrôle sur toutes ses propriétés web

Le problème est dans l’organigramme. L’équipe sécurité porte le risque de chaque script exécuté sur chaque propriété de l’entreprise, et presque aucune des personnes qui ajoutent ces scripts ne lui rend compte. Le marketing a son tag manager. Les équipes produit livrent leurs expérimentations. L’agence qui gère les microsites de campagne a son propre conteneur, sur un domaine validé vaguement en 2024. Le tag manager a rendu l’injection de scripts self-service, c’était son but, et la revue sécurité est devenue optionnelle en chemin, ce qui ne l’était pas.

Le modèle qui tient a deux moitiés. D’abord l’inventaire par observation plutôt que par déclaration : construit depuis les navigateurs des visiteurs, il enregistre ce qui s’exécute vraiment sur chaque propriété, avec hashes d’intégrité et, sur Scale, versions de bibliothèques confrontées aux CVE, déployé par un seul en-tête de réponse quelle que soit la stack. Ensuite une boucle de gouvernance par-dessus : des règles d’alerte sur les nouvelles origines de script de chaque propriété et sur les scripts non justifiés des pages de paiement, routées vers le SOC, et un workflow de justification qui garde trace de qui a approuvé chaque script, et pourquoi. CentralCSP fournit les deux. L’inventaire est présent sur toutes les offres, dès 39,99 €/mois (Start : 3 sites, 5 utilisateurs, 250 000 rapports par mois).

Pourquoi l’inventaire déclaratif échoue

L’approche classique, c’est le questionnaire. Un mail à chaque équipe, une liste de scripts en retour, une fusion dans un tableur, une présentation en comité trimestriel.

Trois choses déraillent, à chaque fois. Les gens listent ce qu’ils se souviennent d’avoir ajouté, pas ce qui est là : l’essai de heat-mapping du deuxième trimestre que personne n’a coupé ne figure sur aucune liste. Les conteneurs de tags changent chaque semaine et rien de tout cela n’atterrit dans le tableur. Et les agences répondent pour les propriétés auxquelles elles pensent encore, pas pour celles qui servent encore du trafic.

Nous avons lu beaucoup de ces tableurs. Version polie : ils décrivent une intention, pas un site. Version honnête : la fusion prend plus de temps que les données ne restent vraies.

Inventorier en observant : les navigateurs savent déjà

Chaque script qui s’exécute le fait dans un navigateur, et le reporting CSP permet à ces navigateurs de vous le dire. Ajoutez les hashes de reporting report-sha256, report-sha384 ou report-sha512 sous vos directives script, pointez l’en-tête Reporting-Endpoints vers l’endpoint géré du site (https://MyEndpoint.report.centralcsp.com, un sous-domaine par site), et le navigateur de chaque visiteur déclare les scripts qu’il exécute : origine, URL complète, hash d’intégrité et historique des hash, première et dernière observation, page par page. Aucun agent dans la page, aucun crawler.

Pour une équipe sécurité, l’argument décisif est le déploiement. Prenez un portefeuille typique : un storefront Next.js, un site marketing WordPress, un portail Java hérité, un site de documentation et ce que l’agence a construit. Déployer un agent, c’est cinq projets d’intégration à négocier avec cinq équipes sur cinq stacks. Un en-tête de réponse, c’est une ligne dans la configuration serveur ou CDN de chaque propriété, la même partout, quelques minutes par site. Et chaque propriété devient son propre site dans l’espace de travail, avec son plafond de rapports, son filtre d’ingestion sur les origines autorisées à rapporter et ses rôles de site : les flux ne se mélangent jamais, et l’agence obtient le rôle Viewer sur ses microsites et rien d’autre.

Les données venant de vrais visiteurs, elles couvrent ce qu’un crawler ne verra jamais : les pages authentifiées, les variantes géo-ciblées, le script qu’un test A/B sert à 3 % des sessions. Et chaque script inventorié porte son hash. Sur Scale, la vue Technologies prend l’empreinte de ce contenu pour nommer la bibliothèque et sa version exacte, confronte cette version aux bases de CVE avec sévérité et plage affectée, et lui attribue un statut de cycle de vie (à jour, obsolète, dormante, dépréciée) : le SBOM côté client que le comité de revue réclamera un mois plus tard. Les scripts inline ne sont pas analysés. Ce workflow est détaillé dans notre article sur la détection des scripts vulnérables par CVE.

La boucle de gouvernance, étape par étape

Un inventaire que personne ne regarde n’est qu’un tableur plus joli. La boucle en fait de la gouvernance.

La vérité terrain, en continu. L’inventaire remplace le questionnaire trimestriel comme registre de ce qui tourne où. Quand quelqu’un demande « est-ce qu’on charge quelque chose depuis ce fournisseur », la réponse est une recherche, pas un sondage.

Vient ensuite l’alerte. Une règle « nouvelle origine de script » par site, c’est la plus bruyante, et sur Scale les pages déclarées comme pages de paiement reçoivent la règle « script non justifié » : le checkout est surveillé de plus près que le blog. Seize types d’événements en tout, sur chaque type de rapport que l’endpoint reçoit. Les alertes partent vers Slack, Microsoft Teams, Google Chat, Telegram, l’e-mail ou des webhooks HTTPS signés en HMAC dont le JSON s’intègre directement dans Splunk, Datadog, PagerDuty, Opsgenie ou Jira : le SOC traite donc les changements de scripts dans la file qu’il utilise déjà. Les délais de refroidissement regroupent au lieu de jeter, chaque tentative de livraison reste dans un historique, et les règles sont une ressource REST, donc l’outillage du SOC peut les créer pour une nouvelle propriété en même temps que le site. Disponible dès l’offre Business à 129,99 €/mois, sans plafond d’alertes. Le câblage est décrit dans notre article sur les alertes CSP vers Slack, Splunk et PagerDuty et la logique de détection dans celui sur les changements de scripts tiers.

Puis l’artefact d’approbation. Sur Scale (349,99 €/mois) et au-delà, là où vit le module PCI DSS, chaque script d’une page de paiement déclarée passe par un workflow de justification : une justification métier ou technique par script, des règles d’auto-validation pour qu’une rotation de hash de routine ne repasse pas en file d’attente, une file pour tout ce qui est nouveau, et une chronologie datée des changements (ajout, modification, retrait, nouvelle origine) conservée jusqu’à la suppression du compte, bien au-delà des 90 jours des rapports bruts. Ce registre est le processus d’approbation : quand l’auditeur demande qui a approuvé un script et pourquoi, la réponse sort d’un champ que quelqu’un a rempli, pas d’une fouille archéologique dans de vieux fils Slack. Sur les pages de paiement, cela répond directement à PCI DSS 6.4.3.

Enfin, l’équipe elle-même doit passer l’audit. Les rôles d’espace de travail et les rôles par site (Viewer, Analyst, Manager, Admin, plus les groupes) existent sur toutes les offres. Le SSO en SAML ou OIDC et le journal d’audit exportable arrivent avec Scale, et tout est stocké et traité chez OVH, en France. Si votre comité de revue s’intéresse à la résidence des données (le cas des banques est traité dans l’article sur la surveillance CSP en environnement bancaire), ce dernier point raccourcit la réunion.

Ce que cette approche ne voit pas

Soyons précis, parce que les fournisseurs de ce marché le sont rarement. La CSP observe les chargements et les connexions. Elle vous dira à l’instant où les octets d’un script changent, où un script apparaît, où une page contacte une origine inédite. Elle ne vous dira pas ce qu’un script autorisé et resté identique fait à l’exécution.

En pratique, la plupart des compromissions de scripts tiers se signalent précisément là où regarde la surveillance d’identité : un fichier modifié, une origine nouvelle, un ajout inattendu. L’attaquant doit changer quelque chose avant que l’attaque n’agisse. Si votre modèle de menace exige vraiment de l’analyse comportementale sur un checkout à haut risque, c’est un outil séparé pour cette page-là, par-dessus l’inventaire, jamais à sa place.

Par où commencer

Une propriété, une CSP en report-only avec les hashes de reporting, un en-tête. Après une journée de trafic réel, la liste contiendra quelque chose que personne dans l’équipe ne se souvient d’avoir approuvé. C’est presque toujours le cas.

Ensuite, le même en-tête part propriété par propriété, jusqu’à couvrir le portefeuille. La page de l’inventaire de scripts donne la syntaxe des en-têtes, et l’essai de 14 jours de l’offre Start couvre trois sites et 250 000 rapports par mois, de quoi inventorier quelques propriétés de bout en bout.