NPMScan

Quality 63 / 100needs work

23 tools, about 13,479 tokens to load them all · tool set 01418053599b · tools last changed 2026-10-14 · checked 2026-10-20 12:13 UTC

Tool changes

• 2026-10-14diff_dependencieschangeddescription
  before

  Compare two snapshots of a package.json, package-lock.json (v1-v3), yarn.lock (classic or Berry) or pnpm-lock.yaml (e.g. before/after a PR; formats can differ) and report added, removed and changed packages. Lockfiles cover the full resolved graph, so transitive-only changes are caught; npm aliases are followed (`actualName`). Up to 100 added/changed packages are checked in detail. Ideal for a CI gate. Per added/changed package: - `installScriptIntroduced`: a preinstall/install/postinstall script the old version lacked — the shape of a compromised-maintainer release. `prepare` never runs on a registry install, so it is excluded; `installScriptKeysIntroduced` lists every new key, prepare included. - `sourceIntegrityChanged`: the same version now resolves to a different tarball URL or hash, or a bump moved to another host (ordinary bumps are not flagged). A same-version swap is `changeType: "source-swap"`. - `identityMismatch`: the tarball is a different package or version than declared; `tarballName`/`tarballVersion` say what really installs, and the vulnerability fields describe that. - `vulnerabilityDelta` (introduced/fixed/still-vulnerable/still-clean) plus the findings, each with isMalware. Project-level (package.json only): `projectLifecycleChanges` diffs the project's own root install scripts (a PR that only adds a root postinstall changes no dependency), and `overridesChanges` diffs overrides/resolutions/pnpm.overrides (removing one can let a vulnerable version back in). Both count toward `flaggedCount`. Read `comparisonNote` when the two snapshots differ in format. Install-script checks are presence-only; use analyze_install_script to see what a script does.

  after · 98% of words in common

  Compare two snapshots of a package.json, package-lock.json (v1-v3), yarn.lock (classic or Berry) or pnpm-lock.yaml (e.g. before/after a PR; formats can differ) and report added, removed and changed packages. Lockfiles cover the full resolved graph, so transitive-only changes are caught; npm aliases are followed (`actualName`). Up to 100 added/changed packages are checked in detail. Ideal for a CI gate. Per added/changed package: - `installScriptIntroduced`: a preinstall/install/postinstall script the old version lacked — the shape of a compromised-maintainer release. `prepare` never runs on a registry install, so it is excluded; `installScriptKeysIntroduced` lists every new key, prepare included. - `sourceIntegrityChanged`: the same version now resolves to a different tarball URL or hash, or a bump moved to another host (ordinary bumps are not flagged). A same-version swap is `changeType: "source-swap"`. - `identityMismatch`: the tarball is a different package or version than declared; `tarballName`/`tarballVersion` say what really installs, and the vulnerability fields describe that. - `vulnerabilityDelta` (introduced/fixed/still-vulnerable/still-clean) plus the findings, each with isMalware. Project-level: `projectLifecycleChanges` diffs the project's own root install scripts (package.json only; a PR that only adds a root postinstall changes no dependency), and `overridesChanges` diffs overrides/resolutions/pnpm.overrides, from package.json or between two pnpm-lock.yaml files (removing one can let a vulnerable version back in). Both count toward `flaggedCount`. Read `comparisonNote` when the two snapshots differ in format. Install-script checks are presence-only; use analyze_install_script to see what a script does.

