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.
- third-party JS
- the scripts and dependencies actually loaded in your visitors' browsers
- passive
- Playwright crawl, no payload, production-safe
- 24/7
- continuous monitoring, not a yearly questionnaire
Fonctionnalités
Tout ce qu'il faut pour sécuriser, sans le superflu.
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.
Package health and reputation
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.
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.
Missing SRI, secrets and loaded cloud URLs
A third-party script served without Subresource Integrity can be swapped on the CDN side without the browser flinching: the scanner flags tags with no integrity attribute. It also digs through exposed source maps for forgotten secrets (keys, tokens) and spots the S3, Azure or GCP URLs actually loaded from your scripts, as well as orphaned CNAMEs pointing to a cancelled service (dangling CNAME, an open door to a takeover).
Third parties tied to your domains, as a complement
Alongside the JS crawl, the EASM engine maps the network exposure of the third parties tied to your domains: subsidiaries, vendors hosted under your subdomains, shared assets. This is active discovery (port scanning, service fingerprinting) that correlates assets through shared TLS certificates, DNS and ASN, and surfaces lookalike and typosquatted domains. Distinct from the passive crawl: here we look at exposed infrastructure, not the code loaded in the browser.
Comment ça marche
Du setup à la première alerte.
- 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.
- 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.
- 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).
- 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.
Bénéfices
L'impact concret pour vos équipes.
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.
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.
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.
Aperçu
La plateforme en images.
Pourquoi own2pwn
Ce qu'on fait différemment.
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.
Des tarifs lisibles, sans surprise.
- 1 monitored domain, up to 25 assets
- 10 scans / mo
- Multi-source discovery + more than 240 detection modules
- CVE correlation, KEV and EPSS prioritisation
- 2 AI-native validations / mo
- Email alerts, 1 user
- Free, no time limit
- Up to 5 domains, 250 tracked assets
- 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), up to 5 users
- VAT not applicable (art. 293 B of the French tax code)
- Up to 15 domains, 1,000 tracked assets
- Unlimited scans
- 100 AI-native validations / mo
- SSO, RBAC and role management
- SIEM connector, custom integrations
- Email support, prioritised handling
- VAT not applicable (art. 293 B of the French tax code)
- Unlimited domains, scans, assets and AI 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
Questions fréquentes
Ce que vous voulez probablement savoir.
How is this different from an SCA (Software Composition Analysis)?
How do you know which npm package a minified script came from?
What are dependency confusion and npm typosquats, and how do you spot them?
Do you detect exposed secrets and missing SRI?
Do you scan my vendors' S3 or Azure buckets?
Is the crawl intrusive for my production or my vendors?
What about the third parties tied to my domains, subsidiaries and vendors?
How does this help my NIS2 compliance?
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 →Parlons de votre besoin.
Démo, devis ou question technique : réponse sous 48 h ouvrées.