Skip to main content
own2pwn

EASM

Supply Chain

Your software supply chain, seen from your users' browsers.

Every public page loads JavaScript that isn't yours: analytics, widgets, CDNs, chatbots, npm bricks bundled into your builds. The Supply Chain scan mode crawls your pages passively, inventories those third-party scripts and dependencies actually running in your visitors' browsers, works out which package they came from, then scores the risk: abandoned or malicious package, dependency confusion, npm typosquat, missing SRI, a secret left in a source map. As a complement, the EASM engine maps the third parties tied to your domains. Continuous discovery, findings ranked by risk, an alert on the first change.

Start for freeTalk to a pentester
Free account, hosted in the EU, one domain is enough
the scripts and dependencies actually loaded in your visitors' browsers
third-party JS
Playwright crawl, no payload, production-safe
passive
continuous monitoring, not a yearly questionnaire
24/7

Features

What supply chain monitoring covers.

Passive crawl and third-party script inventory

A dedicated scanner walks your public pages with a real browser (Playwright) and records every third-party script actually loaded: tag managers, analytics, widgets, chatbots, CDNs, marketing pixels. No payload, no exploitation, just what really runs in your visitors' browsers. This is the surface of a Magecart-style web supply chain attack: one compromised third-party script siphons form data under your domain name, without ever touching your servers.

Provenance attribution of dependencies

A minified JS file won't tell you where it came from. The scanner works back up the chain: node_modules paths left in the bundle, source maps when they are exposed, license headers. From there it ties the loaded code to the npm packages it originates from. You no longer see a 400 kB blob, you see the list of open-source bricks actually running on your pages, and their versions.

Dependency confusion and npm typosquats

Two attack classes target package resolution: dependency confusion, where an attacker publishes a public package under an internal scope name to get pulled in your place, and typosquatting, where a package mimics a popular name by one letter. The scanner checks the loaded dependencies against these patterns and surfaces npm scope spoofing and suspicious names, before an update pulls in the wrong package.

Supply chain security pricing.

Discovery

€0

  • Supply Chain module included in the EASM offering
  • In plain terms: the perimeter of a single domain name, 25 exposed assets at most.
  • 10 scans / mo
  • Multi-source discovery + more than 240 detection modules
  • CVE correlation and prioritisation by real exploitability
  • 2 AI-native validations / mo
  • Email alerts, 1 user
  • Free, no time limit and no credit card
Start for free
Recommended

Pro

€99 / mo

  • In plain terms: 5 domain names, 250 tracked exposed assets, 5 people on the account.
  • 100 scans / mo
  • 30 AI-native validations / mo
  • HMAC-signed webhooks (Slack, Teams, Discord, PagerDuty)
  • Jira, GitHub, GitLab, Slack integrations
  • PDF and CSV exports, API access (5 keys)
Subscribe

For businesses only, a company identifier is asked at the next step.

Business

€299 / mo

  • In plain terms: 15 domain names, 1,000 tracked exposed assets, no cap on scans.
  • 100 AI-native validations / mo
  • SSO, RBAC and role management
  • SIEM connector, custom integrations
  • Email support, prioritised handling
Subscribe

For businesses only, a company identifier is asked at the next step.

Enterprise

On request

  • In plain terms: the perimeter you set in the contract, no cap on domains or validations.
  • SSO / SAML, SCIM provisioning
  • Enhanced AI validation (extended reasoning)
  • GDPR-compliant DPA, master agreement and NIS2 guidance
  • A single point of contact: the pentester who runs it
Talk to a pentester

VAT not applicable (art. 293 B of the French tax code)

How it works

