Every SBOM belongs to exactly one place in a three-level hierarchy:
| Level | What it is | Example |
|---|---|---|
| Project | A product, repository or service you own | checkout |
| Version | A release of that project | 2.4.0, main |
| Artifact | One deliverable of that version | checkout-api, checkout-web |
You create projects yourself. Versions and artifacts are created automatically when an SBOM arrives for a name that doesn’t exist yet.
Where version and artifact names come from
By default we read them from the SBOM’s root component:
- CycloneDX:
metadata.component.versionandmetadata.component.name - SPDX: the first package’s
versionInfo, and the documentname(or the first package’s name)
If the SBOM doesn’t say, the version is unversioned and the artifact is named after the uploaded file. You can always override both when uploading — for example with the Git branch or tag as version (see CI integration).
Uploads
Every upload is kept. The project overview shows the upload history; findings are always computed from the latest SBOM of an artifact version. Uploading the same artifact version again (say, from a second pipeline run) simply replaces what you see, while your triage decisions stay in place.
Support period
Every version has a support end: the first day you no longer support the release. The EU Cyber Resilience Act asks manufacturers to declare this period (Art. 13, usually at least five years). Versions in support are re-analysed automatically whenever the vulnerability database changes.
A new version has no support end and is monitored until you set one, so nothing drops out of monitoring by accident. The Versions tab shows No support end set as a reminder. Set the date there, or click End support today when a release reaches end of life. Its SBOMs, findings and triage decisions stay available, but it no longer generates new findings. Clearing the date turns monitoring back on. Several versions can be in support at the same time, for example when you maintain more than one release line.
Why the hierarchy matters for triage
Triage decisions are stored per artifact version and vulnerable component, not per uploaded file. That means:
- A decision survives every re-upload and re-analysis of the same artifact version.
- A new version starts with a clean slate — the code changed, so earlier assessments need a fresh look.
- Two artifacts of the same version are triaged independently: a vulnerability can matter for your API image and not for your CLI.