How do you generate and read an SBOM with the Safeguard CLI?

You generate an SBOM with the Safeguard CLI by installing it and running a scan against your project folder. The scan builds the bill of materials and matches it to advisories. Local runner mode does that work on your own machine, then returns results to your tenant.

What do you need first?

A terminal and a repo. The CLI docs at cli.safeguard.sh give one install line for macOS and Linux and one for Windows PowerShell.

curl -fsSL https://cli.safeguard.sh/install | bash

irm https://cli.safeguard.sh/install.ps1 | iex

If you do not like piping a script into a shell, the same page shows how to download the installer first and read it. Do that. It takes a minute. You can also pin a release with the SAFEGUARD_VERSION environment variable or choose an install location with SAFEGUARD_INSTALL_DIR.

Then sign in. The CLI uses the OAuth 2.0 device flow, so you run the login command and approve it in a browser.

safeguard login
safeguard whoami

How do you build the SBOM?

The docs do not describe a separate "make an SBOM" command. The scan is what builds it. Point it at the current folder:

safeguard scan --dir .

Other inputs exist. You can scan a repository URL, a container image reference, or an existing SBOM file. The existing file can be SPDX or CycloneDX.

safeguard scan --repo URL
safeguard scan --image REF
safeguard scan --sbom FILE

In CI you can add an output directory so every run writes to the same place.

How do you read what came out?

The docs name these files. Knowing which is which saves a lot of grepping.

• sbom.json is the bill of materials itself: the components found in your project.
• findings.json holds the combined findings.
• vuln.json holds vulnerability matches. The docs say it is compatible with grype output, with matches under the data.matches path.
• license.json covers licenses.
• secret.json covers secrets found.
• scorecard.json holds the scorecard.

Start with sbom.json and ask a plain question: does this list match what I think I ship? Look for components you did not choose. Transitive dependencies are the usual surprise, because they arrive without anyone typing their names.

One thing the docs do not state is which SBOM format the generated file uses. Do not assume. Open the file and check the top-level fields, then run the validator.

safeguard validate sbom.json

The validate command checks SBOM documents against the SPDX and CycloneDX specifications. That catches a malformed file before you hand it to a customer or an auditor.

Where does the local runner fit?

There are two ways to use it.

Run safeguard with no arguments and you get an interactive runner session. Inside it, the login command authenticates the machine and the help command lists what else is available.

Or run the on-prem runner. It claims scan jobs queued for your tenant, runs them locally, and returns the results. You can check its registration at any time.

safeguard runner
safeguard runner status

The point of local runner mode is that the repository is pulled and scanned on your machine, and only encrypted results are pushed back. If source code leaving your network is the blocker for your security review, this is the mode to read about.

Try the walkthrough at /demos/local-runner-cli.

What to do

1. Read the installer, then install the CLI on one machine.
2. Run login and whoami to confirm the token.
3. Run a scan with the dir option on one real repo.
4. Open sbom.json and compare it with what you expect to ship.
5. Run validate on the file before sharing it.
6. Wire the same scan into CI, writing output to a fixed folder.
7. If code must stay on your machine, set up the runner and check its status.

Quick check

Sources

• Safeguard CLI docs, fetched 18 October 2026.
• Free in-browser dependency scan, fetched 18 October 2026.

Last reviewed: 18 October 2026.