Documentation

Install

SBOM Sentinel is a single command-line program. It uses Syft to build a software inventory and Grype and Trivy to check it. Homebrew and Scoop install these tools for you.

macOS · Homebrew

brew install cloudengine-labs/tap/sbom-sentinel
sbom-sentinel --version

Upgrade later with brew upgrade sbom-sentinel. Current Homebrew version: 0.3.2.

Linux · Homebrew on Linux

Install Homebrew first if you don't have it, then run:

brew install cloudengine-labs/tap/sbom-sentinel
sbom-sentinel --version

Works on x86_64 and ARM64, on Ubuntu 22.04 or newer and equivalent distributions (glibc 2.34 or newer).

Windows · Scoop

scoop bucket add cloudengine-labs https://github.com/cloudengine-labs/scoop-bucket
scoop install sbom-sentinel
sbom-sentinel --version

Upgrade later with scoop update sbom-sentinel. Current Scoop version: 0.3.1.

Windows · Chocolatey (coming soon)

The package is submitted and waiting for Chocolatey's review. choco install sbom-sentinel will not work until it is approved; use Scoop for now.

Download manually

Each release has an archive and a .sha256 checksum. Check the archive against its checksum, unpack it, and put sbom-sentinel on your PATH. For manual installs, also put syft plus grype and/or trivy on your PATH.

Quick start

Run these from your project folder. Keep changes on a branch so you can review and revert them.

1. Find vulnerable dependencies

sbom-sentinel scan .

Scan finds your projects, builds a software inventory for each, checks it with Grype and Trivy, and writes a report folder at <project>/.sbom-assessment/<timestamp>/. It prints the path.

2. Write a fix plan

sbom-sentinel remediate .sbom-assessment

This writes remediation-plan.json and prints a Plan ID. It never changes your project.

3. Preview the plan

sbom-sentinel apply-remediation .sbom-assessment/<run>/remediation-plan.json

Replace <run> with the timestamped folder from your scan. Without --apply, this is a read-only preview: it lists each upgrade, marks it direct or transitive, and warns if a file changed since the plan was made.

4. Apply with confirmation

sbom-sentinel apply-remediation <plan> --apply --confirm <PLAN-ID>

Replace <plan> with the plan's file path and <PLAN-ID> with its printed ID. The command refuses to run if the ID doesn't match or a manifest changed. Then run your tests and a build, and review git diff.

5. Verify the fixes

sbom-sentinel scan .

Scan again to confirm. Findings that remain usually have no published fix yet.

Other commands

Reading the results

• report.md is a readable summary. issues.csv opens in a spreadsheet. findings.json is for scripts.
• A finding is a vulnerability, not a package. One package can have many findings.
• Reports list only vulnerable packages, sorted most severe first.
• The report command takes the scanned project's .sbom-assessment folder. Relative paths resolve from where you run the command; use the full path if you're elsewhere.

Use it in CI

By default, scan exits 0 even when it finds vulnerabilities. Add --fail-on to make it a gate:

sbom-sentinel scan . --fail-on high

Reports are always written first, and a one-line PASS or FAIL goes to stderr. You can also gate an existing scan:

sbom-sentinel report <folder> --fail-on high

Compatibility

Operating systems

The Windows binary isn't code-signed. Windows SmartScreen may ask for confirmation the first time you run it.

Languages and ecosystems

Scanning covers all eight ecosystems below. Automatic fixing is most complete for Node (JavaScript & TypeScript).

For Node projects, the package manager is detected from the packageManager field in package.json, then the newest lockfile (bun.lock/bun.lockb, pnpm-lock.yaml, yarn.lock, package-lock.json), then npm. Transitive packages are fixed with overrides, resolutions or pnpm.overrides; dev dependencies stay in devDependencies. Multiple package-manager lockfiles trigger a warning: keep one and delete stale lockfiles.

Requirements

• syft, plus grype and/or trivy on your PATH. Homebrew and Scoop install them.
• Internet access the first time and whenever scanner databases update. Without it, Trivy fails with a ‘failed to download vulnerability DB’ error.

How it stays safe

• Scanning never changes your project. It writes only inside .sbom-assessment/.
• Fixes need two steps: preview first, then --apply --confirm <PLAN-ID>.
• Plans record a hash of every file they will change and refuse to run if one changed.
• No shell commands are built from package names, and there is no telemetry.
• Everything runs on your machine. Scan results are not sent anywhere.

Know the limits

• It reports what the Grype and Trivy databases know. A clean result is not proof of safety.
• An upgrade can break your code. Run your tests and a build before merging; keep changes on a branch.
• Some findings have no published fix. Packages installed at several major versions may need a manual upgrade.
• It doesn't tell you whether your code actually uses the vulnerable function.
• There is no undo command. Review git diff and revert with git if needed.

Troubleshooting

License

Apache License 2.0. Free to use.