Retention Policies
Server-side retention behavior, CLI flags, and examples for keeping SBOM history manageable.
How retention works
Every SBOM uploaded to SBOM Observer is versioned per component. Retention policies control how many recent versions stay “active” in search results while older ones are archived in the order they were ingested. Archived SBOMs remain available for audit retrieval, but they no longer generate noise in dashboards or consume high-performance storage. The default policy keeps only the latest SBOM per component.
CLI flags
When uploading SBOMs you can tune retention directly from the 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 that introduce dependency changes are kept even if they fall outside thekeepcount. 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.
For broader CLI usage, refer to the Observer CLI reference.
Behavior by option
| Setting | Result |
|---|---|
(default) --retention-keep 1 | Only the newest SBOM stays active. Older versions move to archive. |
--retention-keep 5 | The latest five SBOMs remain searchable; anything older is archived. |
--retention-keep 20 --retention-keep-dependencies true | Keep the latest 20 SBOMs, plus any older ones that introduced dependency deltas. Ideal for critical services with frequent builds. |
Named policy (e.g., --retention-policy regulated) | Uses the server-defined combination of keep count and dependency rules, ensuring consistency across teams. |
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.
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. |
| Regulated release train | keep = 5 and tag milestone SBOMs | Align retention with documented release cadence. |
For guidance on the strategic “why” behind these settings, see the Retention Strategy concept page.