Often not. When a UI library compiles a dependency into its dist files, the published package.json may no longer list it, and a manifest based scanner has nothing to match. The code is still in your users' browsers. Cover the gap with a bundle inventory or an SBOM generated at build time.
Two ways a library can include a dependency
A regular dependency stays a separate package. The consuming app installs it, the lockfile records it, and scanners see it by name and version.
A bundled dependency is copied into the library's output by a build tool. The published manifest may list nothing for it. The npm documentation also describes a separate bundleDependencies field, which packs named packages into the tarball when publishing. Either way, the versions are fixed inside the artifact rather than chosen by the app's installer.
Why this matters for security
If a bundled package gets an advisory, nothing in the app's lockfile will show it. Updating the app's dependencies changes nothing, because the vulnerable code travels inside your library release. The only fix is a new release of the library.
| Approach | Visible in app lockfile | Who can patch it |
|---|---|---|
| Regular dependency | Yes | The app, by updating its lockfile |
| Peer dependency | Yes, from the app's own choice | The app |
| Bundled into dist | No | The library owner, with a new release |
Bundling has real benefits, such as smaller install trees and fewer version conflicts. The trade is that you take on the patching duty for those packages.
How to cover the gap
- Produce an inventory at build time. Generate an SBOM from the library's build, including what the bundler pulled in, and publish or store it with each release.
- Keep a list of bundled packages in the library repo, with an owner. Treat it like a runtime dependency list.
- Scan the library repo's lockfile, since bundled packages came from somewhere. The repo lockfile is where the versions are known.
- Rebuild on advisories. When a bundled package is flagged, bump it, rebuild, publish a patch release, and tell app teams.
- Prefer externalizing risky packages. For a parsing or sanitizing package, let apps install it so they can patch it themselves.
For general guidance on inventory sources, see where scanners get component lists: five inventory sources and why your SBOM is missing components.
A quick test
Pick one bundled package and search your published dist files for its name or a known string from it. Then check what your scanner reports for a consuming app. If the scan is silent while the code is present, you have confirmed the gap, and you know which of the steps above to apply.
Try it yourself
Click through it at your own pace, or open it full screen. Compare which components appear in an inventory with what you would expect to ship.
Safeguard generates SBOMs and scans dependencies from lockfiles and manifests, which covers what your repository declares. A free scan is at gold.safeguard.sh/scan.
Quick check
Does bundling make a library safer?
Not by itself. It hides versions from the app's lockfile, so patching depends on the library owner.
Should an app team ask for the library's SBOM?
Yes. It is the quickest way to learn what is compiled into the package.
Sources
Last reviewed: 19 October 2026.