• 2026-10-10simulate_dependency_upgradechangedoutput schema
• 2026-10-10get_latest_advisorieschangedoutput schema
• 2026-10-08get_latest_advisorieschangedoutput schema
• 2026-10-08search_packageschangedoutput schema
• 2026-10-06audit_github_repositorychangeddescription, output schemameaning changed
  before

  Given a GitHub repository URL, fetches its package.json (and, if present, a pnpm-lock.yaml/package-lock.json/yarn.lock — first one found wins, in that priority order) straight from the repo's default branch and runs the same vulnerability, license-compliance, install-script, and ownership-risk pipelines batch_query_vulnerabilities/check_license_compliance/analyze_install_script/check_maintainer_changes/check_package_provenance expose individually, in one call — no copy-pasting file contents required. A monorepo (package.json#workspaces, Yarn's {packages:[...]} form, or pnpm-workspace.yaml) is detected automatically: pnpm-lock.yaml and yarn.lock already record every workspace member's dependencies directly, and for package.json-only or package-lock.json repos this additionally lists the repo's file tree, resolves the declared glob patterns to member directories, and merges each member's dependencies into the audit (capped at 50 member packages) — see isMonorepo/workspacePatterns/workspacePackageCount/workspaceNote in the result. Every lockfile entry (up to 3,000; the repo's own workspace/link entries are skipped) is checked against OSV.dev, so vulnerablePackageCount covers the whole dependency set — read `coverage` before calling a repo clean. Up to 100 packages, vulnerable ones first, additionally get the detailed checks: a license-compliance verdict against the given policy (same default as check_license_compliance: only copyleft/network-copyleft/proprietary are violations unless you pass one), and a tarball-free install-script risk signal (installScriptScanScope: 'lifecycle-scripts-only'). Up to 10 of the packages that actually declare a lifecycle script — prioritized by already-vulnerable, then possible-typosquat, then whatever's left — additionally get the full tarball-fetching deep scan analyze_install_script itself runs (installScriptScanScope: 'deep-tarball-scan', with a populated installScriptFindings array); any remaining flagged packages past that cap keep the lighter signal only, noted in deepScanNote. Any package that comes back vulnerable at high/critical severity, a possible typosquat, or deprecated (ownershipRiskEligible) additionally gets check_maintainer_changes and check_package_provenance run against it — up to 5 such packages per call (ownershipRiskChecked), prioritized the same way as the deep install-script scan, populating maintainerRiskTier/maintainerFindings and provenanceRiskTier/provenanceFindings; remaining eligible packages past that cap are named in ownershipCheckNote. This is the most expensive tool in the suite (a repo lookup, a handful of file fetches, up to 100 registry doc fetches, one OSV batch call, up to 10 tarball fetches, up to 5 packages each getting a maintainer-history check plus a provenance check — the latter alone can fan out to ~8 more registry fetches on its own — and, for a monorepo needing enumeration, one file-tree listing plus up to 50 more manifest fetches) — don't call it in a loop across many repos. `peerDependencies` (root and, for a monorepo, each workspace member's own manifest) are excluded from the audit by default, same as batch_query_vulnerabilities — pass `includePeerDependencies: true` to also check them; see `warnings` for which peers were excluded.

  after · 43% of words in common

  Audit a GitHub repository's npm dependencies from its URL — no pasted files needed. Fetches package.json plus the first lockfile found (pnpm-lock.yaml, then package-lock.json, then yarn.lock) from the default branch (or `ref`), and detects monorepos (package.json workspaces, pnpm-workspace.yaml), merging member dependencies (up to 50 members). What it checks: - Every lockfile entry (up to 3,000; the repo's own workspace/link entries skipped) against OSV.dev, so `vulnerablePackageCount` covers the whole dependency set. - Up to 100 packages, vulnerable ones first, also get a license verdict (same default policy as check_license_compliance, or pass `policy`) and an install-script signal; up to 10 with lifecycle scripts get the deep tarball scan (`installScriptScanScope`). - Up to 5 high-risk packages (critical/high vulnerability, possible typosquat, deprecated) get the maintainer-change and provenance checks; others are named in `ownershipCheckNote`. Read `coverage` and the summary before calling a repo clean: a summary starting `PARTIAL AUDIT` (`coverage.complete: false`) means not every package got every check. `findings` has full detail only for packages with something to report; the other detailed packages are listed compactly in `cleanFindings`. Vulnerable packages past the 100-package detail cap are in `overflowVulnerablePackages`. peerDependencies are skipped unless `includePeerDependencies: true`. This is the most expensive tool here — do not call it in a loop across many repos.

