Supply Chain
Votre chaîne d'approvisionnement logicielle, vue depuis le navigateur de vos utilisateurs.
Chaque page publique charge du JavaScript qui n'est pas le vôtre : analytics, widgets, CDN, chatbots, briques npm empaquetées dans vos bundles. Le mode de scan Supply Chain crawle vos pages en passif, inventorie ces scripts et dépendances tiers réellement exécutés chez vos visiteurs, remonte de quel paquet ils viennent, puis note le risque : paquet abandonné ou malveillant, dependency-confusion, typosquat npm, SRI manquant, secret oublié dans une source map. En complément, le moteur EASM cartographie les tiers rattachés à vos domaines. Découverte continue, findings classés par risque, alerte au premier changement.
- JS tiers
- les scripts et dépendances réellement chargés chez vos visiteurs
- passif
- crawl Playwright sans payload, compatible production
- 24/7
- surveillance continue, pas un questionnaire annuel
Fonctionnalités
Tout ce qu'il faut pour sécuriser, sans le superflu.
Crawl passif et inventaire des scripts tiers
Un scanner dédié parcourt vos pages publiques avec un vrai navigateur (Playwright) et relève chaque script tiers réellement chargé : tag manager, analytics, widgets, chatbots, CDN, pixels marketing. Pas de payload, pas d'exploitation, juste ce qui s'exécute pour de vrai dans le navigateur de vos visiteurs. C'est la surface d'un supply chain web à la Magecart : un script tiers compromis siphonne des données de formulaire sous votre nom de domaine, sans jamais toucher vos serveurs.
Attribution de provenance des dépendances
Un fichier JS minifié ne dit pas d'où il vient. Le scanner remonte la chaîne : chemins node_modules qui traînent dans le bundle, source maps quand elles sont exposées, en-têtes de licence. De là, il rattache le code chargé aux paquets npm dont il est issu. Vous ne voyez plus « un blob de 400 ko », vous voyez la liste des briques open source qui tournent réellement sur vos pages, et leur version.
Santé et réputation des paquets
Une dépendance chargée en prod peut être abandonnée depuis trois ans, tenir sur un seul mainteneur (bus-factor), ou porter des signaux de paquet malveillant. Le scanner évalue la santé de chaque paquet identifié via les signaux GitHub et OpenSSF : dernier commit, nombre de mainteneurs, indicateurs de compromission connus. Vous repérez la brique fragile avant qu'un mainteneur ne se fasse détourner son compte npm.
Dependency-confusion et typosquat npm
Deux classes d'attaque visent la résolution des paquets : le dependency-confusion, où un attaquant publie un paquet public au nom d'un scope interne pour se faire tirer à sa place, et le typosquatting, où un paquet imite un nom populaire à une lettre près. Le scanner confronte les dépendances chargées à ces schémas et fait remonter le spoofing de scope npm et les noms suspects, avant qu'une mise à jour n'importe le mauvais paquet.
SRI manquant, secrets et URL cloud chargées
Un script tiers servi sans Subresource Integrity peut être remplacé côté CDN sans que le navigateur bronche : le scanner signale les balises sans attribut d'intégrité. Il fouille aussi les source maps exposées à la recherche de secrets oubliés (clés, tokens) et repère les URL S3, Azure ou GCP réellement chargées depuis vos scripts, ainsi que les CNAME orphelins pointant vers un service désabonné (dangling CNAME, porte ouverte à un takeover).
Tiers rattachés à vos domaines, en complément
En parallèle du crawl JS, le moteur EASM cartographie l'exposition réseau des tiers rattachés à vos domaines : filiales, prestataires hébergés sous vos sous-domaines, actifs partagés. C'est de la découverte active (scan de ports, fingerprint de services) qui corrèle les actifs par certificats TLS, DNS et ASN partagés, et remonte les domaines lookalike et typosquattés. À distinguer du crawl passif : ici on regarde l'infrastructure exposée, pas le code chargé dans le navigateur.
Comment ça marche
Du setup à la première alerte.
- 01
Vous saisissez vos domaines
Vos domaines racines en entrée, ceux de vos marques et filiales inclus. Pas d'agent à installer, pas d'accès à vos dépôts ni à vos pipelines de build à connecter. Vous lancez un scan en mode Supply Chain : le moteur EASM et le scanner de dépendances tierces partent en parallèle sur ce périmètre. Vous gardez la main : on n'analyse que ce que vous déclarez.
- 02
On crawle vos pages et on inventorie les scripts chargés
Le scanner dédié parcourt vos pages avec un navigateur Playwright en passif et relève chaque script tiers réellement exécuté. Pour chacun, il tente de remonter la provenance : chemins node_modules laissés dans le bundle, source maps exposées, en-têtes de licence, pour rattacher le code aux paquets npm dont il est issu. En sortie, l'inventaire nominatif des dépendances tierces qui tournent chez vos visiteurs, versions comprises.
- 03
Évaluation du risque de chaque dépendance
Chaque paquet identifié passe au crible : santé et réputation (abandon, bus-factor et signaux GitHub, indicateurs de paquet malveillant OpenSSF), schémas d'attaque npm (dependency-confusion par spoofing de scope, typosquat), Subresource Integrity manquant, secrets oubliés dans les source maps, URL S3 ou Azure chargées depuis les scripts, CNAME orphelins. Les findings remontent dans la catégorie Supply Chain de l'interface, classés par risque. Le moteur EASM, lui, ajoute en parallèle les tiers réseau rattachés à vos domaines (corrélation certificats, DNS, ASN, domaines lookalike).
- 04
Surveillance continue, alerte au premier changement
Vos dépendances tierces changent à chaque déploiement, l'inventaire suit. Les scans tournent en continu et à la demande, et la détection de changement signale tout nouveau script apparu sur une page, toute dépendance dont la version bouge, tout tiers réseau nouvellement rattaché, tout domaine lookalike fraîchement émis. L'alerte tombe le jour même dans Slack, Teams, Jira, GitHub, GitLab, PagerDuty ou un webhook signé HMAC, pas au prochain questionnaire annuel. C'est le suivi continu que l'article 21 de NIS2 attend sur la chaîne d'approvisionnement.
Bénéfices
L'impact concret pour vos équipes.
Sachez quel code tiers tourne vraiment chez vos utilisateurs
Votre CMDB liste vos serveurs, pas les briques npm empaquetées dans vos bundles ni les scripts tiers qu'un tag manager injecte à la volée. Le mode Supply Chain part de vos domaines, crawle vos pages en passif avec un vrai navigateur et relève chaque script réellement exécuté chez vos visiteurs. Puis il remonte la provenance (chemins node_modules, source maps, en-têtes de licence) pour rattacher ce code aux paquets open source dont il est issu. Vous passez d'un « on charge des trucs de Google et d'un CDN » à un inventaire nominatif des dépendances tierces qui tournent sous votre nom de domaine, avec leur version.
Coupez les vecteurs qui visent la chaîne, pas juste les CVE
Le risque supply chain ne se résume pas à une CVE dans une lib. C'est un paquet abandonné qui ne recevra jamais de patch, un mainteneur unique dont le compte npm se fait détourner, un typosquat qui remplace lodash par lodahs, un dependency-confusion qui spoofe le scope de votre entreprise, une source map qui laisse fuiter une clé API, un script tiers sans SRI qu'un CDN compromis peut réécrire. Le scanner évalue ces signaux (santé du paquet via GitHub et OpenSSF, schémas d'attaque npm, secrets exposés, intégrité manquante) et classe les findings par risque réel, pour que vous traitiez d'abord ce qui mène quelque part.
Tenez le volet chaîne d'approvisionnement que NIS2 réclame
L'article 21 de NIS2 nomme explicitement la sécurité de la chaîne d'approvisionnement parmi les mesures de gestion des risques. Un tableur de prestataires ne tient pas face à des dépendances qui changent à chaque déploiement. Ici l'inventaire reste vivant : scripts et paquets tiers chargés, tiers réseau rattachés à vos domaines, scans périodiques ou à la demande, historique par actif, détection des changements. Vous exportez les rapports en PDF et CSV par section pour les remettre à un auditeur ou au comité. Soyons clairs sur le périmètre : on regarde ce qui est chargé et exposé depuis l'extérieur, pas le code source de vos livrables (ça, c'est SecAI). Données hébergées dans l'UE, sous droit européen, conçu par un pentester certifié OSWE.
Aperçu
La plateforme en images.
Pourquoi own2pwn
Ce qu'on fait différemment.
Hébergé dans l'Union européenne
L'inventaire des dépendances et scripts tiers qui tournent sur vos sites est une donnée sensible : il reste sous droit européen, hébergé dans l'UE, conforme RGPD, avec isolation stricte par client au niveau base de données. Confier la cartographie de votre chaîne d'approvisionnement numérique à un éditeur américain, c'est l'exposer à des demandes d'accès extraterritoriales ; le vôtre reste hébergé dans l'UE.
Conçu par un pentester certifié OSWE
La logique suit ce qu'un attaquant vise en premier pour pivoter par la chaîne : le paquet abandonné qu'on peut reprendre, le scope npm laissé libre pour un dependency-confusion, le script tiers chargé sur toutes vos pages sans SRI, la source map qui fuite une clé. La priorisation reflète l'exploitabilité réelle, pas un score recopié d'un framework. C'est une méthode offensive mise en SaaS, pas un dashboard de gestion des risques fournisseurs pensé par des marketeux.
L'IA là où elle aide vraiment
Pas de chatbot. L'IA sert à corréler les actifs de votre écosystème (certificats partagés, DNS, ASN), à dédupliquer et classer les findings par risque réel, et à repérer les rattachements que personne n'a déclarés. En option et quotaée, une validation IA-native tente de confirmer l'exploitabilité d'un finding critique. Elle s'appuie sur les modèles Claude via Vertex AI, sans aucun entraînement sur vos données. C'est de l'IA, pas un humain : la vérification humaine approfondie, c'est nos pentests, une offre séparée.
Crawl passif, pas un SCA de votre code
Soyons nets sur ce que fait cette facette : elle regarde ce qui est chargé et exécuté dans le navigateur de vos visiteurs, depuis l'extérieur, et l'exposition réseau des tiers rattachés à vos domaines. Ce n'est pas une analyse SCA des dépendances dans le code source de vos dépôts (ça, c'est SecAI, notre offre AppSec). Les deux sont complémentaires : ici on voit ce qui tourne réellement en prod, le SCA lit votre arbre de dépendances au build. Le crawl est passif, sans payload, compatible production, aucun agent à installer.
Des tarifs lisibles, sans surprise.
- 1 domaine surveillé, jusqu'à 25 actifs
- 10 scans / mois
- Découverte multi-source + plus de 240 modules de détection
- Corrélation CVE, priorisation KEV et EPSS
- 2 validations IA-native / mois
- Alertes email, 1 utilisateur
- Gratuit, sans limite de durée
- Jusqu'à 5 domaines, 250 actifs suivis
- 100 scans / mois
- 30 validations IA-native / mois
- Webhooks signés HMAC (Slack, Teams, Discord, PagerDuty)
- Intégrations Jira, GitHub, GitLab, Slack
- Exports PDF et CSV, API (5 clés), jusqu'à 5 utilisateurs
- Jusqu'à 15 domaines, 1 000 actifs suivis
- Scans illimités
- 100 validations IA-native / mois
- SSO, RBAC et gestion des rôles
- Connecteur SIEM, intégrations sur mesure
- Support prioritaire
- Domaines, scans, actifs et validations IA illimités
- SSO / SAML, provisioning SCIM
- Validation IA renforcée (raisonnement étendu)
- SLA, DPA conforme RGPD, accompagnement NIS2
- Support dédié
Questions fréquentes
Ce que vous voulez probablement savoir.
Pour aller plus loin
EASM : le guide complet
Définition, fonctionnement étape par étape, et différence avec un scanner ou un pentest.
Lire →EASM et conformité NIS2
Cartographier sa surface d'attaque externe pour répondre à l'article 21 NIS2.
Lire →La découverte d'actifs, en pratique
Énumération de sous-domaines, ASN, ports et actifs cloud pour cartographier votre surface.
Lire →Comparatif des plateformes EASM
La grille de critères pour trancher entre les outils EASM du marché.
Lire →Parlons de votre besoin.
Démo, devis ou question technique : réponse sous 48 h ouvrées.