Often not. Backend inventories rarely cover mobile apps or front end bundles, yet both ship third party libraries directly to users. Add each surface as its own product, inventory it from the built app or bundle, and note which package managers feed it.
Why these get missed
Teams that own the API often have no connection to the team that owns the mobile app or marketing site. Different repositories, different package managers, different release cycles. The seller's summary says "we scan our code" and means the backend.
The GitHub dependency graph documentation says it summarises manifest and lock files in a repository, so a repository that holds the app's manifests would appear, but only if someone connected it.
Surfaces to add
| Surface | Typical dependencies | Where to inventory from |
|---|---|---|
| Web front end | npm packages, bundled and minified | Lockfile plus the production bundle |
| Android app | Gradle libraries, native libraries | Build output and lock data |
| iOS app | Swift packages, CocoaPods or Carthage items | Resolved package files and built app |
| Embedded web views | Libraries loaded by URL | Page source, script tags |
| Browser extensions | Packaged libraries | The extension package |
The CDN script gap
Pages sometimes load libraries from a content delivery URL instead of a package. These never appear in any lockfile. Search page templates for script tags that load external URLs and record each with its version and whether integrity attributes are used.
Steps
- List every app and site the company publishes, including in app stores.
- Locate the repository for each.
- Generate an inventory from the lockfile and from the built package.
- Search templates for externally loaded scripts.
- Add each to the data room index and the coverage list.
Why it matters
These libraries run on user devices, outside the company's control once released. Old app versions stay installed. That mirrors the shipped software case: each release needs its own record.
Gaps to expect
- No lockfile in a front end repository.
- Native libraries with no version recorded.
- Old app releases still supported but never inventoried.
- Third party SDKs for analytics and payments, which are suppliers as well as dependencies.
Remediation
Generate an inventory on each app build, keep it with the release, and add the app repositories to scheduled scans.
Safeguard has surfaces for developers, such as the CLI and editor plugins, and its SBOM and dependency scanning covers common package ecosystems. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Do SDKs count as dependencies?
Yes. Record them as components, and note the supplier since they may also be a vendor under contract.
Sources
Last reviewed: 19 October 2026.
