Aller au contenu principal
own2pwn

EASM

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.

Commencer gratuitementParler à un pentester
Compte gratuit, hébergé dans l'UE, un domaine suffit
les scripts et dépendances réellement chargés chez vos visiteurs
JS tiers
crawl Playwright sans payload, compatible production
passif
surveillance continue, pas un questionnaire annuel
24/7

Fonctionnalités

Ce que couvre la surveillance de votre chaîne d'approvisionnement.

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.

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.

Tarifs de la sécurité de chaîne d'approvisionnement.

Découverte

0 €

  • Module Supply Chain inclus dans l'offre EASM
  • En clair : le périmètre d'un seul nom de domaine, 25 actifs exposés au maximum.
  • 10 scans / mois
  • Découverte multi-source + plus de 240 modules de détection
  • Corrélation CVE et priorisation par exploitabilité réelle
  • 2 validations IA-native / mois
  • Alertes email, 1 utilisateur
  • Gratuit, sans limite de durée et sans carte bancaire
Commencer gratuitement
Recommandé

Pro

99 € / mois

  • En clair : 5 noms de domaine, 250 actifs exposés suivis, 5 personnes dans le compte.
  • 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)
S'abonner

Réservé aux professionnels, identifiant d'entreprise demandé à l'étape suivante.

Business

299 € / mois

  • En clair : 15 noms de domaine, 1 000 actifs exposés suivis, scans sans plafond.
  • 100 validations IA-native / mois
  • SSO, RBAC et gestion des rôles
  • Connecteur SIEM, intégrations sur mesure
  • Support par email, traitement prioritaire
S'abonner

Réservé aux professionnels, identifiant d'entreprise demandé à l'étape suivante.

Enterprise

Sur devis

  • En clair : le périmètre que vous cadrez au contrat, sans plafond de domaines ni de validations.
  • SSO / SAML, provisioning SCIM
  • Validation IA renforcée (raisonnement étendu)
  • DPA conforme RGPD, contrat-cadre et accompagnement NIS2
  • Interlocuteur unique : le pentester qui opère
Parler à un pentester

TVA non applicable, art. 293 B du CGI

Comment ça marche

Du setup à la première alerte.

  1. 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.

  2. 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.

  3. 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).

  4. 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

Ce que voir vos dépendances tierces change pour vous.

01

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.

02

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.

03

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.

Findings filtrés sur la catégorie Supply chain : dépendances vulnérables ou en fin de vie avec CVE, santé du dépôt, CI/CD à risqueLes findings filtrés sur la supply chain : bibliothèques JS tierces vulnérables ou en fin de vie avec leur CVE, santé du dépôt, CI/CD à risque. La dépendance oubliée remonte comme le reste.
Graphe de la surface d'attaque reliant les actifs, utile pour visualiser l'exposition des tiers rattachésLe graphe relie les actifs entre eux. Pratique pour voir comment un tiers rattaché s'accroche à votre surface.
Inventaire des actifs, y compris ceux rattachés aux tiers et filialesL'inventaire des actifs, filiales et tiers compris. Ce que votre CMDB n'a pas.

Pourquoi own2pwn

Pourquoi on regarde le fournisseur et pas seulement le paquet.

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.

Questions fréquentes

Vos questions sur la sécurité de la chaîne d'approvisionnement.

En quoi c'est différent d'un SCA (Software Composition Analysis) ?

Un SCA lit l'arbre de dépendances de votre code source, au build, à partir de vos package.json et lockfiles : il voit ce que vous avez déclaré. Cette facette part de l'autre bout : ce qui est réellement chargé et exécuté dans le navigateur de vos visiteurs, vu de l'extérieur, sans accès à vos dépôts. Le crawl passif remonte les scripts tiers effectifs et leur provenance (chemins node_modules, source maps, en-têtes de licence). Les deux sont complémentaires et l'analyse SCA de votre code, c'est SecAI, notre offre AppSec. Ici, on voit ce qui tourne en prod ; le SCA lit ce qui est censé y tourner.

Comment vous savez de quel paquet npm vient un script minifié ?

Par attribution de provenance. Un bundle laisse souvent des traces : chemins node_modules dans les commentaires ou le code, source maps exposées qui reconstituent l'arborescence d'origine, en-têtes de licence collés en tête de fichier. Le scanner exploite ces indices pour rattacher le code chargé aux paquets open source dont il est issu, avec leur version quand elle est identifiable. Ce n'est pas magique : sur un bundle parfaitement dépouillé de toute source map et de tout chemin, l'attribution est partielle. Mais en pratique, une bonne part des scripts tiers laisse assez de traces pour être nommés.

C'est quoi la dependency-confusion et le typosquat npm, et comment vous les repérez ?

Le dependency-confusion exploite la résolution des paquets : si votre entreprise utilise un scope interne (par exemple @acme/utils) et qu'un attaquant publie un paquet public au même nom, un build mal configuré peut tirer le paquet malveillant à la place du vôtre. Le typosquat, lui, mise sur la faute de frappe : un paquet nommé à une lettre près d'une lib populaire, en espérant un npm install distrait. Le scanner confronte les dépendances qu'il a identifiées à ces schémas et fait remonter les spoofings de scope et les noms suspects, pour que vous verrouilliez la résolution avant qu'un mauvais paquet n'entre.

Vous détectez les secrets exposés et le SRI manquant ?

