The latest build does not represent the whole estate
The new version passed pipeline checks, but the previous release remains in use at several clients. A vulnerability published tomorrow may affect that older release. Replacing its inventory with the latest build’s removes it from tracking while it remains deployed.
Link every SBOM to the product, version and artefact described, then to known installations. Retain provenance and collection date. To stop monitoring a version, identify who can confirm its retirement: a successful new release does not establish the status of all older installations.
Separate inventory, vulnerability knowledge and treatment
CycloneDX describes an SBOM as an inventory of components and services with their relationships. SPDX also provides a shared vocabulary for software information. Their usefulness depends on collection: missing versions, omitted dependencies and ambiguous origins limit matching even when a file conforms to its schema.
Distinguish three events: a new SBOM describes changed software or collection; refreshed sources may reveal vulnerabilities in an existing inventory; remediation evidence confirms treatment of an installation. A new case can therefore appear without a software change. A recently imported SBOM does not prove an update was deployed.
Sources: CycloneDX: SBOM capabilities, SPDX: Software profile
Keep identifiers and versions interpretable
Distinguish the commercial product from its component, then specify the ecosystem, version and origin. CPE and PURL facilitate exchanges, but identifiers alone do not confirm applicability. OSV distinguishes ecosystems and their versioning rules: identically named packages may represent different components.
When information is missing, send the supplier a precise request: embedded version, transitive dependency, variant or build. Keep the case pending that information. This traceability lets the assessment be reused for other installations sharing the same conditions.
Sources: OpenSSF: OSV schema 1.9.2
Maintain continuity with or without a pipeline
With CI/CD integration, associate the SBOM with the build before submitting it for monitoring. Define stable product, version and artefact conventions. Distinguish development, released and still-used versions: maintenance status and recipients may differ.
Without a pipeline connection, organise export or SBOM collection with teams and suppliers. Define who submits them, when to refresh them and how to reassess retained inventories. No pipeline does not prevent online source updates. Disconnected environments raise a separate issue: authorised transfers and their frequency.
Fictional example: an older version on two systems
Rivage 1.8 remains installed on A and B while 2.0 is prepared. New information, DEMO-SBOM-01, concerns a dependency in the 1.8 SBOM. Importing the 2.0 SBOM leaves both older deployments within scope.
Assessment can be shared if technical conditions match, but each system keeps its owner and treatment evidence. A migrates first; B remains monitored. Closure awaits confirmation of treatment or retirement. No new collection from B does not establish uninstallation.
Maintain the portfolio and measure coverage
Dependency-Track supports portfolio component tracking and project/version organisation. Verify the functions active in your installation: refreshed sources, versions still analysed and groupings used for metrics. Your conventions should make supported versions retrievable, including older ones.
CyberLifeCycle monitors that portfolio from the inventories received, assesses vulnerabilities and manages requests for further information. Alerts and metrics expose affected versions, collection age and pending cases. Teams receive the information needed to prepare maintenance decisions.
Sources: Dependency-Track v4.14: portfolio component tracking, Dependency-Track v4.14: project and version organisation, Dependency-Track v4.14: recurring tasks
Sources consulted
- CycloneDX: SBOM capabilitiesAccessed on 30 October 2026.
- SPDX: Software profileAccessed on 30 October 2026.
- OpenSSF: OSV schema 1.9.2Accessed on 30 October 2026.
- Dependency-Track v4.14: portfolio component trackingAccessed on 30 October 2026.
- Dependency-Track v4.14: project and version organisationAccessed on 30 October 2026.
- Dependency-Track v4.14: recurring tasksAccessed on 30 October 2026.