There’s a lot of focus these days on the security of open source software that is shining a spotlight on how dependent organizations have become on code created by third-parties that finds its way into multiple applications. Most of that attention is on how to build more secure open source software and patch vulnerabilities as quickly as possible once they have been disclosed.
MSPs have the tools and expertise
As noble as those efforts are, however, the major issue that still needs to be addressed is how open source software is consumed. Most organizations have no idea what software components have been incorporated across their software supply chain. As a result, when a vulnerability is discovered, there’s no easy way for them to know whether they are impacted or not. That lack of visibility is creating a unique opportunity for managed service providers (MSPs) that have the tools and expertise needed to identify precisely what versions of any given software component is running within an application.
Software bill of materials (SBOM) make it easier to find vulnerabilities
Awareness of this issue is high thanks to an executive order issued by the Biden administration which requires Federal agencies to have a SBOM for every application they employ by next summer. The executive order was issued in the wake of a discovery of a zero-day vulnerability in Log4j tool discovered late last year that is widely employed to create logs within Java applications. Many organizations are still looking for all the vulnerable instances of Log4j that might be running software in their application environment. SBOMs are being required to provide a list of the “ingredients” used to create an application to make it easier to find any component that might one day be similarly affected by a zero-day vulnerability.
Demand for services will only increase over time
Many organizations are unclear as to how many software or components of software are running in their IT environment. Organizations that want to implement a similar SBOM policy as the Federal government are going to spend massive amounts of time cataloging software unless, of course, some other entity is willing to do it for them. The best part about providing that capability is that it’s an ongoing requirement. Every time an application is updated there’s going to be a need to once again verify what components are being employed. Very few organizations are going to want to dedicate resources to that task if they rely on a services provider to do it for them.
SBOMs will undoubtedly play a critical role in improving overall application security. However, having an SBOM is not the same thing as operationalizing it. Organizations are hoping to be able to use an SBOM to decide whether to green light the deployment of an application. The challenge is that what’s in the application may not always match the list of ingredients in the SBOM, so each application will need to be continuously validated.
It may be a few months before demand for some type of managed SBOM services becomes more apparent but MSPs that get started now will soon find themselves providing a capability that large number of organizations will soon find indispensable.
