What you’ll learn:
- SBOMs provide visibility into software supply chain risks and vulnerabilities
- SBOMs can be generated automatically, including for C/C++
- SBOMs are useful for both compliance and security
- SBOMs improve transparency and trust between suppliers and customers
Software bill of materials (SBOMs) are becoming more prominent by the day in the world of product and software security. Regulatory guidance, industry standards, cyber threats, and growing concerns about the security of the software supply chain are driving their adoption. Even so, many misconceptions exist about SBOMs, who should care about them, and how best to put them to use across an organization.
With the increased focus on SBOMs over the past few years, it’s safe to say they’re here to stay. Joseph M. Saunders from RunSafe Security highlights common myths about SBOMs and how they can be indispensable tools in the modern software landscape.
1. SBOMs have no security benefit.
SBOMs have enormous security benefits, giving organizations visibility into potential software supply-chain risks. With an SBOM, organizations can quickly identify potential vulnerabilities in software components, understand common vulnerabilities across product lines, and take action to prioritize mitigation strategies based on the vulnerabilities identified.
2. Binary-based SBOMs are sufficient.
Binary-based SBOMs are created by analyzing compiled software. Because binary SBOMs rely on heuristics and binary composition analysis, they’re often unable to uncover complete dependency tree mapping or call flow graphs. Because of this, binary-based SBOMs may miss certain components or software dependencies.
SBOMs should, however, include the most comprehensive and accurate information possible to bring the most benefit to an organization. Build-time SBOMs, which are generated during the software compilation process, eliminate the need for binary analysis. This provides perfect visibility into all components written into a binary so that you have a complete understanding of the dependencies.
3. C/C++ SBOMs need a package manager.
It’s a common misconception that C/C++ SBOMs require a package manager. This isn’t the case. The problem with package managers is that they’re shoehorning the language retroactively into something it was never designed to do.
Emerging solutions that provide build-time analysis can generate a SBOM for C/C++ without requiring a package manager. These build-time solutions are ideal for real-time and embedded software.
4. SBOMs give attackers a blueprint of your software.
Guess what? Attackers already have a blueprint of your software with or without an SBOM. While SBOMs do provide detailed information about software components, attackers already know, for example, what open-source components are in software products and available to leverage. That said, sharing SBOMs in a secure way is easily done, and the benefits of better vulnerability identification and mitigation outweigh the potential risks.
5. SBOMs are needed strictly for compliance reasons.
While the FDA, PCI-DSS, and the EU’s Cyber Resilience Act have introduced SBOM-related requirements, compliance isn’t the only driving factor for SBOM generation. In addition to the many security benefits, SBOMs increase transparency with customers by making it much easier to address security issues as they arise. SBOMs improve the ability to disclose vulnerabilities and then update customers with mitigations, building trust alongside security.
6. Nobody reads an SBOM.
Operators and asset owners do read SBOMs, and they will start asking for them more in the days ahead. CISA, as part of its Secure by Demand initiative, calls on software buyers to explicitly demand security as part of the procurement process, including requesting a software bill of materials. By reading SBOMs, operators and asset owners will be able to better understand vulnerabilities across their OT networks and operational infrastructure.
7. Suppliers are resistant to providing SBOMs.
Some suppliers may be resistant to providing SBOMs or only supply them when asked. However, forward-thinking suppliers see SBOMs as an improvement in their customer service. Not only do SBOMs allow for them to be more transparent with customers and show their commitment to software security, they also enable them to communicate specifically about software risks and plans to mitigate.
8. SBOM creation is labor-intensive.
There are many different ways to generate SBOMs. Yes, manually building an SBOM is time-intensive, but it’s not necessary to do so. Automated tools exist that streamline the process. Build-time SBOMs, for example, are automatic and don’t slow down build tools and processes. As a result, it’s easy to integrate SBOM generation as a standard part of your overall process.
9. Only EU companies need to generate an SBOM for compliance.
While the European Union is ahead of the game in terms of regulatory requirements around SBOMs, the U.S. isn’t exempt. In 2021, President Biden issued Executive Order 14028 on “Improving the Nation's Cybersecurity.” Part of the EO is mandated SBOM creation for organizations selling software to the U.S. federal government.
Following the EO and other industry guidance not only allows for organizations to meet that expectation, but it also provides a sure way to boost your security posture.
10. Sharing SBOMs has no benefit.
To date, customers lack clarity on their suppliers and their software development practices, leading to potential unforeseen risks introduced through the software supply chain. SBOMs open up the door for improved communication between suppliers and customers, encouraging a more efficient way to not only disclose new vulnerabilities, but provide updates on mitigations for existing vulnerabilities.
11. No companies are generating SBOMs.
To the contrary, great tech companies like Critical Software, Lockheed Martin, Schneider Electric, and Vertiv, along with hundreds of others, are already generating SBOMs. What these companies understand is that SBOMs are a valuable tool for enhancing software security, letting us better protect the products, embedded systems, and critical infrastructure that keeps the world operating.