References

Retention policies

Archive older SBOM versions on upload: the basic policy, CLI flags, and matching rules.

A retention policy archives older versions of an SBOM when a newer one is uploaded, so the index reflects what is deployed now instead of every build ever uploaded. Archived attestations move to the Archived tab on the Attestations page; they are not deleted.

Retention only runs when it is requested on upload, from the CLI or the API. Uploads in the web interface never apply it; archive older versions there by hand.

CLI flags

observer upload takes three retention flags:

FlagDefaultMeaning
-p, --retention-policynonePolicy to apply. The only policy is basic. Without this flag no retention runs and the other two flags are ignored.
-n, --retention-keep1How many versions to keep, counting the one being uploaded.
-d, --retention-keep-dependenciestrueKeep older versions whose component is a dependency of another component, even beyond the keep count.
observer upload -p basic -n 3 sbom.cdx.json

The API takes the same settings as retention-policy, retention-keep, and retention-keep-dependencies, as query parameters or multipart form fields.

Which versions count as the same SBOM

The basic policy compares the new upload with earlier, non-archived attestations. An earlier attestation is a candidate for archiving when all of these match the new one:

  • attestation type (for example CycloneDX),
  • component type, name, and group,
  • tags.

Candidates are sorted by upload time and all but the newest ones within the keep count are archived. Policies are then evaluated again against what remains.

Supplier-scoped input

The input a supplier-scoped policy receives, with TypeScript types and a sample.

Roles and permissions

Organization roles in SBOM Observer and the permissions each one grants.

On this page

CLI flagsWhich versions count as the same SBOMRelated