The art of integrating the Software Bill of Materials into your work processes, your release management, your development work, your CI/CD pipeline and your inner self needs some guidance. That’s what we developed for you! Enjoy the Zen of SBOM!
1. SBOM is not a single process to be completed. It is a lifecycle process
SBOMs need to be created throughout the development lifecycle. They are not just ‘another’ artefact which you have to produce as part of the release process. Throughout the lifecycle, SBOMs capture key decisions about your product – the components that are used, the versions selected, the licences that are acceptable. This information evolves throughout the lifecycle as decisions are made. SBOMs are not ‘done’ when you generate them; they are the start of something which needs to evolve with your product.
2. Dependencies are like relatives. You can’t choose them but they’re important
Many third party software components require other components in order to deliver the functionality. This helps software to be delivered quickly as it prevents engineers wasting valuable effort in reproducing existing (and hopefully proven) functionality. However this comes with an obligation; you need to identify the components and their dependencies. Whilst you have a choice on which components you select to use, you have no choice of the dependencies (often called transitive) which they depend on. As these dependencies contribute to your product, any weaknesses in your product could come from these dependencies and it is important that your SBOM captures the complete picture.
3. SBOMs are not the answer to all software problems but it sure helps
There are many problems with software with growing complexity, costs and technical debt being significant challenges. SBOMs won’t solve any of these on their own but they will help support the decision making process. They can assist in recognising technical debt by identifying obsolete or unmaintained components; they can challenge complexity by offering insights into the software’s composition, enabling developers and security teams to understand potential risks.
4. Completeness improves the usefulness of the SBOM
The utility of a SBOM is directly proportional to its completeness. A comprehensive SBOM, detailing all dependencies and components, and their associated metadata like licenses and versions, provides an invaluable foundation for a multitude of use cases. Without this thoroughness, an SBOM’s ability to effectively support critical functions is significantly diminished, potentially leading to security gaps and operational inefficiencies.
5. Enriched content is better than minimal details
SBOMs are essential for various critical functions like licence compliance, vulnerability management, and regulatory compliance. While some SBOM data is universally applicable, other information may be specific to particular use cases. The risk of only including data for an immediate need is that it severely limits the SBOM’s long-term utility. To truly unlock the full potential of an SBOM and ensure its relevance for both present and future demands, it’s crucial to include as much comprehensive data as possible.
6. Interoperability is better than fixed format
SBOMs at the basic level are just a list of components and associated attributes. Whilst these could be captured in a document or a spreadsheet, the value of an SBOM comes from following one of the established international standards CycloneDX or SPDX in a format which promotes interoperability and machine readability. Custom formats should be avoided.
7. Current is better than out of date
SBOMs represent a snapshot in time. An “out-of-date” SBOM, much like an expired ingredient list, can provide a false sense of security. A static, point-in-time SBOM quickly loses its value in managing risks and ensuring compliance. Regularly updated and current SBOMs are crucial for accurate vulnerability management, proactive incident response, and maintaining a trustworthy software supply chain, to enable informed decisions to be made based on the most accurate available data.
8- Quality is better than quantity
The content of an SBOM will support many decision making processes. It is essential that the data is accurate and correct otherwise there can be many misinformed decisions. There should be prioritisation given to generating SBOMs that are correct, well-formed, and contain the necessary contextual information to be truly useful, rather than just producing an SBOM for the sake of having one.
9. Now is better than never to generate and share
SBOMs have value within an organisation but they also have great value throughout the software supply chain, both upstream (suppliers) and downstream (customers). Sharing SBOMs promotes and improves transparency and ultimately improves the resilience and reliability of software components and products.
10. Any SBOM is better than no SBOM
Without an SBOM, there is no visibility. Even an incomplete or partially generated SBOM provides some level of transparency and initial insight into software components, which is a significant improvement over having no visibility at all. This partial data can still enable fundamental risk assessments and help in identifying vulnerabilities. It fosters a culture of transparency and proactive security, even if it doesn’t immediately solve all challenges. While the ultimate goal should always be a complete and accurate SBOM, seeing the value of incremental progress encourages adoption and allows the benefits to be achieved sooner.
By Anthony Harrison and Olle E. Johansson, SBOM Europe. All rights reserved.