• 2026-10-06compare_packageschangeddescriptionmeaning changed
  before

  Given 2-5 candidate packages for the same job (e.g. "axios vs got vs node-fetch"), fetches the same registry/popularity/maintenance/vulnerability enrichment get_package computes for each one in parallel and returns a structured side-by-side plus a deterministic, reasoned pick. Each candidate gets downloads + trend, popularityTier/maintenanceTier, GitHub stars, TypeScript support, license, deprecated status, latest-version vulnerability status, a lightweight installScriptRisk signal (scans lifecycle script command strings for known red flags — does NOT fetch the tarball; call analyze_install_script on a specific candidate for that deeper scan), and installSize (the candidate's own dist.unpackedSize plus a transitive rollup — summed dist.unpackedSize across its resolved dependency tree, walked up to depth 2 / 60 nodes per candidate; `installSize.transitive.truncated`/`sizeUnknownCount` flag when that sum is partial rather than pretending it's exact — call analyze_transitive_dependencies on a specific candidate for the full graph). `differentiators` names which candidates stand out on each dimension (most downloads, only ones with TS types, which are deprecated/vulnerable/flagged as a typosquat/install-script risk, smallest/largest install size). `recommendation.pick` is chosen deterministically from a weighted score (popularity, maintenance, deprecation, vulnerabilities, typosquat flag, install-script risk, TS support, GitHub stars — install size is reported but not scored) — never a deprecated or typosquat-flagged candidate — with `rationale` explaining why and `confidence` reflecting how close the top two scored. If a candidate's OSV.dev vulnerability check itself failed (network/timeout/upstream outage), `isLatestVersionVulnerable` comes back `false` only because the field has to be a boolean — `vulnerabilityCheckFailed:true` is the real signal there, and means that candidate's safe/not-safe answer is unknown, not confirmed clean. A name that can't be resolved (typo, unpublished, malformed) still appears in `candidates` with `found:false` and `resolutionError` set rather than failing the whole call; duplicate names in the input are rejected. More than 5 names is rejected with an error, never truncated: to compare more, split them into separate calls (or shortlist first) rather than dropping names to fit.

  after · 48% of words in common

  Compare 2-5 candidate packages for the same job (e.g. "axios vs got vs node-fetch") side by side and get a deterministic pick. More than 5 names is rejected, never truncated; duplicate names are rejected. Use search_packages first if you have no shortlist. Per candidate: downloads and trend, popularity/maintenance tiers, GitHub stars, TypeScript support, license, deprecation, latest-version vulnerabilities, a tarball-free installScriptRisk (scores preinstall/install/postinstall; a prepare-only package scores 0 since prepare never runs on install — use analyze_install_script for the deep scan), and installSize (own size plus a transitive rollup up to depth 2 / 60 nodes; `truncated`/`sizeUnknownCount` mark a partial sum). `differentiators` names who stands out on each dimension. `recommendation.pick` comes from a weighted score (popularity, maintenance, deprecation, vulnerabilities, typosquat flag, install-script risk, TypeScript, stars; size is reported, not scored) — never a deprecated or typosquat-flagged candidate — with a `rationale` and a `confidence` from how close the top two scored. Before trusting the result: `vulnerabilityCheckFailed: true` means the safe/not-safe answer is unknown, not clean; a name that cannot be resolved stays in `candidates` with `found: false` and `resolutionError`.

