Software Bill of Materials (SBOM) have grown in popularity in the past year as a means to help curve the impact software vulnerabilities in open-source technologies have been having on organizations. The concept itself is not new, its foundation are found in other industries; most notably traditional supply chain management. The biggest difference being its adaptation to software.
Tackling Supply Chain Vulnerabilities
The need for SBOM’s is manifesting out of a need to gain better control of software supply chain vulnerabilities.
There is no better recent example of a supply chain vulnerability than with Log4J and the chaos that created. Go back a bit further, and you stumble on one of the biggest breaches of sensitive user information with the EquiFax that was made possible by a vulnerability in the Apache Struts Framework. Then there is the developer that was frustrated with the establishment and decided the best way to handle that was to purposefully corrupt his libraries and sending website using those libraries into an infinite loop.
These issues are being categorized as vulnerabilities in the software supply chain and have highlighted how little organizations know about the software they depend on.
It’s become a big enough of an issue that working groups have been created between Federal and Private industries to tackle the problem. It also brought about Executive Order 14028 (Improving the Nation’s Cybersecurity) in the United States which has a heavy emphasis on securing software supply chains, and SBOM’s are becoming a critical piece of that strategy.
Open-Source CMS’s Critical to Software Supply Chains
Open-Source Content Management Systems (CMS) are an especially important part of this conversation, or at least should be. Not only are they part of the bigger supply chain in an organization, they themselves have their own supply chains to be considered.
Site note: It was disappointing not to see representatives from the more popular platforms like WordPress, Drupal, Joomla!, Magento and others included in the private / federal security summit in 2021 but hope that change in the future.
These platforms are no different than some of the system level applications like NGINX, Apache, OpenSSL, Linux, and so many other open-source technologies that make up the web.
All the open-source CMS applications in the market are highly extensible by design. They offer its users rich marketplaces (i.e., plugins, modules, extensions, themes, designs) that facilitate the creation of b eautiful dynamic online spaces. That same extensibility, however, continues to be its weakest link in the security chain. This weakness exists because of the lack of visibility and awareness. While SBOM’s don’t solve the problem directly, they lean into the problem and work towards becoming a piece of the solution.
SBOM Frameworks Exist Providing a Foundation To Build From
I think it’s important that communities start having this conversation internally and work towards defining what that standard will be, before its defined for them.
Thankfully a framework has already been defined by the Open Web Application Security Project (OWASP) coined the CycloneDX project. It provides a foundation from which communities can build on, and it also presents an opportunity to create a joint initiative between different Open-Source CMS communities to create a SBOM adaptation for their communities and the consumers of their platforms.
This will become a reality for open-source CMS’ applications sooner rather than later, if it hasn’t already, especially if these platforms are being used in the Enterprise and in Government environments.
Embracing SBOMs as a community can have a big role in upgrading the technologies security maturity to better align with the greater Information Security community, while having the added benefit of improving consumer confidence.