SBOM Lifecycle

The lifecycle of an SBOM covers the stages involved in creating, managing, and using a Software Bill of Materials (SBOM).

SBOM Generation

Generating an SBOM encompasses the following steps:

Asset Discovery: Identifying all software components, dependencies, and their associated metadata within an application or system. This involves understanding the software stack, open-source libraries, and third-party components.
Data Analysis: Processing the available data to extract relevant information for the creation of the SBOM
Creation: Generating the SBOM document based on the available data. This involves selecting an appropriate SBOM standard format (e.g., SPDX, CycloneDX) and populating it with component details, versions, licenses, and other available information.
Storage: Securely storing the generated SBOM for future reference and access. This might involve using version control systems, artifact repositories, or dedicated SBOM storage platforms.

Learn more about SBOM generation here.

Analyse

The analysis phase uses the SBOM to create insights about the software components identified in the SBOM. Multiple stakeholders should be examining the contents of the SBOM as part of a risk management approach. At the start of the analysis, the accuracy and completeness of an SBOM should be verified to ensure their reliability in subsequent analysis activities.

Typical SBOM analysis activities include:

Scanning for component vulnerabilities as part of a vulnerability management activity
Validating that all components are used in compliance with their licenses
Assessing the security risk of components not being maintained or
Understanding the supply chain to identify any issues with the ability of component suppliers to mitigate security risks with components.
Confirming that the software development policy in the use of 3rd party components is being followed

Much of this analysis can be automated by using appropriate tools and processes to extract maximum value from the SBOM data. APH10 has extensive experience in analysising SBOMS and can advise on suitable tooling to help in this activity. Contact us today to discuss your needs.

The analysis activity is a continual process; even if the SBOM is not changing, the status of software components is constantly changing as new vulnerabilities are being reported and the risk profile

Prioritsation

The analysis will inevitably identify some issues which need to be remediated. But how to select which ones need to be remediated first? This will depend on your risk appetite and availability of suitable resources. However the best approach is a risk driven approach which looks at the impact that the issues will have on an organisation rather than a metrics driven approach e.g. fix all vulnerabilities of a particular category.

Whatever approach is chosen, the priortisation process needs to be flexible to reflect a constantly evolving threat landscape.

Remediation

Implementing changes to a software product will result in a an updated SBOM being created. The lifecycle will then start again where the analysis can then establish if the changes have resulted in an improved security risk profile.

However it is important to manage and maintain each version of SBOM which represents a product which is deployed into an operational environment.

Next - The role of SBOMs and Compliance