From setup to the first alert.

  1. 01

    You enter your domains

    Your root domains in, brands and subsidiaries included. No agent to install, no access to your repos or build pipelines to connect. You launch a scan in Supply Chain mode: the EASM engine and the third-party dependency scanner both start on that scope. You stay in control: we only analyse what you declare.

  2. 02

    We crawl your pages and inventory the loaded scripts

    The dedicated scanner walks your pages with a passive Playwright browser and records every third-party script actually running. For each one, it tries to work back the provenance: node_modules paths left in the bundle, exposed source maps, license headers, to tie the code to the npm packages it came from. The output is a named inventory of the third-party dependencies running in your visitors' browsers, versions included.

  3. 03

    Risk evaluation of each dependency

    Every identified package is put through the wringer: health and reputation (abandonment, bus-factor and GitHub signals, OpenSSF malicious-package indicators), npm attack patterns (dependency confusion via scope spoofing, typosquat), missing Subresource Integrity, secrets left in source maps, S3 or Azure URLs loaded from the scripts, orphaned CNAMEs. Findings surface in the Supply Chain category of the interface, ranked by risk. The EASM engine, meanwhile, adds the network third parties tied to your domains in parallel (certificate, DNS, ASN correlation, lookalike domains).

  4. 04

    Continuous monitoring, an alert on the first change

    Your third-party dependencies change on every deploy, the inventory follows. Scans run continuously and on demand, and change detection flags every new script that appears on a page, every dependency whose version moves, every newly tied network third party, every freshly issued lookalike domain. The alert lands the same day in Slack, Teams, Jira, GitHub, GitLab, PagerDuty or an HMAC-signed webhook, not at the next yearly questionnaire. This is the continuous monitoring Article 21 of NIS2 expects on the supply chain.

Benefits

What seeing your third-party dependencies changes for you.

01

Know what third-party code actually runs for your users

Your CMDB lists your servers, not the npm bricks bundled into your builds nor the third-party scripts a tag manager injects on the fly. The Supply Chain mode starts from your domains, crawls your pages passively with a real browser and records every script actually running in your visitors' browsers. Then it works back the provenance (node_modules paths, source maps, license headers) to tie that code to the open-source packages it came from. You move from "we load some Google stuff and a CDN" to a named inventory of the third-party dependencies running under your domain name, with their versions.

02

Cut the vectors that target the chain, not just CVEs

Supply chain risk isn't just a CVE in a lib. It's an abandoned package that will never get patched, a lone maintainer whose npm account gets hijacked, a typosquat that swaps lodash for lodahs, a dependency confusion that spoofs your company's scope, a source map leaking an API key, a third-party script with no SRI that a compromised CDN can rewrite. The scanner evaluates these signals (package health via GitHub and OpenSSF, npm attack patterns, exposed secrets, missing integrity) and ranks findings by real risk, so you handle what actually leads somewhere first.

03

Keep the supply chain evidence NIS2 asks for

Article 21 of NIS2 explicitly names supply chain security among the risk-management measures. A vendor spreadsheet can't keep up with dependencies that change on every deploy. Here the inventory stays alive: third-party scripts and packages loaded, network third parties tied to your domains, periodic or on-demand scans, history per asset, change detection. You export reports as PDF and CSV by section to hand to an auditor or the board. Let's be clear on scope: we look at what is loaded and exposed from the outside, not the source code of your deliverables (that is SecAI). Data hosted in the EU, under European law, designed by an OSWE-certified pentester.

Overview

The platform in pictures.

Findings filtered on the Supply chain category: vulnerable or end-of-life dependencies with CVE, repository health, risky CI/CDFindings filtered on the supply chain: vulnerable or end-of-life third-party JS libraries with their CVE, repository health, risky CI/CD. The forgotten dependency surfaces like the rest.
Attack surface graph linking assets, useful to visualise the exposure of tied third partiesThe graph links assets together. Handy to see how a tied third party hooks into your surface.
Asset inventory, including those tied to third parties and subsidiariesThe asset inventory, subsidiaries and third parties included. What your CMDB doesn't have.

Why own2pwn

Why we look at the vendor, not only the package.

Hosted in the European Union

The inventory of the dependencies and third-party scripts running on your sites is sensitive data: it stays under European law, hosted in the EU, GDPR compliant, with strict per-customer isolation at the database level. Handing the map of your digital supply chain to a US vendor exposes it to extraterritorial access requests; yours stays hosted in the EU.

