A JavaScript monorepo's packaging security comes down to five areas: one pinned package manager, a committed and frozen lockfile, controlled registries and tokens, limits on what installs and runs, and a publish path with provenance. Work through the 15 items below, and record the result for each in the repository.
1. One toolchain
- Pin the package manager. Use the packageManager field and Corepack so every developer and CI job uses the same version. See Corepack and packageManager.
- One lockfile for the workspace. npm workspaces resolve a single tree from the root, and pnpm workspaces typically share one lockfile. Confirm scanners read it. See what scanners read in a pnpm workspace.
- Delete the old lockfile after a switch. Two lockfiles mean two truths. See deleting the old lockfile.
2. Lockfile discipline
- Commit the lockfile for applications.
- Use the frozen install in CI. npm ci fails when package.json and the lockfile disagree and never writes to either. See frozen flags compared.
- Review lockfile diffs, especially changes without a manifest change. See lockfile poisoning.
3. Registries and tokens
- Scope private packages to your registry in .npmrc or yarnrc so internal names are never requested publicly.
- Scope tokens to a registry host, and keep them in environment variables. See npmrc precedence.
- Keep TLS strict. Never turn off strict SSL to get past a proxy.
4. What installs and runs
- Delay brand new versions. Settings exist in all three managers. See the settings comparison.
- Control git and URL dependencies, with an allowlist or a block.
- Decide the install script policy and write it down, since Yarn skips third party postinstall scripts by default while npm runs them.
5. Publishing
- Mark internal packages private and set publishConfig so they cannot reach the wrong registry. The npm docs say private true makes npm refuse to publish, and publishConfig can override the registry at publish time.
- Check what ships with npm pack and a dry run before publishing. In a workspace, publish with the workspace option, one package or all with the workspaces option.
- Publish with provenance or trusted publishing from a supported cloud runner, with no long-lived token where possible. See provenance from a release tool.
How to use the list
Copy it into an issue, mark each line pass, fail or not applicable, and attach evidence such as a config file path or a CI log line. For failed items, open tickets with owners. Repeat quarterly, and after any package manager upgrade.
What the list does not cover
It does not cover vulnerabilities in the code you already depend on. A clean checklist can sit on top of a tree with known issues, so scanning and monitoring run alongside it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a component is watched after the build, not only at install time.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation cover workspace lockfiles, reachability analysis helps prioritize what matters, and policies and gates enforce rules on pull requests. A free scan is at https://gold.safeguard.sh/scan.
Quick check
How often should I review this checklist?
Quarterly, and after any package manager or CI platform change. Record evidence for each item so a review takes minutes.
Does a perfect checklist mean no vulnerable dependencies?
No. It controls how packages arrive and are published. Known vulnerabilities in your tree need scanning and monitoring as well.
Sources
- package.json documentation
- npm workspaces documentation
- npm publish documentation
- npm ci documentation
- Yarn configuration reference
- npm docs: generating provenance statements
Last reviewed: 19 October 2026.
