Quaze + Trivy

Trivy is one of the most widely used open-source SBOM generators. It produces clean CycloneDX (or SPDX) output and runs against container images, filesystems, and repositories. This guide pairs Trivy with Quaze: Trivy generates the SBOM, Quaze keeps watching it.

What you need

• Trivy installed locally or in your CI runner — see Trivy install.
• A Quaze API token (qzat_…) — your organization owner can generate one in the app under Manage organization → API tokens.
• A product and a component in your Quaze workspace — created in the app, or via Create a component.

Generate the SBOM

Against a container image:

trivy image \
  --format cyclonedx \
  --output sbom.cdx.json \
  ghcr.io/your-org/your-image:1.0.0

Against a filesystem:

trivy fs \
  --format cyclonedx \
  --output sbom.cdx.json \
  ./your-project

Against a Git repository:

trivy repo \
  --format cyclonedx \
  --output sbom.cdx.json \
  https://github.com/your-org/your-project

You can also output SPDX with --format spdx-json if your tooling prefers it.

Upload to Quaze

Uploading is a two-step flow: request a presigned URL, then PUT the SBOM bytes to it.

#!/usr/bin/env bash
set -euo pipefail

QUAZE_API_TOKEN="${QUAZE_API_TOKEN:?missing}"
PRODUCT_ID="${PRODUCT_ID:?missing}"
COMPONENT_ID="${COMPONENT_ID:?missing}"
VERSION="${VERSION:-1.0.0}"
SBOM_FILE="${1:-sbom.cdx.json}"

# Optional: pin this version to the source commit so AI code analysis runs
# against the exact code you shipped. In GitHub Actions these come from the
# runner environment (GITHUB_SHA / GITHUB_REF_NAME).
COMMIT_SHA="${GITHUB_SHA:-}"
SOURCE_REF="${GITHUB_REF_NAME:-}"

# Step 1: request the upload URL
response=$(curl -fsS -X POST https://api.quaze.io/v1/upload-sbom \
  -H "Authorization: $QUAZE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"productId\":   \"$PRODUCT_ID\",
    \"componentId\": \"$COMPONENT_ID\",
    \"version\":     \"$VERSION\",
    \"fileName\":    \"$(basename "$SBOM_FILE")\",
    \"commitSha\":   \"$COMMIT_SHA\",
    \"sourceRef\":   \"$SOURCE_REF\"
  }")

presigned_url=$(printf '%s' "$response" | jq -r .presignedUrl)

# Step 2: upload the SBOM bytes
curl -fsS -X PUT "$presigned_url" --upload-file "$SBOM_FILE"

echo "Uploaded $SBOM_FILE for component $COMPONENT_ID @ $VERSION"

commitSha and sourceRef are optional — drop them if you are not using AI code analysis. When present, they let the analysis read the exact source you built from. See Upload an SBOM for the full request/response details.

What happens next

Once the SBOM is in Quaze:

• The component version is recorded against the product and component IDs you sent.
• Findings appear within a minute or two as the SBOM is matched against vulnerability data.
• New CVEs published in the future are evaluated against the SBOM automatically. You do not need to re-upload unless the release contents change.

If you ship a new version of the same component, just upload the new version’s SBOM the same way. Quaze tracks all versions side by side.

A typical CI pattern

A common shape inside a release job (any CI tool):

1. Build the artifact you ship (image, binary, bundle).
2. Run Trivy against the artifact, emitting a CycloneDX SBOM.
3. POST the metadata to /v1/upload-sbom and PUT the SBOM bytes to the returned URL.
4. (Optional) Create a release snapshot tying the new component version to the release.
5. (Optional) Deploy the release to the environment that just received it.

Steps 1–3 cover the minimum to start monitoring. Steps 4–5 give you release- and environment-level visibility.