In today’s complex software landscape producing digital products, the Software Bill of Materials (SBOM) has emerged as a crucial tool for understanding the components within our applications. Organisations are increasingly adopting them, driven by security concerns, regulatory pressures, and a desire for greater transparency.
If you’ve got an SBOM for your software, that’s a fantastic step forward!
However, simply having an SBOM isn’t always enough. Just as a hammer is great for nails but not for screws, an SBOM’s utility is tied to its type. Not all SBOMs are created equal, and using the wrong type for your intended use case can leave you exposed or, at best, working with incomplete or irrelevant information.
There are six types of SBOMs, each offering a unique perspective on your software’s composition at different stages of its lifecycle. Understanding these distinctions is key to maximising their value.
When you ask for an SBOM you need to consider what you are going to do with the SBOM once have received it. And this comes down to the use case(s) that you are going to perform. In many cases, multiple stakeholders have a need for the information which you can capture within a SBOM.
So which use cases are suitable for which type of SBOM?
Use Cases for a Design SBOM:
- Early Risk Assessment: Identify potential licensing conflicts or known vulnerabilities in planned components (although the version of a component will unlikely to be known unless this is an identified constraint) before development even begins.
- Supplier Due Diligence: Evaluate the security posture of third-party libraries and services you intend to integrate. Are they maintained? How quickly are defects, and in particular those related to security, remediated?
- Architectural Compliance: Ensure chosen components align with organisational security policies and architectural standards.
- Cost Estimation: Forecast potential licensing costs associated with open-source or commercial components.
Use Cases for a Source SBOM:
- Developer Visibility: Provide developers with a clear view of their direct dependencies. Depending on how the dependencies are specified (are pinned versions specified?), specific versions of the dependencies may not be known.
- License Compliance (Early): Identify and manage licenses of declared dependencies at the source level.
- Vulnerability Scanning (Early): Perform initial vulnerability scans based on declared dependencies.
- Code Review Enhancement: Aid in reviewing dependencies brought in by new features or modules.
Use Cases for a Build SBOM:
- Supply Chain Integrity: Verify that only approved and expected components are included in the build.
- Reproducible Builds: Essential for ensuring that a given source code always produces the same binary or product, a critical step for trust.
- Attestation: Create cryptographic attestations about the build process and included components.
- Early Vulnerability Remediation: Pinpoint exact versions of vulnerable components that made it into the build, allowing for precise patching.
Use Cases for an Analysed SBOM:
- Discovering Hidden Dependencies: Uncover components that weren’t explicitly declared.
- Deep Vulnerability Analysis: More accurately assess vulnerabilities by understanding the call graph and reachability of vulnerable functions.
- Malware Detection: Identify malicious or unauthorised components embedded within the software.
- Compliance Auditing: Provide a more robust and verifiable list of components for regulatory compliance.
Use Cases for a Deployed SBOM:
- Deployment Security Baseline: Establish a baseline of components for production environments.
- Incident Response Preparation: Quickly identify components in deployed software during a security incident.
- Vulnerability Management (Late): Perform vulnerability scans based on what’s actually installed and prioritise patching efforts based on an assessment of risk.
- License Compliance (Late): Identify and manage licenses of all dependencies.
- Configuration Drift Detection: Compare deployed SBOMs over time to detect unauthorised changes.
Use Cases for a Runtime SBOM:
- Real-time Vulnerability Monitoring: Detect and alert on vulnerabilities in components actively being used in production.
- Behavioral Anomaly Detection: Identify unexpected or unauthorised components being loaded or executed.
- Supply Chain Attack Detection: Pinpoint malicious components introduced or activated during runtime.
- Optimised Resource Allocation: Understand which components are truly necessary for a given workload.
This is quite a diverse set of use cases. And clearly one type of SBOM is unlikely to meet all the use cases which are typically required.
So next time, you ask for an SBOM, explain what use cases you are considering. An enlightened supplier of SBOMs should understand the data which you require in order to meet your needs. If they only have one type of SBOM, then that is revealing and it may require that you generate an SBOM based on the information you have. Whilst this is not ideal, it may be necessary to support your use cases.
A very important point is that the use cases are focusing on the content of the SBOM and not the format. This is a critical observation; if the provider of the SBOM is focused on the format and not the content, then this should be a warning as it may indicate that they are not focusing on support the use cases which consumers of SBOMs need.
So how do the SBOMs you have stack up? Share you experiences and help make SBOMs a valuable artefact to support the numerous needs for an organisation or user of digital products.
Originally posted on LinkedIn
