Type a package. We check it against live malware advisories, provenance, capability access, freshness, and its whole dependency tree. That's the exact verdict the somewhere CLI gives you, before anything installs.
Checking…Then swpx instead of npx · swpm instead of npm
Every significant npm supply-chain attack since 2018, and the honest answer for each: did a confirmed advisory exist, and how long was the bad version live before it landed?
Ultimately, if no one catches it, we won't catch it. We consolidate the best known info about any package, so there's an easy way to stay safe: just wait. The window between a malicious publish and its advisory is usually minutes to hours (axios: 6 minutes; chalk: ~2 hours), though once in a while it's much longer (event-stream sat undetected for ~2.5 months).
So we close the window a different way: swpx won't trust a version that's less than 24 hours old by default. Almost every attack above was caught inside that window, so wait a day and you're already past it. Need the newest version right away? swpx --fresh (or set the age threshold in your config). Honesty over a green checkmark.
How it behaves, how it works, and what it looks like. Tap to expand.
YES!! They 100% should! All of this is publicly available information. We built it because WE needed it to vet the packages in our own users' builds. somewhere.tech is the backend platform AI agents use to build and ship real apps, and every build pulls in npm packages we had to trust before they ran. We shared the tool with our users, and now we're opening it up to everyone, even without a free somewhere login. Until npm catches up, your installs shouldn't be blind.
Silent. swpx wraps npx, swpm wraps npm. A verified package just runs, and you don't notice anything different.
$ swpx create-next-app my-app ✓ create-next-app@15.2.0 — network, fs, child_process ✓ matches "Create Next.js apps" Creating a new Next.js app in /Users/dev/my-app... [normal npx output continues] $ swpx is-odd ✓ is-odd@1.0.0 — (no system access)
It stops with the evidence. An unverified package is a soft stop you can override; confirmed malware is a hard block.
$ swpx some-analytics-tool ⚠ some-analytics-tool@2.1.0 — could not verify ⚠ No provenance · minified · has a postinstall script ⚠ network, fs, child_process, process.env ⚠ capabilities don't match "lightweight date formatter" Run npx some-analytics-tool to proceed unverified.
$ swpx @ctrl/tinycolor@4.1.1 ✖ BLOCKED — @ctrl/tinycolor@4.1.1 MAL-2025-47141 · credential-stealer (Shai-Hulud) Disclosed 2025-09-15 · OpenSSF / OSV Confirmed malware. Do not install.
swpm install checks the entire resolved tree, direct and transitive, before anything runs. One blocked package stops the install.
$ swpm install Checking 47 packages (12 direct, 35 transitive) ✓ 44 verified ⚠ 2 unverified └ obfuscated-util@1.2.0 — minified, no provenance ✖ 1 blocked └ @ctrl/tinycolor@4.1.1 — MAL-2025-47141 Remove or replace blocked packages to continue.
Same command. One of them warned you. @ctrl/tinycolor@4.1.1 shipped a credential-stealer in September 2025:
$ npm i @ctrl/tinycolor@4.1.1 > @ctrl/tinycolor@4.1.1 postinstall > node bundle.js added 1 package in 0.9s — the stealer already ran.
$ swpm i @ctrl/tinycolor@4.1.1 ✖ BLOCKED — MAL-2025-47141 credential-stealer (Shai-Hulud) Nothing installed. Nothing ran.
Every supply-chain attack arrives as a change to a previously-clean package, so the attack is in the delta. We read that delta: the diff, the changelog, and the package's stated purpose, and ask whether the change fits.
event-stream@3.3.5 → 3.3.6 ⚠ Added dependency flatmap-stream — no changelog entry ⚠ encrypted payload, unrelated to event streaming axios@1.7.0 → 1.14.1 ⚠ Added dependency plain-crypto-js — no changelog entry ⚠ network exfiltration, unrelated to an HTTP client
Every version is reviewed once; the result is instant for everyone who checks it after.
We're not a registry or a mirror, and we never touch your packages. You run swpx/swpm; it resolves the exact version and asks our verdict database one question. Clean? It hands off to real npx/npm, so the bytes come straight from npm's own CDN at the same speed, and we're never in the download path. Flagged? It stops with the evidence. Confirmed malware? It hard-blocks. We track the live malware feeds continuously, so a version flagged an hour ago is blocked now, even if it's since been unpublished. (And pssst, check out our repo, the CLI is open source.)
Yes. Agents run npm constantly and are the most exposed to silent malware. Every check is a structured object an agent can act on, escalating to a human only when something trips:
$ swpx check some-pkg --json { "verdict": "unverified", "signals": { "provenance": false, "readable": false, "install_scripts": ["postinstall"], "capabilities": ["network", "fs", "process.env"] } }
By default swpx falls back to plain npx with a loud warning. We're a gate, not a wall, and our outage shouldn't stop your work. Rather be safe than sorry? swpx --enforce (or SWPX_ENFORCE=1) makes a failed check refuse the install instead of waving it through. Set once, your call.
A set of tools for agents (and people) to ship web apps easily AND safely. swpx / swpm are the package-verdict layer you're looking at; the same CLI gives you a sandboxed browser, a server-side deploy-check oracle, and the rest of the somewhere.tech toolchain. One install: npm i -g somewhere-cli.
No account needed. Free, no login (signing in unlocks higher limits and org policies). The client is open source, so you can read exactly what swpx does: resolve, check, show, hand off. If a verdict's ever wrong, the fallback is plain npx: a false positive costs one keystroke, a false negative is no worse than not using us. And no, we don't store or serve packages; npm serves the bytes from its own CDN, we store verdicts and point at theirs.