The research firm Gartner is warning software development organizations that they should be prepared to provide their customers with software bills of materials (SBOMs) if they want to remain competitive in their software markets.
"An SBOM is foundational to managing the complexity and securability of modern software deployments. And product leaders must meet the growing demand for technology, best practices and solutions to support the delivery of SBOMs," Gartner analyst Mark Driver wrote in a research report titled Emerging Tech: A Software Bill of Materials Is Critical to Software Supply Chain Management.
Gartner believes that by 2025, 60% of organizations procuring mission-critical software solutions will mandate SBOM disclosure in their license and support agreements, up from less than 5% in 2022.
However, Driver cautioned in the report that SBOMs are not a panacea.
"They are only as useful as the processes and tools implemented to process, analyze and leverage the information they contain. Additional tools and techniques, such as software composition analysis (SCA) and code signing, are also necessary elements of a complete software supply chain management effort."
—Mark Driver
Here are three key takeaways from the Gartner report.
[ Get a free SBOM and full supply chain risk analysis report ]1. Get ahead of the demand for SBOMs
In preparation for the new SBOM environment, the report recommends software providers meet the minimal requirements for SBOM disclosure as soon as possible. When preparing SBOMs, Gartner added, they should be tailored for the demands and dynamics of the industries for which they're being prepared.
It also recommended that software providers get ahead of demand.
"Even if you aren’t getting requests for SBOM disclosures today, create a full inventory of your product’s internal software assets."
The report also advised providers to categorize each of their assets as a "trade secret" or "fully disclosed." It explained that a provider may decide to exclude trade secrets from an SBOM or reveal them, but protect them through a nondisclosure agreement in a customer licensing agreement.
Creating a full inventory of all external dependencies is also recommended in the report. Dependencies subject to a service-level agreement (SLA) with an asset provider should be categorized as "commercially supported." Any SLA for the dependency should require full SBOM disclosure.
Dependencies without a contractual SLA should be categorized as "self-supported," the report advised. In addition, a self-supported SLA should be created for those dependencies. That SLA should include discovery and tracking of a complete SBOM.
2. Remove 'security through obscurity'
The report also recommended that providers of software assets ensure they have the capability to create a complete SBOM of their self-developed assets. While meeting the minimum demand from customers for SBOMs, it added, providers should look beyond meeting bare essentials and build strategies to use the SBOMs to create value.
Among the methods for creating value cited in the report were tying SBOM delivery to broader security opportunities, such as deeper integration into DevSecOps practices, and expanding and evolving SBOM technology in a way that ties it to long-term product roadmaps.
"Don’t stop with an SBOM. Keep in mind its purpose is to provide insight into the assets that make up a software solution."
"You must work diligently to correct the security and quality issues discovered through the SBOM disclosure to avoid cybercriminals using it for their own attack vector strategies," he continued.
"In other words, an SBOM removes the capability of 'security through obscurity.'"
3. Modern software development requires a new approach
Driver noted in the report that Gartner estimates 40% to 80% of the lines of code in new software projects come from third parties. "Most of this external code comes from myriad open-source projects; the remaining proprietary code comes from suppliers that provide little or no transparency to its status or condition. To complicate things even further, many open-source software (OSS) dependencies are undermanaged and understaffed."
In a perfect world, there would be minimal need to share SBOM information. "Every contributor along the supply chain would provide guarantees of the quality and security of their components," he wrote. "These guarantees would propagate from one link in the supply chain to the next. Updates would be posted immediately, and dependencies would be propagated across the supply chain automatically."
But the industry operates in an environment where providers along the software supply chain often fail to do what they should do, he wrote. "[One] can also argue that they have traditionally lacked the tools to do this even when they’ve tried."
"In addition, within a technology ecosystem heavily dependent upon open-source software, many components lack a sufficient commercial source of support altogether. As a result, 'software hygiene' practices vary broadly from one supplier to another; the rigor of practices at each node in the supply chain varies from robust to nonexistent, and this situation changes constantly over time as well."
The report predicted that over the next three years, product leaders will be challenged to keep up with the evolution and general direction of SBOM technologies, tools, and best practices. They must do this while avoiding or minimizing potential dead ends, missteps and the hit-or-miss nature of discontinuous innovation along the way, it added.
The report also forecasted that the state of the art for SBOM initiatives will evolve and improve continuously from 2022 through 2026, but the most impactful innovations are unlikely to reach mainstream adoption before 2025.
SBOMs are now essential
Driver wrote in the report that SBOMs were becoming essential for software development organizations. "The requirement to supply a complete, accurate and up-to-date SBOM for your software solution will be a mandatory element of the majority of client engagements within the next three years," he wrote.
"Product leaders unable or unwilling to provide SBOM disclosure will find themselves increasingly pushed out of competitive opportunities. Many technology and service providers will struggle to deliver necessary SBOM requirements because they are unable to accurately discover and track both internal and external dependencies."