Designed by an OSWE-certified pentester

The logic follows what an attacker targets first to pivot through the chain: the abandoned package you can take over, the free npm scope left open for a dependency confusion, the third-party script loaded on all your pages with no SRI, the source map leaking a key. Prioritisation reflects real exploitability, not a score copied from a framework. It is an offensive method turned into SaaS, not a vendor-risk dashboard dreamed up by marketers.

AI where it actually helps

No chatbot. AI is used to correlate your ecosystem's assets (shared certificates, DNS, ASN), to dedup and rank findings by real risk, and to surface the ties nobody declared. Optional and quota-limited, an AI-native validation tries to confirm the exploitability of a critical finding. It relies on Claude models via Vertex AI, with no training on your data. It is AI, not a human: thorough human verification is our pentests, a separate offering.

Passive crawl, not an SCA of your code

Let's be clear about what this facet does: it looks at what is loaded and executed in your visitors' browsers, from the outside, and at the network exposure of the third parties tied to your domains. It is not an SCA of the dependencies inside the source code of your repos (that is SecAI, our AppSec offering). The two are complementary: here we see what actually runs in production, SCA reads your dependency tree at build time. The crawl is passive, no payload, production-safe, no agent to install.

Frequently asked questions

Your questions about supply chain security.

How is this different from an SCA (Software Composition Analysis)?

An SCA reads your source code's dependency tree, at build time, from your package.json and lockfiles: it sees what you declared. This facet starts from the other end: what is actually loaded and executed in your visitors' browsers, seen from the outside, with no access to your repos. The passive crawl surfaces the effective third-party scripts and their provenance (node_modules paths, source maps, license headers). The two are complementary, and the SCA of your code is SecAI, our AppSec offering. Here we see what runs in production; SCA reads what is supposed to run.

How do you know which npm package a minified script came from?

Through provenance attribution. A bundle often leaves traces: node_modules paths in comments or code, exposed source maps that reconstruct the original tree, license headers pasted at the top of a file. The scanner uses these clues to tie the loaded code to the open-source packages it came from, with their version when identifiable. It's not magic: on a bundle perfectly stripped of every source map and path, attribution is partial. But in practice a good share of third-party scripts leaves enough traces to be named.

What are dependency confusion and npm typosquats, and how do you spot them?

Dependency confusion exploits package resolution: if your company uses an internal scope (say @acme/utils) and an attacker publishes a public package under the same name, a misconfigured build can pull the malicious package instead of yours. Typosquatting bets on the typo: a package named one letter off a popular lib, hoping for a careless npm install. The scanner checks the dependencies it has identified against these patterns and surfaces scope spoofing and suspicious names, so you lock down resolution before a bad package gets in.

Do you detect exposed secrets and missing SRI?

Yes. The scanner digs through exposed source maps (they reconstruct the original code, including constants) for forgotten secrets: API keys, tokens, credentials. It also flags third-party scripts served without an integrity attribute (Subresource Integrity): without SRI, a script hosted on a third-party CDN can be swapped without the browser detecting the change, which makes it a direct entry point for a web supply chain attack. You add the SRI, you purge the secrets, and you close two very classic doors.

Do you scan my vendors' S3 or Azure buckets?

No, and the nuance matters. This scanner won't enumerate raw buckets: it detects the S3, Azure Blob or GCP Storage URLs actually loaded from your scripts, the ones serving an asset executed on your pages. It's the "what the browser goes and fetches" angle, not "which buckets exist somewhere". Hunting for open buckets and storage ACLs is the job of the classic EASM scan, on the asset discovery facet. Here we follow the chain as it loads on the visitor's side.

Is the crawl intrusive for my production or my vendors?

No, it is passive by design. The scanner loads your pages with a real browser (Playwright) and observes what runs: no payload, no exploitation, no write attempt. It is client-side reconnaissance, comparable to a user visiting your pages, just more instrumented. You can run it against production without coordinating a maintenance window. AI-native validation, on the other hand, is active testing reserved for critical findings on a verified domain and stays quota-limited: distinct from the supply chain crawl.

