Phase 1 — Produce

This phase covers the process of generating an SBOM for a specific software artifact. This can be done manually or, preferably, as part of an integrated software development process. The SBOM should detail all components, direct and indirect dependencies, and relevant metadata. The quality and completeness of the SBOM are foundational for the rest of the lifecycle.

Functional Goals

Functional GoalDescription
CreationGenerating an SBOM for a specific software artifact.

Security Goals

Security GoalDescription
AuthenticityEnsure that the information used to create the SBOM comes from a trusted source.
IntegrityAll data involved in the production process must be included in the SBOM without alteration.
Non-repudiationThe origin of the SBOM can be reliably recorded, and the recipient has proof of the source’s identity.
ConfidentialityAn attacker cannot read the SBOM; it is encrypted or only accessible to authorized parties.
AuthorizationAn SBOM may only be edited by processes or users with the appropriate authorization.

Phase 2 — Share

After creation, the SBOM is shared between producer and consumer (or third parties). Secure and reliable exchange is essential, whether the SBOM is made public or shared privately. The process must ensure authenticity, integrity, and confidentiality.

Functional Goals

Functional GoalDescription
SharingFacilitate sharing from a supplier to a consumer, or from a consumer to a third party.
IngestionImport SBOMs from suppliers and/or third parties.

Security Goals

Security GoalDescription
AuthenticityVerify the identity of sender and receiver, as well as the correctness of the SBOM.
IntegrityAn SBOM must arrive at the recipient without modification.
Non-repudiationThe generation or sharing of an SBOM is recorded and cannot later be denied by the supplier.
ConfidentialityOnly authorized parties may view an SBOM.
AuthorizationOnly an authorized party should be able to share and receive an SBOM.

Phase 3 — Manage

This phase involves storing and maintaining SBOMs within the organization. It includes updating SBOMs when software changes, validating quality, converting formats, and enriching SBOMs with new vulnerability or security information.

Functional Goals

Functional GoalDescription
Quality assessment & validationCheck structural correctness and completeness of the SBOM against SBOM standards and internal requirements.
ConversionConvert SBOM information into formats (often CycloneDX and SPDX) supported by organizational tools and processes.
ManagementManage the SBOM collection: ensure availability, integrity, and confidentiality; verify validity; archive SBOMs no longer relevant.
EnrichmentEnrich SBOMs with new vulnerability information and security advisories (e.g., VEX and CSAF), and add dependency/quality info from other sources.

Security Goals

Security GoalDescription
ConfidentialityThe SBOM storage within an organization must only be accessible to authorized users.
IntegrityDuring SBOM management, it must remain accurate and complete; updates in the software product must be reflected in the SBOM; old SBOMs should be archived.
AvailabilitySBOM storage must always be available for use.
AuthorizationSBOMs should only be managed by an entity with the appropriate authorization.

Phase 4 — Deploy

In this phase, the SBOM is actively used for risk management, vulnerability management, and compliance processes. The SBOM is linked to vulnerability information to assess and mitigate risks in the software supply chain.

Functional Goals

Functional GoalDescription
Vulnerability assessmentUse SBOM and vulnerability information for security operations and risk management.

Security Goals

Security GoalDescription
ConfidentialitySBOM and vulnerability information should not be visible to unauthorized individuals.
IntegrityEnsure that the deployed SBOM is correct and complete.
AvailabilityAn organization must always have access to the SBOM collection to quickly link vulnerabilities.
AuthorizationOnly authorized individuals may make changes or add information to the systems.