Skip to content
Quaze docs

Products, releases, environments

Quaze models the world as products, releases, and environments. These three entities are how Quaze knows which deployment is affected when a CVE drops, who owns it, and what to do about it. Getting them right at the start makes everything downstream simpler.

Product

Section titled “Product”

A product is the unit of software you ship. Examples:

  • quaze-api — a SaaS backend service.
  • quaze-cli — a CLI tool you distribute.
  • customer-portal — a customer-facing web app.

A product is the level at which ownership, support periods, and CRA-style obligations apply. Each SBOM you upload belongs to exactly one product.

A typical organisation has a handful of products, not dozens. If you find yourself creating hundreds, you may be thinking at the release or component level instead.

Release

Section titled “Release”

A release is a versioned snapshot of a product. Examples:

  • quaze-api release 2.4.1
  • quaze-cli release 0.12.0-beta
  • customer-portal release 2026-05-20-deploy

Releases are how Quaze tracks what is shipping over time. Each release has its own SBOM. You can have many releases of one product alive at the same time, especially if you support older versions for existing customers.

The release identifier is up to you. Semantic versions, calendar versions, and Git SHAs all work. The only rule is that it should be unique within the product.

Environment

Section titled “Environment”

An environment is where a release runs. Examples:

  • production-eu
  • production-us
  • staging
  • customer-acme-prod

An environment is the layer that turns a static SBOM into a live deployment. When a CVE drops, the question “is this in production?” is answered by checking which environments are mapped to releases that contain the affected component.

You can have a release deployed in multiple environments at once (a single image running in three regions), and an environment can host multiple releases over time (production was on 2.4.1 last week, now on 2.4.2).

How they fit together

Section titled “How they fit together”
product
  ├── release 2.4.0      (live in staging)
  ├── release 2.4.1      (live in production-eu, production-us)
  └── release 2.5.0-rc1  (live in staging-canary)

A new CVE is published. Quaze walks the model in this order:

  1. Which SBOMs reference the affected component?
  2. Which releases do those SBOMs belong to?
  3. Which environments are those releases live in?
  4. Which products do those releases belong to?
  5. Who owns those products?

By the time the question reaches a human, it is scoped: “release 2.4.1 of quaze-api is affected, it runs in production-eu and production-us, the platform team owns it.”

Mapping releases to environments

Section titled “Mapping releases to environments”

There are two ways to associate a release with an environment in Quaze:

  • Per-release via Import release to environment once the release ships. Easiest in the common case.
  • Per-component via Deploy to environment when components roll independently of releases.
  • Via the app when deployment happens out of band, or as a one-off.

Ownership

Section titled “Ownership”

Components inside a release map to owning teams. Once mapped, every new finding against that component is routed automatically. You configure the component-to-team mapping inside the app; you do not need to send ownership information in the SBOM itself.

When to create a new product vs a new release

Section titled “When to create a new product vs a new release”

A rough rule of thumb:

  • New release — same software, new version. Typical case for every CI build that ships.
  • New product — different software, different ownership, different support cadence. A new microservice, a new CLI, a new offering.

When in doubt, prefer fewer products and more releases. You can always split later.