What about the third parties tied to my domains, subsidiaries and vendors?

That is the complement brought by the EASM engine, which runs alongside the JS crawl. Where the crawl looks at the code loaded in the browser, the engine maps network exposure: subsidiaries, vendors hosted under your subdomains, shared assets. It correlates these assets through shared TLS certificates, DNS and ASN to reveal the real ties, and surfaces the lookalike and typosquatted domains aimed at your customers. This is active discovery (port scanning, fingerprinting), distinct from the passive crawl: two angles on the same supply chain.

How does this help my NIS2 compliance?

Article 21 of NIS2 explicitly names supply chain security among the expected risk-management measures. This facet addresses the technical, external part: a live inventory of the third-party scripts and dependencies loaded on your sites, per-package risk signals (abandonment, maliciousness, dependency confusion, typosquat, SRI, secrets), the network third parties tied to your domains, an alert on the first change, PDF and CSV reports for your auditors. To be clear: it doesn't cover the whole supply chain part of NIS2 (contracts, third-party governance, security clauses remain on you), nor the audit of your deliverables' code (that is SecAI). It addresses the knowing and monitoring what your chain loads and exposes part.

Is there a minimum term, and how do I cancel?

No minimum term. The subscription is monthly or annual (annual works out at ten months paid), renewed tacitly at each due date, and you cancel it at any time, with no justification to give: either you do it yourself from your billing area, or you write to contact@own2pwn.fr and the answer comes within 24 hours. No notice period to serve: cancellation takes effect at the end of the current billing period, and you keep access until then. In return, that period is not refunded pro rata. That is not a sales promise, it is article 7 of the terms of sale.

Do I need a credit card for the free plan?

No. The Discovery plan opens from the sign-up form, with no payment method: no card to enter, no counter starting after fourteen days. It is not a trial but a free plan with no time limit and its own quotas (1 domain, 25 tracked assets, 10 scans per month). The Supply Chain module is included in it, not sold separately. A card only comes into play if you move to a paid plan, and payment happens on own2pwn.fr, by card only.

How long between payment and actual access?

Access opens immediately after the payment is validated. In practice: as soon as the payment is confirmed, the subscription is attached to your account and the plan quotas apply, with no manual step in between. If you subscribe without an own2pwn account yet, the payment creates one and you get an email to set your password: access is live as soon as that is done. If anything gets stuck, write to contact@own2pwn.fr, the answer comes within 24 hours.

Can I change plan mid-subscription?

Yes, and without starting over: the account, the domains you declared and the scan history stay in place, only the quotas change. Modules are never billed separately: Supply Chain comes with the EASM subscription, so changing plan moves the quotas of every module at once. You request the change by email to contact@own2pwn.fr, stating the plan you want and the date it should take effect; the answer comes within 24 hours. What is settled on the billing side is that the period already paid for is not refunded pro rata (article 7 of the terms of sale); the exact amount and the effective date of the new plan are confirmed to you in writing before anything is validated.

How do you assess the health of a dependency loaded in production?

A dependency loaded in production may have been abandoned three years ago, rest on a single maintainer (bus-factor), or carry malicious-package signals. The scanner evaluates the health of every identified package through GitHub and OpenSSF signals: last commit, number of maintainers, known compromise indicators. You spot the fragile brick before a maintainer gets their npm account hijacked.

Go further

EASM and NIS2 compliance

Mapping your external attack surface to meet NIS2 Article 21.

Read →

Finding exposed shadow IT

Tracking down the exposed assets nobody manages.

Read →

Recon via Certificate Transparency

Tying unknown assets to your perimeter through shared certificates.

Read →

Asset discovery in practice

Subdomain enumeration, ASN, ports and cloud assets to map your surface.

Read →

Want your third-party dependencies mapped?

We surface the third-party building blocks exposed from your domain. To scope it, a reply lands within 24 hours.

Book a demoWrite to us