• 2026-10-06simulate_dependency_upgradechangeddescription, input schemameaning changed
  before

  Given a package and a current/target version, tells you whether that specific upgrade is a safe patch/minor bump or a likely-breaking major bump, before you actually run npm install. Natural follow-up to prioritize_remediation: pass its `packageName` + `currentVersion` + `fixedVersion` straight in to check whether the suggested fix is a drop-in patch or something that needs a review pass. Classifies the jump by semver (major/minor/patch/prerelease), treats a minor bump between two pre-1.0 (0.x) versions as breaking-risk per semver's own "the API isn't stable yet" convention, and flags skipping over multiple major versions in one jump (e.g. 2.x -> 5.x) as needing a per-major changelog review rather than just a diff against the final target. Beyond semver, it also checks the registry for real signals the version number alone won't tell you: whether the target version is marked deprecated, whether it introduces a preinstall/install/postinstall script the current version didn't have (`installScriptKeysIntroduced` also lists a new `prepare`, which never runs on a registry install and so doesn't raise the tier), whether it tightens its engines.node requirement, and whether it is itself a prerelease. Finally it batch-checks both versions against OSV.dev and reports vulnerabilityDelta (introduced/fixed/still-vulnerable/still-clean) — catching the case where a suggested "fix" version doesn't actually clear every open CVE. Combines all of this into one riskTier (safe/low-risk/review-recommended/breaking-change-likely/unknown/do-not-upgrade) with a reasons list explaining exactly which signals drove it. `do-not-upgrade` means the target is known malware, or was pulled from npm while OSV still carries advisories for it (the target is still checked against OSV when the registry no longer lists it). This does NOT read the package's changelog/release notes or scan the target tarball's source diff for actual breaking API usage — it's a fast, deterministic pre-check, not a substitute for reading the release notes on a flagged major bump. For simulating more than one upgrade at once — e.g. every "patch-now" finding prioritize_remediation just ranked — pass `packages: [{packageName, currentVersion, targetVersion?}, ...]` (1-100 items) instead of `packageName`/`currentVersion`/`targetVersion`, not both. Registry fetches are deduped/parallelized and all OSV checks for the whole batch run as one call, so this is not the same cost as N single-item calls. A package that can't be resolved at all (typo, unpublished, registry error) shows up as its own `results` entry with `fetchError` set instead of failing the whole batch.

  after · 46% of words in common

  Before running npm install, check whether upgrading a package from a current to a target version is safe. Pass `packageName` + `currentVersion` + `targetVersion` (omit target for "latest"), or `packages: [...]` (1-100) to check many in one call; a name that cannot be resolved comes back with `fetchError` instead of failing the batch. A natural follow-up to prioritize_remediation: pass its packageName/currentVersion/fixedVersion straight in. What it checks: - semver jump (major/minor/patch/prerelease; a 0.x minor bump counts as breaking; skipped majors are flagged) - registry signals on the target: deprecated, a newly added preinstall/install/postinstall script (`installScriptIntroduced`; a new `prepare` is listed in `installScriptKeysIntroduced` but never runs on a registry install), a tightened engines.node, prerelease - OSV for both versions: `vulnerabilityDelta` (introduced/fixed/still-vulnerable/still-clean) and `targetVulnerabilities` with isMalware — catching a "fix" that does not clear every CVE Result: one `riskTier` — safe / low-risk / review-recommended / breaking-change-likely / unknown / do-not-upgrade — with `reasons`. `do-not-upgrade` means the target is known malware, or npm no longer lists it while OSV still has advisories for it (how npm removes malicious releases). It does not read changelogs or diff source; it is a fast pre-check, not a substitute for release notes on a major bump.

