SBOM management: storage, versioning, sharing and lifecycle

Most of an SBOM's working life happens after it is generated. This guide covers how to store, version, share, enrich and retire SBOMs so they stay trustworthy.

The SBOM lifecycle

A managed SBOM passes through intake or generation, validation, storage, enrichment, sharing and eventual retirement. CERT-In's guidelines set out several expectations for this lifecycle: workflows to update SBOMs as components are introduced or changed, clear policies for handling and sharing SBOM data, and secure storage and transmission ^[1].

Versioning

CERT-In recommends a separate SBOM for each software version, updated only when additional component information is provided or errors are corrected ^[1]. The NTIA minimum elements similarly require a new SBOM for each new build or release, and accept that early SBOMs will contain mistakes that should be corrected in good faith ^[2]. In practice:

• Key each SBOM to a product, a version and an artefact hash.
• Keep superseded corrections, with the reason for the change.
• Store diffs between releases. CycloneDX CLI, for example, can diff two BOMs and report added, removed or modified component versions ^[3].

Storage and access

An SBOM portfolio shows exactly which components, versions and suppliers you depend on. CERT-In recommends that SBOM data be stored and transmitted securely using encryption, access controls and other security measures ^[1]. The NTIA report notes that SBOMs may be shared publicly or under access restrictions defined by licences or contracts ^[2]. Apply least privilege, separate supplier-provided SBOMs by supplier, and log access.

Sharing

CISA's SBOM Sharing Lifecycle Report describes three phases: discovery (how a consumer learns an SBOM exists), access (how they are authorised) and transport (how it is delivered) ^[4]. The report found that no single mechanism was used by everyone, with methods ranging from email to repositories ^[5]. CERT-In lists secure file-sharing platforms, API integration, collaboration tools and industry repositories as channels, and recommends digitally signing shared SBOMs ^[1]. Ecma TC54 is developing a Transparency Exchange API to automate discovery and exchange of SBOMs, VEX and attestations ^[6].

Intake of supplier SBOMs

CERT-In expects software consumers to ask for a complete SBOM, map it against their internal SBOM and include it in vulnerability management ^[1]. On intake: validate format and fields, verify the signature, compare against your own analysis of the delivered artefact, and record gaps as supplier actions. See SBOM procurement requirements for contract terms.

Enrichment

Several CERT-In fields, such as vulnerabilities, patch status, EOL date and criticality, change after release ^[1]. Keep the SBOM as delivered, and hold enrichment (vulnerability matches, known-exploited status, EOL dates, VEX decisions, owners) as linked data. This preserves the original for evidence and lets enrichment be updated daily. BSI's TR-03183-2 goes further and excludes vulnerability data from the SBOM itself ^[7].

Retention and retirement

Keep SBOMs for as long as the software version may be in use, plus the period your regulators expect for audit evidence. When a product version is decommissioned, mark its SBOM retired rather than deleting it, so historical questions ("were we exposed in March?") can still be answered.

For platform criteria that support these practices, see SBOM platforms.

How IntelliXBOM helps

IntelliXBOM stores CycloneDX and SPDX SBOMs with version history and diffs, and keeps enrichment such as vulnerability matches, known-exploited status, licences, EOL data and VEX decisions linked to each version. It runs self-hosted, including air-gapped, and produces timestamped evidence of the inventory at any point in time.