Integration
Quaze + Trivy
Use Trivy to generate the SBOM; let Quaze keep watching it. Together they cover the full lifecycle from build-time scan to continuous post-release monitoring.
The workflow
- 1 Trivy generates a CycloneDX SBOM as part of your release build.
- 2 Your CI step uploads the SBOM to Quaze, tagged with product, release, and environment.
- 3 Quaze keeps watching that SBOM against fresh vulnerability data.
- 4 When a new CVE matches, the finding is routed to the team that owns the component.
Trivy is one of the most widely used open-source SBOM generators. It is fast, ships with sensible defaults, and produces clean CycloneDX (or SPDX) output as part of a normal CI step.
What Trivy does well is the generation side of the workflow: it inspects container images, filesystems, or repositories and produces an accurate component list. What it does not do is keep watching that SBOM after the build. Once Trivy emits the file, its job is done.
That is where Quaze fits. Trivy hands the SBOM off to Quaze, and Quaze takes over the rest of the lifecycle: store, monitor, triage, and report. You keep your existing Trivy setup and add monitoring on top.
Where the responsibilities split
- Trivy: generate the SBOM at build time, with whichever scanner mode your pipeline uses (container, filesystem, repo).
- Quaze: receive the SBOM, tag it with product/release/environment, watch it continuously against fresh vulnerability data, route findings, and produce evidence packs.
If you also run Trivy as a scanner against the SBOM at build time, that is fine — Quaze does not replace the build-time scan, it complements it by continuing the work afterwards.
A worked example
A team builds container images in CI. Trivy runs as a CI step and emits a CycloneDX SBOM per release. The same CI step uploads the SBOM to Quaze via the upload API, tagged with product=quaze, release=2.4.1, environment=production-eu.
Two weeks later, a new high-severity CVE is published against a transitive dependency. Quaze re-evaluates all stored SBOMs against the new advisory, identifies that release 2.4.1 is affected, and routes the finding to the platform team that owns the component. The team did not re-run Trivy. The SBOM Trivy emitted two weeks ago was enough.