• 2026-10-06prioritize_remediationchangeddescriptionmeaning changed
  before

  Given a batch of vulnerability findings already flagged elsewhere (e.g. from batch_query_vulnerabilities, analyze_transitive_dependencies, or query_vulnerabilities across a whole package.json/lockfile audit), ranks them by what to actually fix first. Combines CISA KEV status (confirmed active exploitation in the wild — an automatic top-priority override), FIRST.org EPSS (probability of exploitation in the next 30 days — the primary ranking signal, since it measures likelihood rather than just impact), and severity (a secondary/fallback signal, most useful for a GHSA finding with no CVE alias) into one composite score and a remove-now/patch-now/patch-soon/scheduled/monitor tier per finding. A finding with `findingType: "malware"` (or an advisoryId that is a malware advisory — a MAL-* id, or a GHSA whose OSV record carries CWE-506 / a MAL-* alias, looked up automatically) always lands in `remove-now` — the tier above patch-now — regardless of score: a confirmed-malicious package needs removal/replacement, not an "urgent patch" (there often isn't a fixed version to patch TO), and EPSS/severity don't meaningfully apply to "how malicious" the way they do to a genuine vulnerability. When EPSS data isn't available at all (no CVE id, or a real CVE that just isn't in FIRST.org's database) severity becomes the sole usable signal and is scored on its own scale instead of being diluted to a ~10% sliver of the composite — a bare CRITICAL/HIGH GHSA finding with no CVE alias lands in patch-soon/scheduled, not monitor, the way it would if severity kept its normal secondary weight with nothing else to combine it with. An EPSS of 10% or more always ranks at least patch-soon. Pass in the severity/CVE id/advisoryId findings other tools already returned; it adds KEV/EPSS enrichment (the same data get_cve returns per-CVE) plus the per-advisory malware lookup, and ranks the batch (malwareCheckFailedAdvisoryIds lists any advisory whose malware status is unknown). A CVE id shared by multiple findings in the same call is only looked up once. The tier is a fix-ORDER ranking across a backlog, not a severity verdict or a merge/admission gate: a CRITICAL CVE with low EPSS and no KEV listing can legitimately land in `monitor` (minimist's CVE-2021-44906 has ranked there). Do not report a `monitor`/`scheduled` finding as "low severity", and when deciding whether a change that INTRODUCES a vulnerability is acceptable, judge it on severity, not on this tier.

  after · 41% of words in common

  Rank vulnerability findings other tools already returned (batch_query_vulnerabilities, query_vulnerabilities, analyze_transitive_dependencies, diff_dependencies...) by what to fix first. Pass up to 200 `{packageName, cveId?, severity?, advisoryId?, currentVersion?, fixedVersion?, findingType?}`. Each gets a tier: remove-now / patch-now / patch-soon / scheduled / monitor. How the tier is decided: - remove-now: confirmed malware — `findingType: "malware"`, a MAL-* advisoryId, or an advisoryId whose OSV record is a malware advisory (CWE-506 or a MAL-* alias, looked up automatically). Malware is removed, not patched. Advisories that could not be looked up are listed in `malwareCheckFailedAdvisoryIds`. - patch-now: on the CISA KEV list (actively exploited), whatever the severity. - otherwise a score led by FIRST.org EPSS (30-day exploitation probability), with severity as a secondary signal — or the only signal when there is no EPSS data (no CVE id). An EPSS of 10% or more always ranks at least patch-soon. The tier is a fix-ORDER across a backlog, not a severity verdict or a merge gate: a CRITICAL CVE with low EPSS can rank monitor. Never describe a monitor/scheduled finding as "low severity", and judge whether a change that INTRODUCES a vulnerability is acceptable by its severity, not this tier.

