Skip to content

Bump NPM version and configure it to be more secure against supply chain attacks #1694

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sequba wants to merge 6 commits into
base: develop
Choose a base branch
from
Open

Bump NPM version and configure it to be more secure against supply chain attacks #1694

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
2bbfcfa
Configure NPM to be more secure against supply chain attacks
sequba Jun 15, 2026
d4d3a86
Set default node version to 26
sequba Jun 15, 2026
8b40f6c
Set package.json to require Node 22+
sequba Jun 15, 2026
79245ae
Merge branch 'develop' into feature/improve-npm-security
sequba Jun 15, 2026
84d1325
Remove full-icu package
sequba Jun 15, 2026
06b351a
Remove node and npm requirements from package.json
sequba Jun 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions .npmrc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# --- Security ---
# Run only minimal lifecycle scripts; block arbitrary install scripts from deps
ignore-scripts=true
Comment thread
cursor[bot] marked this conversation as resolved.
# Fail install if a package has a known advisory at/above this level
audit-level=low

@marcin-kordas-hoc marcin-kordas-hoc Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wording nit: audit-level doesn't gate npm install — it sets the exit-code threshold for npm audit. npm install prints an audit summary but won't fail on advisories. The real gate here is the Security workflow running npm run audit (= npm audit --omit=dev), which does respect this threshold. So the setting is effective, just via the audit job rather than installs.

Suggest rewording so it doesn't imply installs are blocked, e.g.:

Suggested change
audit-level=low
# Threshold at/above which `npm audit` (run by the Security CI workflow) fails
audit-level=low

# Always verify package integrity against the lockfile
package-lock=true
# Dependency cooldown: only install versions published more than N days ago
# (requires npm >= 11.10.0; silently ignored on older npm)
min-release-age=30

@marcin-kordas-hoc marcin-kordas-hoc Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

min-release-age requires npm ≥ 11.10.0 (npm/cli#8965); older npm just prints npm warn Unknown project config 'min-release-age' and silently ignores it. Since engines was (rightly) dropped from package.json, nothing now guarantees contributors/CI actually run a new-enough npm — so this cooldown, which is the headline mitigation of this PR, may be a no-op for most installs.

Worth decoupling the two concerns: keeping engines out of the published package is correct (it shouldn't constrain library consumers), but the dev/CI npm version is separate — pinning it via .nvmrc / a packageManager field / a CI check would make min-release-age actually take effect. (The npm-version dependency is a practical inference, not npm-documented.)

@marcin-kordas-hoc marcin-kordas-hoc Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separately, on the value itself: is 30 days heavier than needed? The cooldown analysis behind this feature found 8/10 major npm supply-chain attacks had exploitation windows under a week, so min-release-age=7 would capture ~all the protection with much less friction — relevant if the cooldown applies to npm ci (lockfile installs), since a dependency bump would then block CI until the newly-locked version ages past 30 days. Worth considering 7.


# --- Reproducibility / supply chain ---
# Pin exact versions (no ^ or ~) so installs are deterministic
save-exact=true
# Enforce the Node/npm range declared in package.json "engines"
engine-strict=true

@cursor cursor Bot Jun 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Engine strict without engines

Medium Severity

This commit enables engine-strict=true to enforce Node/npm ranges from package.json, but package.json has no engines field. The node/npm constraints exist only under the root entry in package-lock.json, which npm does not use for engine checks, so installs are not blocked on unsupported runtimes despite the stated hardening.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 06b351a. Configure here.

4 changes: 4 additions & 0 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,10 @@
"last 2 op_mob versions"
],
"license": "GPL-3.0-only",
"engines": {
"node": ">=20",
"npm": ">=10"
},
Comment thread
sequba marked this conversation as resolved.
Outdated
"type": "commonjs",
"module": "es/index.mjs",
"main": "commonjs/index.js",
Expand Down
Loading