A Software Bill of Materials (SBOM) is a list containing an inventory of software components, licenses and code dependencies in an organization. SBOMs can be an effective means to improve the security of software products and reduce the risk of vulnerabilities by providing visibility into all software components used and their security status. Organizations utilize SBOMs to enforce security standards, recognize malware, and enable minimum quality levels for software. In May 2021, President Biden issued an Executive Order on Improving the Nation’s Cybersecurity that specifies requirements for SBOMs. Other nations around the world have adopted similar policies.
The Major Problem of SBOM
The major problem with the SBOM is, well, it’s just a list. Like all lists, their information can be wrong, outdated or tampered with. The information in an SBOM isn’t guaranteed to be correct or that it is built according to the software user’s specification.
Furthermore, because most SBOMs are stored as simple text files or as entries into a database, they are typically not tamper-proof. Therefore, they can be easily manipulated by vendors or teams who have access to it, or attackers. This makes them useless unless they’re managed properly from their inception – and then maintained throughout development so they’re always accurate and up-to-date.
In other words, the SBOM creation, updating and reviewing lifecycle must be tamper-proof and protected with strong cryptographic enforcement.
Need for a Tamper-Proof, Verifiable SBOM Central Store
A central, tamper-proof store for SBOMs is therefore required to allow companies to manage all of their assets from one place instead of having multiple systems for each asset type. A central store will also make it possible to integrate data from other systems into the SBOM so that assets are updated regularly as needed.
SBOMs Must Be Actionable and Enforceable
To have an SBOM that is actionable and enforceable, you need to do more than just store the list of components. You also need to use it as part of your development process, which will make it possible to do things like the following:
- Run vulnerability scans against the list of components to find out which ones have security vulnerabilities. Importantly, this can change as new vulnerabilities are discovered, so this needs to be an ongoing process.
- Gain insight into which applications are using what libraries (and how).
- Understand the usage of the many different open-source licenses and avoid license infringements and copyright claims.
- Quickly discover which software applications use any recently discovered malware.
To effectively manage the many SBOMs produced during the software development life cycle, it makes the most sense to store SBOMs in a central store that is maintained in a tamper-proof database. This central storage for all SBOMs must be maintained on an ongoing basis by the development team and should be made accessible to users of the software, or customers, for their own verification.
Only once you have a tamper-proof, central storage for SBOMs, can you harness the security and insight from having built them.
Conclusion
As a result of the regulations requiring SBOMs, we can expect software security to improve. However, the real challenge lies in enforcing regulations and ensuring that companies comply with their requirements. The solution lies in centralizing data collection and analysis so that vulnerabilities can easily be identified before hackers or other malicious actors exploit them.