A browser extension is usually a JavaScript bundle built from npm packages, and store review does not guarantee those packages are free of known vulnerabilities. Scan your lockfile on every build, check what is actually inside the final bundle, and gate releases on the result.
Why extensions are exposed
Manifest V3 requires that an extension's code ship in the package, with no remotely hosted logic. That is good, because the code reviewed is the code that runs. It also means a vulnerable library is frozen into your release until you ship a new one. Users receive fixes only when you publish. Mozilla's guidance says third-party libraries should be kept current and unmodified, and that AMO may disable extensions that contain outdated or altered libraries.
What to inventory
- Direct dependencies in package.json.
- Transitive dependencies from the lockfile.
- Vendored files copied into the source tree, which package managers do not track.
- Libraries bundled into the final output by your build tool.
The last two are where surprises hide. A minified file copied in years ago has no version record, so identify it and replace it with a managed dependency.
A release routine
- Commit the lockfile and install from it in CI, so builds match.
- Run a dependency scan on the lockfile for every pull request.
- Inspect the final bundle, not just the source tree. List which packages ended up inside.
- Decide a policy: for example, block the release on known exploited issues in code your extension actually uses, and track the rest with dates.
- Keep a software bill of materials for each release, so when a new advisory appears you can tell in minutes which published versions are affected.
- When a fix lands, publish a new version, and say so in release notes. Use a staged rollout if your user count allows.
Check reachability, not only presence
A vulnerable function in a package is not always called by your code. Reachability analysis tells you whether your extension actually reaches it, which helps order the work. Still, extension code runs next to untrusted pages, so lean toward upgrading when a fix exists.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and reachability analysis, and a free scan is available at gold.safeguard.sh/scan if you want to try it on a manifest or lockfile first. The demo below shows what an inventory view looks like.
Click through it at your own pace, or open it full screen.
Quick check
Does store review catch vulnerable libraries?
Not reliably. Review looks at policy compliance and code, and a known flaw in a bundled library can pass. Scan dependencies yourself.
Why must I ship a new version to fix a library?
Because under Manifest V3 the code is in the package and cannot be changed remotely. A fix reaches users only through an update.
Sources
Last reviewed: 19 October 2026.
