[salemalem]

Summary

• add a pull request workflow that runs NPMscan/npmscan-action on yarn.lock changes
• keep the check low-friction with mode: warn and fail-on-error: false
• pin the action to an immutable commit SHA

Why

This adds a lightweight supply-chain check for PRs so new install scripts, tarball swaps, and lockfile overrides get surfaced during review without blocking contributors.

Test plan

• workflow file added under .github/workflows/npmscan.yml
• action pinned to de14168f65640a4ed1f0e82ad3ad8c80483d360d
• workflow scoped to relevant manifest and lockfile changes

[neSpecc]

Why do we need it?

[salemalem]

Fair question, and a disclosure I should have made up front: I'm the creator of npmscan.com and maintain this action.

Why it can be useful: when a PR touches yarn.lock, it diffs the lockfile against the base branch and flags supply-chain changes that vulnerability audits don't cover:

• a dependency that gains an install script (preinstall/install/postinstall), the usual sign of a hijacked package
• a lockfile entry whose tarball URL or integrity hash changes while the version stays the same
• new or changed resolutions
• known malware and vulnerabilities on the newly added versions

It's set to mode: warn and fail-on-error: false, so it only adds a comment and annotations and never blocks a merge. It needs no secrets. The only data it sends is the lockfile (from the base branch and from the PR) to the npmscan.com API.

That said, it's an extra tool to trust and maintain. If you don't see the need, I completely understand. Feel free to close this.

[neSpecc]

Thanks for the answer. I don't think we need it at the moment

[salemalem]

no probs