Retention Policies
Server-side retention behavior, CLI flags, and examples for keeping SBOM history manageable.
How retention works
New attestations are typically imported when new versions of applications or services are deployed, or when attestations for already deployed versions are updated (new VEX information etc).
Over time the number of attestations accrue and should be archived to reflect the current active set of applications.
Retention policies control how many recent versions of an SBOM (or other attestation) for a specific component is kept in the index ("imported") when a new SBOM is uploaded. Older versions identified by the policy will be automatically archived (they remain available for audit retrieval).
The default behavoir when uploading attestations is that no retention policy is applied.
Archived != deleted
Pruned SBOMs are archived, not destroyed. Administrators can restore them for audits or legal holds even if they fall outside the active retention window.
Only available from the CLI and API
The retention policies are only applied when attestations are uploaded from the CLI or directly to the API. When manually uploading SBOMs in the web ui, you need to manually archive any older attestations that you don't want to keep in the index.
CLI flags
When uploading SBOMs you can tune retention directly from the observer CLI:
-p, --retention-policy <name>– Apply a named policy that may be preconfigured server-side.-n, --retention-keep <count>– Keep only the latest N SBOM versions for the component (defaults to1).-d, --retention-keep-dependencies <true|false>– Whentrue, SBOMs for components with dependants (i.e. they are dependencies for some other application) kept. This prevents losing context for supply-chain changes between releases.
These options can be combined. For example, a policy might enforce defaults while individual uploads override the keep count for special cases.
Available Retention Policies
| Policy Name | Description |
|---|---|
basic | Considers components related when the have the same name, group and type |
Behavior by option
| Setting | Result |
|---|---|
--retention-keep 1 | Only the newest SBOM is kept. Older versions are archived. |
--retention-keep 5 | The latest five SBOMs is kept; anything older is archived. |
--retention-keep 20 --retention-keep-dependencies true | Keep the latest 20 SBOMs, plus any older that are depended on. |
Choosing values
| Use case | Suggested keep | Notes |
|---|---|---|
| Rapid CI builds / feature branches | keep = 1 (default) | Keeps storage light while ensuring the latest artifact is always ready. |
| Critical customer-facing service | keep = 20 + keep-dependencies=true | Preserves richer history for incident response and dependency drifts. |
For guidance on the strategic “why” behind these settings, see the Retention Strategy concept page. For broader CLI usage, refer to the Observer CLI reference.