Oui. Le scanner fouille les source maps exposées (elles reconstituent le code d'origine, y compris les constantes) à la recherche de secrets oubliés : clés d'API, tokens, identifiants. Il signale aussi les scripts tiers servis sans attribut d'intégrité (Subresource Integrity) : sans SRI, un script hébergé sur un CDN tiers peut être remplacé sans que le navigateur détecte le changement, ce qui en fait un point d'entrée direct pour un supply chain web. Vous ajoutez le SRI, vous purgez les secrets, et vous fermez deux portes très classiques.

Vous scannez les buckets S3 ou Azure de mes fournisseurs ?

Non, et la nuance compte. Ce scanner ne va pas énumérer des buckets bruts : il détecte les URL S3, Azure Blob ou GCP Storage réellement chargées depuis vos scripts, celles qui servent un asset exécuté sur vos pages. C'est l'angle "ce que le navigateur va chercher", pas "quels buckets existent quelque part". La chasse aux buckets ouverts et aux ACL de stockage relève du scan EASM classique, sur la facette de découverte d'actifs. Ici, on suit la chaîne telle qu'elle se charge côté visiteur.

Le crawl est-il intrusif pour ma prod ou mes fournisseurs ?

Non, il est passif par conception. Le scanner charge vos pages avec un vrai navigateur (Playwright) et observe ce qui s'exécute : aucun payload, aucune exploitation, aucune tentative d'écriture. C'est de la reconnaissance côté client, comparable à une visite de vos pages par un utilisateur, en plus instrumenté. Vous pouvez le lancer sur de la production sans coordonner une fenêtre de maintenance. La validation IA-native, elle, est du test actif réservé aux findings critiques d'un domaine vérifié et reste quotaée : distincte du crawl supply chain.

Et les tiers rattachés à mes domaines, filiales et prestataires ?

C'est le complément apporté par le moteur EASM, qui tourne en parallèle du crawl JS. Là où le crawl regarde le code chargé dans le navigateur, le moteur cartographie l'exposition réseau : filiales, prestataires hébergés sous vos sous-domaines, actifs partagés. Il corrèle ces actifs par certificats TLS, DNS et ASN communs pour révéler les rattachements réels, et remonte les domaines lookalike et typosquattés qui ciblent vos clients. C'est de la découverte active (scan de ports, fingerprint), à distinguer du crawl passif : deux angles sur la même chaîne d'approvisionnement.

En quoi ça aide ma conformité NIS2 ?

L'article 21 de NIS2 cite explicitement la sécurité de la chaîne d'approvisionnement parmi les mesures de gestion des risques attendues. Cette facette adresse le volet technique et externe : inventaire vivant des scripts et dépendances tiers chargés sur vos sites, signaux de risque par paquet (abandon, malveillance, dependency-confusion, typosquat, SRI, secrets), tiers réseau rattachés à vos domaines, alerte au premier changement, rapports PDF et CSV pour vos auditeurs. Soyons clairs : elle ne couvre pas tout le volet supply chain de NIS2 (contrats, gouvernance des tiers, clauses de sécurité restent à votre charge), ni l'audit du code de vos livrables (ça, c'est SecAI). Elle adresse la partie connaître et surveiller ce que votre chaîne charge et expose.

Y a-t-il un engagement de durée, et comment je résilie ?

Aucune durée minimale d'engagement. L'abonnement est mensuel ou annuel (l'annuel revient à dix mois payés), reconduit tacitement à chaque échéance, et vous le résiliez à tout moment, sans justification à fournir : soit vous le faites vous-même depuis votre espace de facturation, soit vous écrivez à contact@own2pwn.fr et la réponse tombe sous 24 heures. Pas de préavis à respecter : la résiliation prend effet à la fin de la période de facturation en cours, et vous gardez l'accès jusque-là. En contrepartie, cette période n'est pas remboursée au prorata. Ce n'est pas une promesse commerciale, c'est l'article 7 des conditions générales de vente.

Faut-il une carte bancaire pour le plan gratuit ?

Non. Le plan Découverte s'ouvre depuis le formulaire d'inscription, sans moyen de paiement : aucune carte à saisir, aucun compteur qui se déclenche au bout de quatorze jours. Ce n'est pas une période d'essai mais un plan gratuit sans limite de durée, avec ses quotas propres (1 domaine, 25 actifs suivis, 10 scans par mois). Le module Supply Chain y est compris, pas vendu à part. La carte bancaire n'apparaît que si vous passez sur un plan payant, et le paiement se fait sur own2pwn.fr, par carte uniquement.

Combien de temps entre le paiement et l'accès effectif ?

L'accès est ouvert immédiatement après la validation du paiement. Concrètement : dès que le règlement est confirmé, l'abonnement est rattaché à votre compte et les quotas du plan s'appliquent, sans intervention manuelle. Si vous souscrivez sans avoir encore de compte own2pwn, le paiement en crée un et vous recevez un email pour définir votre mot de passe : l'accès est effectif dès que c'est fait. Si quelque chose coince, écrivez à contact@own2pwn.fr, la réponse tombe sous 24 heures.

Je peux changer de plan en cours d'abonnement ?

Oui, et sans repartir de zéro : le compte, les domaines déclarés et l'historique de scans restent en place, seuls les quotas changent. Les modules ne se facturent jamais séparément : Supply Chain est compris dans l'abonnement EASM, donc un changement de plan déplace les quotas de tous les modules d'un coup. Le changement se demande par un email à contact@own2pwn.fr, en indiquant le plan visé et la date d'effet souhaitée ; la réponse tombe sous 24 heures. Ce qui est acquis côté facturation, c'est que la période déjà réglée n'est pas remboursée au prorata (article 7 des conditions générales de vente) ; le montant exact et la date d'effet du nouveau plan vous sont confirmés par écrit avant toute validation.

Comment vous évaluez la santé d'une dépendance chargée en production ?

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.

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 →

Cartographier vos dépendances tierces ?

On remonte les briques tierces exposées depuis votre domaine. Pour cadrer le périmètre, la réponse arrive sous 24 h.

Réserver une démoNous écrire