Yes. Packaging a CLI as a single executable hides its dependencies from tools that read manifest files on disk, yet the code is still inside. Generate a software bill of materials at build time, from the same lockfile that fed the build, and publish it next to each release.
What gets lost when you bundle
A source project has a manifest and a lockfile. A scanner can read them and list every package. After you compile or bundle the tool into one file, those files are not on the user's machine. A customer who downloads your binary sees one file and has no list of what is in it.
Scanners that look inside binaries can recover some information, but they work from clues and miss things. The reliable source of truth is your build.
What an SBOM is
A software bill of materials is a list of the components in a piece of software, with names and versions. For a CLI release it answers one question for customers and for you: when a new vulnerability is announced in a library, is it in this release?
Where to generate it
| Point in the process | Quality of the list | Notes |
|---|---|---|
| From the lockfile in CI | Good, exact versions | Preferred default |
| From the built artifact | Variable, clues only | Useful as a cross-check |
| By hand | Poor, goes stale | Avoid |
Generate from the lockfile as the build runs, then compare to a scan of the final binary. If the two disagree, investigate before release.
Steps
- Pick an SBOM format your customers can read and stick to it.
- Generate it in the release job, from the committed lockfile.
- Name it clearly, with the tool version in the file name.
- Publish it as a release asset next to the binary and the checksum.
- Sign it, or at least list its checksum, so it cannot be swapped quietly.
- Keep every old SBOM. When an advisory lands, you need to answer for past versions as well.
- Feed it into your own monitoring, so you learn about new advisories before customers write to you.
Try it yourself
Open the demo and look at how an inventory ties each package to a version. Imagine that list attached to every release you ship.
Click through it at your own pace, or open it full screen.
Customers will ask
Buyers increasingly request component lists in security reviews. Having one ready per release shortens the review, and it lets you answer a question about a newly announced vulnerability in minutes instead of days.
Embedded runtimes count
If your binary bundles a language runtime or a native library, list it too. The runtime has its own advisories, and it is often the largest component by size.
Quick check
Can a scanner find the dependencies inside my binary without an SBOM?
Sometimes, in part. It is guesswork compared to a list from the build. Publish the list.
How often should I regenerate the SBOM?
At every release, and rescan old SBOMs against new advisories on a schedule.
Safeguard's SBOM and dependency scanning works from this kind of inventory, and the free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
