The vast majority of software today is built from open-source components, or elements that were written by people outside the organization. By definition, this opens companies up to cyber risks because all open source components have different track records of being safe.
“In many cases, large organizations don’t know how safe their software is because there’s no tracking system for the security of the open source components they use,” said Charlie Jacco, Principal, Cyber Security. “Bad actors can easily target open source libraries. Executives need to take steps now to hedge against very real attacks tomorrow.”
Jacco argues that companies are often hampered by silos that make the process of reconciling risk more complicated. Specifically, the people who build the software are in the CIO organization, while others that secure the software sit in the office of the CISO. Each has different missions and measure success differently. The CIO builds software quickly on tight deadlines, sometimes sacrificing security for speed to market. Meanwhile the office of the CISO may not have the budget or resources to influence the CIO organization to put the right protocols in place.
To complicate things further, companies face third party risk, when organizations in their supply chain are open to attack as well.
But what is the answer?
Advice to companies
For a start, companies should manage risk by being intentional about the type and amount of open-source software they are using to build applications.
But that’s not always possible. Clients often wonder what else they can do.
KPMG tells companies that they can better manage risk using Software Bills of Materials (SBOMs). Reminiscent of a bill of materials in traditional manufacturing, the SBOMs are like a nutrition label of software components. They list what open-source components are in a piece of software, enabling companies to know what is in their environment and how out of date it may be – crucial for scenarios when there’s an attack on commonly used open source components like Log4J.
“We recommend that all companies have SBOMs of all the software they are building and consider require SBOMS for the software they are buying. It makes securing a company’s software portfolio much easier,” said Caleb Queern, Director, Cyber Security.
With value for so many organizations, clients often ask, “How and where do we start?”
KPMG advises that the first step to utilizing SBOMs is generating them which can be done using developer IDE plug-ins, software composition analysis tools, and using tooling available in the build pipeline.
After the SBOM has been generated, the information needs to be distributed effectively. Companies might consider forwarding them to their organization’s data lake or knowledge management system. Downstream consumer teams in the security organization or elsewhere can then pull this information from the central repository to ensure they have up-to-date and accurate information.
According to Queern, companies should start small, segmenting the adoption of SBOMs across high priority application teams, rather than a sudden mandate that SBOMs be created by every application team across the organization.
“Ultimately SBOMs will enable businesses to confidently go forth to innovate and grow their businesses,” Queern said. “Having the transparency provided by SBOMs enables informed decision making for prioritizing security investments across an application portfolio.”
To speak to Charlie Jacco or Caleb Queern, contact Melanie Batley.