An SBOM for a desktop or mobile app should describe the artifact you ship, not just the source repository. List direct and transitive packages, bundled runtimes, native libraries and frameworks, and record the version and build that each release contains. Regenerate it for every release, because the installer is what users run.
Why apps are different
A web service runs on your servers, so you can patch it today. An installed app sits on thousands of devices at whatever version each user last updated to. A vulnerable library inside it stays exposed until the user updates, which is why knowing exactly what shipped matters more.
What to list
- Package manager dependencies, direct and transitive, with exact versions from the lock file.
- Bundled runtimes and frameworks, such as an embedded browser engine, a language runtime or a UI toolkit. These are large and often forgotten.
- Native libraries compiled into the binary or shipped next to it, including ones vendored as source.
- Mobile SDKs for analytics, ads, payments and crash reporting. Each is code you ship with your name on it.
- Assets with licences, such as fonts and icon sets, if you track licence obligations.
- Build identity: version, build number, commit and the signing identity used.
Where the repo view falls short
A lock file shows what you asked for. The installer shows what you got. The two differ when a build step copies files, a vendored folder is edited, or a platform packer adds components. Scan the final artifact, or the unpacked installer, as well as the repository.
Using the SBOM
- Match each component against vulnerability data on every release, and again when new advisories appear.
- Keep old SBOMs. When an advisory lands, you can answer which shipped versions are affected.
- Share it with customers who ask. Pick a standard format. See CycloneDX versus SPDX.
- Tie it to the update plan, so a fix in a bundled library triggers a release.
Mobile specifics
On mobile, the store packages your app, and third party SDKs often bring their own transitive libraries and permissions. Record the SDK versions you ship and review what data each one collects. When an SDK vendor announces a flaw, a current SBOM tells you in minutes whether you are affected and which app versions are in the field. Without one, you start by unpacking old builds.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how transitive packages appear beneath the ones you declared.
Safeguard generates SBOMs and scans dependencies, and there is a free scan at https://gold.safeguard.sh/scan if you want a first look at what your repository pulls in.
Quick check
Is a lock file an SBOM?
It is an input to one. An SBOM also records bundled runtimes, native libraries and build details.
How often should I regenerate it?
For every release, and rescan the stored ones when new advisories are published.
Last reviewed: 19 October 2026.
