Time for the objections. If you have read this far you have at least one of them, and they are fair.
"Why should I trust a security tool I just heard about." "Why not stick with Syft, which I already run." "What is the catch with a 19 dollar platform." Good questions. Here are the straight answers.
Why the core is open source, and why that matters for this specific tool
A security tool you cannot inspect is a security tool you are taking on faith. That trade is bad for any category. It is worse for one whose entire job is telling you what is in your software and what it is allowed to do.
So the CLI is MIT licensed. The full thing. Unlimited local scans, CycloneDX and SPDX and AI-BOM output, the GitHub Action, OSV enrichment, and a self-hostable API you can run under Docker Compose. Read the code. Run it air-gapped. Use it commercially without asking. The license says you can.
That is not a marketing tier. It is the whole product at the layer where trust has to be earned. The hosted platform is a convenience built on top, not a paywall in front.
What happens to your source code
The most common worry first. Does this thing ship my code somewhere.
No. The CLI clones the repo to a temp directory, reads lockfiles and manifests, then deletes the clone. What reaches the hosted platform is SBOM metadata only: component names, versions, hashes, vulnerability IDs. Not source. Not secrets. Not environment variables. If that still makes you uneasy, run the self-hosted API and nothing leaves your network at all. The open source license exists precisely so that "trust us" is not the answer you have to accept.
Why not just keep running Syft
If a package-level SBOM is all you need, Syft is solid and you should keep using it. No argument.
The reason to switch is the AI-BOM. Syft and Trivy inventory your packages. Neither detects your model weights, hashes them, maps your datasets, or catalogs your MCP servers and their scope. That is not a knock on them. It is a different inventory shape they were not built for. If your stack has no AI in it, the gap does not apply to you. If it does, that gap is the difference between a clean-looking SBOM and actually knowing what your agents can touch.
You saw the benchmark numbers in the last post. Faster on lock-file scans, and it produces a file the others do not. Run both on your own code and decide.
When the free CLI is enough, and when it isn't
I would rather tell you to stay free than oversell the platform. So here is the honest line.
The CLI alone is plenty when:
- You scan a handful of repos
- You are fine reading JSON files and tracking history yourself
- You self-host or stay fully local
The hosted tier earns its keep when:
- You have more than a few apps and want one org-wide view instead of scattered files
- You want email alerts when a new critical CVE hits a component you already shipped
- You want AI-BOM analysis and CISA KEV enrichment on every scan without managing it
- You want to hand an auditor a link instead of a folder
The line is volume and memory. One repo, stay on the CLI. Twenty repos and an auditor on the calendar, the dashboard pays for itself in the first evidence request.
Enterprise is for the teams that need SSO, audit log export, an SLA, and data residency. If you have to ask, you are not there yet, and that is fine.
The part I won't oversell
AI-BOM tooling is young. The format is settled and the standards are real, but the broader ecosystem is still maturing. SBOMix is early, and so is the category. What that buys you is a head start before the inventory becomes mandatory, not a finished compliance product with a bow on it. I would rather you adopt this knowing that than feel sold.
Where to start
Run the free thing on one repo:
npx sbomix owner/repoIf the AI-BOM surfaces something you did not know was in there, star the repo and put the Action in your CI. When one repo turns into ten and the files get hard to track, the dashboard is there. Fourteen days, no card.
Start at the layer you can inspect. Move up when you have a reason to. That order is the whole pitch.