Many inventories do not. Teams list server packages and forget the JavaScript libraries that ship to every shopper's browser: theme libraries, bundled front-end packages and widget code. OWASP says to inventory both client-side and server-side components, nested dependencies included.
Why the browser side gets missed
Server components live in a package manifest that tooling reads. Front-end libraries often arrive in other ways: copied into a theme folder, bundled into one minified file, or added by an app from an extension. Nothing in the server manifest mentions them.
The OWASP Top 10 entry for Vulnerable and Outdated Components says you are likely vulnerable if you do not know the versions of all components you use, both client side and server side, including nested dependencies. It lists retire.js among tools for continuously inventorying versions, and its references name Retire.js for detecting known vulnerable JavaScript libraries.
The OWASP third-party JavaScript cheat sheet also notes that keeping JavaScript libraries updated matters because earlier versions can have known vulnerabilities that typically make a site vulnerable to cross-site scripting.
Where client-side components hide in a store
| Source | Example | How to find it |
|---|---|---|
| Package manifest | Front-end framework, UI kit | Lockfile and SBOM |
| Bundled output | Libraries merged into one minified file | Source maps or build report |
| Theme folder | Slider, zoom or carousel libraries copied in | Search the theme for library names and headers |
| Platform apps | Code the app injects into pages | Page capture with developer tools |
| Tag manager | Libraries loaded by custom tags | Tag manager audit |
| CDN links | Libraries loaded from a public host | Search templates for external script URLs |
Steps to build the list
- Start from the build. Generate an SBOM from each front-end project and keep it with the release.
- Search the theme. Look in theme folders for files with a library name or a version in a header comment.
- Capture the live page. Load key pages, including checkout, and list every script file and its origin.
- Identify versions. For each file, find the version from the header comment, the package name or the source map. Mark unknowns.
- Record ownership. Each entry needs a person who can update or retire it.
- Compare after changes. Repeat after each release and each app install.
Unknown versions are findings on their own. If nobody can say which version a file is, nobody can say whether a fix applies.
Keep the list useful
An inventory that is a one-time spreadsheet goes stale in a month. OWASP advises continuous inventory, and monitoring of sources such as CVE and the National Vulnerability Database. Tie the list to your build so it updates itself where possible, and review the manual parts on a schedule.
Prune as you go. OWASP's first prevention step is to remove unused dependencies, unnecessary features, components, files and documentation. A slider library nobody uses is still a library with an advisory waiting to happen.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and nested components appear in the same list.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists the packages in your front-end projects alongside server code, with reachability analysis to help rank what matters. Files copied into a theme or injected by an app are not packages, so use the manual steps for those. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a lockfile a complete inventory of what shoppers load?
No. It covers what your build installs. Copied files, app-injected code and tag manager libraries need separate discovery.
What if we cannot find a library's version?
Record it as unknown, assign an owner and replace the file with a known version from an official source.
Sources
- OWASP Top 10:2021 A06 Vulnerable and Outdated Components
- OWASP Third Party JavaScript Management Cheat Sheet
Last reviewed: 19 October 2026.
