We publish our own SBOM on every build. Here's the pipeline.

There is a category of company that sells a discipline it does not practice. We decided early that the fastest way to find the rough edges in an SBOM platform is to be subject to it — so SBOMVault generates an SBOM of SBOMVault on every build, and that document flows through the exact product pipeline our customers use.

The pipeline

The mechanics are deliberately boring, which is the point — this is what we tell customers to build, so it had better be buildable:

1. Generate on every merge. A CI job runs on our main branch (and weekly on a schedule) and produces a CycloneDX SBOM with syft — read from the resolved dependency tree the build actually installs, not a filesystem scan after the fact, and using the same generator family our shipped integrations use.
2. Refuse an empty document. The job fails unless the SBOM parses and contains components. That gate exists because SBOM generators fail politely: a misconfigured run happily emits a valid, empty document, and an empty SBOM looks exactly like a secure one.
3. Scan the document itself. An OSV pass runs over the generated SBOM — not the lockfile — consuming it exactly the way a customer's tooling would. If our own SBOM stops being matchable, we find out before a customer does.
4. Gate the release. The blocking vulnerability gate lives in the main CI pipeline (OSV scan plus dependency audit on the lockfile), and the SBOM itself is published as a build artifact of every run — so "send us your current SBOM" is a download, never a project.

What dogfooding has actually taught us

The honest argument for this setup is what it has surfaced. The empty-document gate is there because we got burned by how quietly generation can fail. Consuming public advisory APIs for our own monitoring means we experience their outages — rate limits, 502s from upstream feeds — as users, which is why our matching pipeline degrades gracefully and fills back in when a source recovers, instead of erroring.

It also keeps us honest about noise. When a wave of advisories lands on transitive dependencies, we feel the triage burden ourselves before our customers ask about it. Product decisions about prioritization and alert routing get made by people who sat in that queue the same week.

Why this matters when you evaluate any vendor

This is not really a post about us. It is an evaluation heuristic that costs you one question: ask any SBOM vendor for the SBOM of their own product, and ask how it was produced. A current, complete, well-scored document that falls out of their CI tells you their pipeline works end to end — and that they trust their own product enough to live in it. A two-month-old JSON file assembled for your meeting tells you something too.