Integration
Quaze + CycloneDX
Quaze accepts CycloneDX SBOMs natively, with version, package URL, and VEX-style fields preserved end to end. Generate with any CycloneDX-compatible tool; monitor with Quaze.
The workflow
- 1 Generate a CycloneDX SBOM with the tool that fits your stack (Syft, Trivy, npm, mvn).
- 2 Upload the file to Quaze, tagged with product, release, and environment.
- 3 Quaze stores the SBOM with full PURL and version detail preserved.
- 4 Continuous monitoring evaluates the SBOM against fresh vulnerability data.
CycloneDX is the SBOM format most commonly chosen by teams whose primary goal is vulnerability monitoring. It is an OWASP project, compact, JSON-first, and built with security workflows (including VEX) in mind. Most SBOM generators emit CycloneDX natively.
Quaze accepts CycloneDX SBOMs directly. Package URLs, versions, license fields, and VEX-style determinations are preserved end to end, so a precise SBOM produces precise alerts.
What Quaze does with the SBOM
- Stores the SBOM tagged with product, release, and environment, preserving full PURL and version detail.
- Watches the SBOM continuously against fresh vulnerability data. New CVEs against listed components produce findings.
- Respects fix-version metadata in upstream advisories, so a transitive that already moved past the affected range does not generate noise.
- Surfaces VEX-style determinations alongside the SBOM when triage decisions are captured.
A worked example
A team generates a CycloneDX SBOM via Syft for every release of a service. The SBOM uploads to Quaze tagged with product=quaze-api, release=2.4.1, environment=production-eu.
Two weeks later, a CVE is published against library-x versions < 1.4. Quaze checks the SBOM, sees that library-x@1.3 is in the release, and surfaces the finding. Because the CycloneDX SBOM included precise PURL and version data, there is no ambiguity about which release is affected and no false positives from version-range guessing.