v1.3.0: Known malware and swapped tarballs always caught

@v1 points to this release, so existing workflows get it automatically. No changes needed.

Stricter

• Known malware always blocks. A package version with a malicious-package advisory (an OSV MAL- record, or a GitHub advisory for embedded malicious code) now fails the check in mode: block whatever fail-on-severity says. These advisories are often rated only HIGH, so fail-on-severity: critical used to let a release like ua-parser-js 0.7.29 through. Malware is labelled ☠️ in the table, the advisory list and the line annotation. Only mode: warn stops it blocking.
• Swapped tarballs are caught. A lockfile entry whose tarball is a different package or version than it declares (e.g. left-pad@1.3.0 pointing at minimist-0.0.8.tgz) now counts as a source change, and the comment names the real tarball. Before, a newly added entry like this only showed up as a vulnerability of the declared package. It's controlled by fail-on-source-change, like other source changes.

Fewer false alarms

• A dependency's prepare script no longer counts as a new install script. npm never runs a dependency's prepare when installing it from the registry, so a bump like husky 6 → 7 is no longer blocked for it. This changed on the npmscan.com side and already applies to every version of the action. Your own root prepare script is still flagged, because it does run on npm install in your repository.

Tested on

Two new tests replay real npmscan.com API responses for a malware release and a swapped tarball, alongside the existing npm, pnpm, Yarn classic/Berry, monorepo, fork-PR and outage tests (119 assertions).

📖 Full docs: https://npmscan.com/docs/github-action

Updated branding

Updated branding.

v1.2.0: Fewer false alarms on upgrades, security policy and OpenSSF Scorecard

@v1 points to this release, so existing workflows get it automatically. No changes needed.

Fixes

• Ordinary upgrades are no longer flagged as source changes. Every version bump in a lockfile was reported as a "source / integrity" change, which blocked routine Dependabot and Renovate PRs. Now this check only fires when the same version points to a different tarball or hash, or an upgrade suddenly downloads from a different server. This was fixed on the npmscan.com side and already applies to every version of the action.
• Advisory summaries in the PR comment can no longer turn into stray formatting or links.
• When a package has more than 5 advisories, the comment now says "…and N more" instead of looking complete.

Trust and transparency

• Security policy with private vulnerability reporting and response times: see SECURITY.md.
• OpenSSF Scorecard runs weekly. Every action this repo uses is pinned to a commit SHA.
• MIT license, contributing guide, and issue forms, including one for reporting false positives and false negatives.
• The README now explains exactly what leaves your runner and how to pin the action to a commit SHA.

Tested on

npm, pnpm, Yarn classic and Yarn Berry lockfiles, plus monorepos, new lockfiles, fork PRs and API outages. Every PR to this repo also runs the action against the live npmscan.com API.

📖 Full docs: https://npmscan.com/docs/github-action

v1.1.0: Severity thresholds, warn mode, monorepos and inline annotations

Catch risky npm dependency changes before they merge, now with control over what blocks.

@v1 points to this release, so existing workflows get it automatically. No changes needed.

New

• mode: warn: report findings without failing the check. Try npmscan for a week, then switch to mode: block.
• fail-on-severity: choose the lowest vulnerability severity that blocks (low, moderate, high, critical, or none).
• fail-on-install-script and fail-on-source-change: turn each check on or off.
• fail-on-error (default false): if npmscan.com is unreachable, the step warns instead of failing, so an outage never blocks your merges.
• files: scan several lockfiles in one step. All results go into one PR comment, which is useful for monorepos.
• Inline annotations: each finding is marked on its line in package.json, package-lock.json, yarn.lock or pnpm-lock.yaml.
• New outputs: blocking-count and error-count.

Better reports

• New dependencies that have install scripts are now shown in the table. Before, they were counted but hidden.
• Changes to your own root preinstall/install/postinstall/prepare scripts and to overrides/resolutions get their own tables.
• A collapsible list of advisories shows the fixed version for each one.
• A warning appears when results are partial.

Fixes

• npmscan only edits its own PR comment. Before, it could overwrite another bot's comment.
• Several npmscan steps in one workflow each keep their own comment.
• A lockfile added in the PR is compared against an empty lockfile of the same type.
• Package names and script contents from the PR are escaped in the comment.
• Clearer messages when the comment can't be posted, for example on Dependabot PRs without pull-requests: write, or on PRs from forks.

Worth knowing

Initial release

npmscan Dependency Check v1.0.0

First release. Scans the package.json or lockfile changes in a pull request with npmscan.com and reports risky packages before they're merged.

What it flags

• Known vulnerabilities in added or upgraded packages, with severity
• Newly introduced install scripts (preinstall / install / postinstall)
• Changed package source or integrity hash, such as a lockfile entry pointing at a different tarball with the same version

What you get on the PR

• A comment with a table of flagged packages, each linking to its npmscan.com page, updated in place on every push
• The same report in the workflow's job summary
• A failing check when anything is flagged (turn this off with fail-on-flagged: false)

Supported files

package.json, package-lock.json, yarn.lock (classic and Berry), pnpm-lock.yaml

Quick start

name: npmscan
on:
  pull_request:
    paths: [package.json, package-lock.json, yarn.lock, pnpm-lock.yaml]
permissions:
  contents: read
  pull-requests: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: npmscan/npmscan-action@v1

Known limitations

• PRs from forks get a read-only token, so the PR comment is skipped; the report still appears in the job summary.
• No API key needed. Requests share npmscan.com's public rate limit.