• 2026-10-06diff_dependencieschangeddescriptionmeaning changed
  before

  Compares two raw snapshots of a package.json, package-lock.json (npm v1-v3), yarn.lock (classic v1 or Berry), or pnpm-lock.yaml — e.g. before/after a PR — and reports which packages were added, removed, or version-bumped. An npm alias (e.g. `"totally-safe": "npm:[email protected]"`) is followed to its real target in every format — `actualName` names the real package that vulnerability/install-script data attaches to (`name` stays the declared/alias key); this is NOT silently skipped, since doing so would let a vulnerable package hide behind whatever name a project calls it. For every added or bumped package (up to 100 per call), also checks whether its resolved version carries a preinstall/install/postinstall script that the before-version did NOT have (`installScriptIntroduced`, a headline signal — a routine-looking patch bump quietly adding a postinstall is exactly the shape of a compromised-maintainer supply-chain attack; `prepare` is excluded since it never runs on a registry install) and batch-checks it against OSV.dev, reporting `vulnerabilityDelta` (introduced/fixed/still-vulnerable/still-clean) rather than just a bare isVulnerable flag. `installScriptKeysIntroduced` lists every newly-added lifecycle key, prepare included (null when only npm-lock's boolean hint was available, not the real scripts object). `sourceIntegrityChanged` catches a DIFFERENT attack shape than a version bump: a lockfile entry whose resolved tarball URL or integrity hash changed while the version string stayed IDENTICAL — e.g. a compromised registry mirror or a hand-edited lockfile pointing a legitimate-looking "[email protected]" at a different, unverified artifact — which a version-only diff would report as "no change" — or a version bump whose tarball moved to a different host (a routine bump changing URL+hash is not flagged) (`resolvedUrl`/`integrity` are null when a format doesn't record either, package.json has neither). A same-version swap is `changeType: "source-swap"`; when the tarball URL is a different package/version than declared, `identityMismatch` is true and the vulnerability fields describe the real tarball (`tarballName`/`tarballVersion`). Scope notes: package.json is diffed as its own declared dependency list only (a manifest has no transitive data at all, and this includes `peerDependencies`, unlike batch_query_vulnerabilities/generate_sbom which exclude them by default — a diff should catch a peerDependency change just like any other); every lockfile format (package-lock.json, pnpm-lock.yaml, yarn.lock) reports its FULL resolved graph — direct and transitive alike — so a transitive-only change (e.g. a nested `qs` bumped while the direct `express` version is untouched) is caught, not just direct dependency changes; check `comparisonNote` when the two snapshots are different formats/scopes. The install-script check is presence-only (read from the registry packument or lockfile metadata, not a tarball content scan) — use analyze_install_script for a deep-dive on anything flagged here. `projectLifecycleChanges` diffs the SCANNED PROJECT's own root preinstall/install/postinstall/prepare scripts (package.json only — null when neither snapshot is one) — independent of the dependency list above, since a PR that only adds a root postinstall (`"postinstall": "curl ... | sh"`) changes nothing about added/removed/changed and would otherwise be invisible to this tool entirely; `introduced`/`changed` on a preinstall/install/postinstall key is counted in `flaggedCount`. `overridesChanges` similarly diffs package.json's `overrides` (npm), `resolutions` (yarn), or `pnpm.overrides` — these force a specific version onto a transitive dependency (often to pin past a known vulnerability), so a PR that quietly removes, downgrades, or introduces one is exactly the kind of change a dependency diff should catch, and previously nothing here read this field at all; ANY change here (introduced/removed/changed) is counted in `flaggedCount`, since an override can

  after · 37% of words in common

  Compare two snapshots of a package.json, package-lock.json (v1-v3), yarn.lock (classic or Berry) or pnpm-lock.yaml (e.g. before/after a PR; formats can differ) and report added, removed and changed packages. Lockfiles cover the full resolved graph, so transitive-only changes are caught; npm aliases are followed (`actualName`). Up to 100 added/changed packages are checked in detail. Ideal for a CI gate. Per added/changed package: - `installScriptIntroduced`: a preinstall/install/postinstall script the old version lacked — the shape of a compromised-maintainer release. `prepare` never runs on a registry install, so it is excluded; `installScriptKeysIntroduced` lists every new key, prepare included. - `sourceIntegrityChanged`: the same version now resolves to a different tarball URL or hash, or a bump moved to another host (ordinary bumps are not flagged). A same-version swap is `changeType: "source-swap"`. - `identityMismatch`: the tarball is a different package or version than declared; `tarballName`/`tarballVersion` say what really installs, and the vulnerability fields describe that. - `vulnerabilityDelta` (introduced/fixed/still-vulnerable/still-clean) plus the findings, each with isMalware. Project-level (package.json only): `projectLifecycleChanges` diffs the project's own root install scripts (a PR that only adds a root postinstall changes no dependency), and `overridesChanges` diffs overrides/resolutions/pnpm.overrides (removing one can let a vulnerable version back in). Both count toward `flaggedCount`. Read `comparisonNote` when the two snapshots differ in format. Install-script checks are presence-only; use analyze_install_script to see what a script does.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.