By default a pnpm workspace has one pnpm-lock.yaml at the workspace root, not one per package. Point your scanner at the root lockfile to cover every member. If the team turned the shared lockfile off, each project has its own and each needs scanning.
What pnpm documents
The pnpm docs describe a setting called sharedWorkspaceLockfile. When it is enabled, pnpm creates a single pnpm-lock.yaml in the root of the workspace. A related page says that setting it to false gives each project its own lockfile. The docs also note that every dependency becomes a singleton with the shared file, and that each package can use only dependencies declared in its own package.json.
That last point matters for scanning. A shared lockfile records the whole workspace, but your question is usually about one package. Do not read one big result as one big blast radius.
Two layouts, two scan plans
| Layout | Lockfiles | Scan plan |
|---|---|---|
| Shared lockfile (default) | One at the root | Scan the root once, then map results to packages |
| Per-project lockfiles | One per project | Scan each project folder |
To find out which layout you have, look for pnpm-lock.yaml files.
git ls-files '*pnpm-lock.yaml'
One result at the root means a shared lockfile. Many results mean per-project lockfiles, or a mix left over from a migration.
Mapping results back to packages
A shared lockfile lists importers, which are the workspace projects and their direct dependencies. A good scan result tells you which package pulled in the vulnerable version. If your tool reports only a flat list, you still have a way to answer the question: read the package.json in each member and check the direct dependency, then follow the chain.
The workspace colon protocol deserves a mention. The docs say pnpm will refuse to resolve to anything other than a local workspace package when you use it. Internal packages referenced this way are your own code, not registry downloads, so they should not appear as vulnerable third party components.
Pitfalls
- Stale lockfile. If a package.json changed and nobody ran install, the lockfile no longer matches. Run a frozen install in CI so drift fails the build.
- Two sources of workspace truth. pnpm reads pnpm-workspace.yaml and ignores the workspaces field in package.json if they diverge, so check the right file.
- Scanning only changed packages. A change to the shared lockfile can touch many packages at once. See scan only affected packages for how to handle it.
Try it yourself
Open the demo and look at how components in the inventory trace back to the files that declare them. That is the same mapping you want from a workspace scan.
Click through it at your own pace, or open it full screen.
Safeguard scans dependencies from lockfiles and manifests and produces SBOMs per project. Try the free scan at https://gold.safeguard.sh/scan on one workspace package.
Quick check
Can a pnpm workspace have more than one lockfile?
Yes, if the shared lockfile setting is turned off. Then each project has its own file.
Do I scan every package folder when there is a shared lockfile?
Usually the root lockfile covers the workspace. Scan the root and map findings to packages instead.
Sources
Last reviewed: 19 October 2026.
