Software Bills of Materials (SBOMs) are top of mind for most organizations, with 78% of them expecting to produce or consume SBOMs[1]. This is not surprising as the visibility provided by comprehensive SBOM makes it easier to answer the questions such as: “What’s the minimum number of libraries we must update to get rid of the Apache log4j vulnerability?”
Since over half of enterprise executives expect software supply chain related incidents to increase in 2022[2], getting SBOMs that are usable for incident response and prevention will only grow in importance. As software producing organizations evaluate technology to generate their SBOMs, this infographic explores items to consider, why those considerations matter and the benefits of using a modern approach for generating SBOMs.
Share this infographic:
<p><a href="https://blog.reversinglabs.com/resources/top-considerations-when-evaluating-sboms"><img src="https://www.reversinglabs.com/hubfs/Resources/Infographic/SBOM-infographic-ReversingLabs.jpg" alt="Infographic – Top Considerations When Evaluating SBOMs" border="0" /></a></p>
List of Top SBOM Considerations
1: Completeness matters when responding to new risks
Modern software can be a rat's nest of third-party, open source, and statically linked packages and dependencies that are many layers deep. Consider that research shows when installing an average npm package, a user implicitly trusts approximately 80 other packages due to transitive dependencies[3]. When looking for components with newly reported vulnerabilities you’ll need visibility into every layer and dependency. SBOMs that haven’t exposed every layer will "leave you with a risk that could have been avoided."
2: Accuracy matters when you are trying reduce software bloat
Reducing the number and variety of components and libraries can significantly improve software security. Missing or incorrect naming, version and publisher information in a SBOM makes it very difficult to rationalize and reduce the use of multiple versions of the same component within a single application (i.e. software bloat). Verification checks during SBOM generation can help ensure that each component in the software is what the SBOM says it is.
3: Understanding “software as delivered” matters when trying to identify malicious changes
Illicit changes to a software producer’s build infrastructure or to binaries being generated can enable attacks on customer networks, the most well-known example being Solarwinds. These changes are essentially invisible to development teams without a pre-release security assessment. Similarly a number of other items are often packaged with the software to assist with installation: installer software, separate installation libraries, or even an entire container. Vulnerabilities or tampering within these items can introduce the same security risks. The SBOM created during the final build (i.e.“Software as built”) will not list these components, leaving organizations blind to the risks. “Software as delivered” – the binary and packaging – is what matters from a security standpoint.
4: Integrated risk analysis matters when trying to automate new security practices into software development lifecycle (SDLC) or devops pipelines.
A list of what’s in your software is great, but having component data linked to other information makes it more actionable by development teams. Automated binary analysis of each component, as it’s found and listed in your SBOM, can deliver:
- A software quality grade for each component so you know at a glance where major issues need remediation
- Insight into indicators of supply chain compromise, such as software tampering, malware, ineffective mitigations or certificate signing issues
- Remediation advice and prioritization that helps teams focus on the most important software security improvements
References
[1] linuxfoundation.org
[2] www.pwc.com
[3] usenix.org
