Visibility into the software that organizations and their suppliers use has become a cornerstone of supply chain security. That's the bottom line from a recent panel discussion among experts at a webinar sponsored by the IT GRC Forum, which focuses on governance, risk management, and compliance.
During the forum, titled "Prevent an SBOM F-Bomb: Streamlining Compliance in Your Software Supply Chain," Brian Fox, co-founder and CTO of Sonatype, said that pretty soon, every software provider is going to be expected to give customers an accurate software bill of materials (SBOM).
Charlie Jones, director of product management for ReversingLabs, added that gaining visibility and control over the software supply chain is no longer optional. "It's firmly ingrained in legislation, regulation, and now in third-party contract templates." And the problem is not only facing software development organizations. Buyers of software are on the hook as well, he said.
"So it's important to think about how you're going to provide demonstrable evidence to an auditor, to a regulator, to a third party that you know what's in your software. And more importantly, you need to know whether it presents a risk to your business or your customers, regardless of whether you built it or bought it."
—Charlie Jones
Here are key takeaways from IT GRC Forum webinar on SBOMs and software risk management.
[ See Special Report: Why You Need Deep Visibility and New Controls for the Software You Build or Buy ]
Software supply chain visibility is essential in the modern era
Jones said that buyers today expect visibility into their software that traditionally they never had. “They were forced to inherently trust that their vendor was using secure development practices."
The problem is that the foundation of that trust today is the security questionnaire, which "doesn't really provide a ton of true assurance" because it relies on the vendor to tell you how secure they are, Jones said.
And while there's certainly no shortage of technology to perform testing on software, Jones added, it likely requires access to source code, something a vendor would never give to an enterprise. However, the barriers to visibility are starting to come down, Jones said.
"We're starting to see this kind of seismic shift in the way that third-party software risk is being managed," he said. "Now you have the emergence of this new principle that's being put forward by CISA [the U.S. Cybersecurity and Infrastructure Security Agency] to reflect the current state of the market which is called Secure by Demand."
—Charlie Jones
Jones said this shift is representative of the increased demand for "transparency of the makeup and security of third-party software from those organizations who rely on it every day."
But organizations don't need access to source code to obtain visibility into the software they use. They can now go beyond traditional application security testing (AST) tools and gain the visibility they need through modern tools, including binary analysis, that are recommended by the Enduring Security Framework (ESF) working group.
"So long as you have access to the actual software package that you consume and deploy in your environment, you can find out what's in it and you can understand whether it poses a risk to your organization. And that's so powerful because it allows you to essentially shed this dependency that you used to have on a supplier."
—Charlie Jones
Get back to basics for software security
Nevertheless, gaining visibility into commercial software packages, can be an overwhelming experience, Jones said.
"The volume of software that large enterprises rely on today is enormous. Software underpins every single business process. I just talked to an AppSec professional of a very large, 30,000-plus-employee global organization, and they were estimating they had 15,000 unique apps deployed within their production environment."
—Charlie Jones
And the real number is probably closer to 50,000 unique applications if software downloaded through non-approved and non-sanctioned channels is included, Jones added.
The lesson learned: "[The] volume of applications is far too high to oversee with manual methods," Jones said.
He recommended that organizations get back to basics by using a risk-based approach, focusing on those applications that are most critical to their business, tying them to important business services, then leveraging automation wherever possible:
"My advice is always start by targeting those vulnerabilities that are most likely to have an actual business impact and materialize into attacks, vulnerabilities which have a known exploit instead of those that are just discovered and hypothetical in nature, those where there's evidence of them being actively exploited in the wild."
Jones recommends consulting CISA's Known Exploited Vulnerabilities (KEV) catalog, which lists vulnerabilities known to have been exploited in the wild. Additionally, the Exploit Prediction Scoring System (EPSS) can be used with KEV and the Common Vulnerability Scoring System (CVSS) to improve effectiveness. "To me, it's all about prioritization, focusing on what's fixable and what presents the most risk to your business," Jones said.
SBOMs start at home
A critical tool for gaining visibility into software is the SBOM. Sonatype’s Fox said organizations need to start their SBOM journey with their own first-party software.
That has largely been a solved problem for a long time, but not enough organizations are doing it, as evidenced by the collective freak-out when Log4Shell happened, Fox said. Log4Shell is a significant security flaw discovered in the Log4j library, a popular Java-based logging utility used in many applications and services. The vulnerability, identified as CVE-2021-44228, was publicly disclosed in December 2021. "So many organizations literally had no idea what their own dependencies were in their applications," he said.
"The sad reality is, as we sit here today, we're almost three years post-Log4Shell, and I can tell you for a fact that 30% of the versions of Log4j that are being downloaded every day are of those versions that are affected by Log4Shell. So at least 30% of the organizations out there have not even responded to the biggest, most high-profile issue in our industry after three years."
—Brian Fox
The only conclusion from that is that they don't have a good understanding of what's inside their software, he continued. "The software bill of materials by itself doesn't solve a lot of problems, but the act of being able to produce it accurately sets you up to have that inventory across your organization so that you can respond to the next problem."
Fox said that if an organization doesn’t have good visibility into its first-party software, it will be unable to meet industry and government standards coming down the road. “For the parts of the stack that you're building on, that you acquire elsewhere, if you don't have good visibility, you're going to have a hard time complying as well because you need to bundle up everything into your SBOM," he said.
"Another challenge in the short term is going to be validating that the SBOMs that you receive are accurate. Right now, I wouldn't trust at face value most of the SBOMs I receive just because of what I see in the industry. So having tooling and ways to trust but verify is going to be very important in the short term."
—Brian Fox
Navigating software supply chain compliance is key
During the forum, the audience was polled on some key security questions. One of those polls asked audience members what they are prioritizing when it comes to navigating the complexities of software supply chain compliance. One out of three members (33%) are prioritizing adhering to industry standards, such as PCI-DSS 4.0, while one out of four (24%) are prioritizing using tools and techniques to streamline compliance processes and reduce risks.
The risks of PCI noncompliance can be significant, Fox noted, and include fines imposed by credit card companies in the hundreds of thousands of dollars a month; a costly PCI audit; and a prohibition against taking credit card payments.
Fox pointed out that as compliance standards become more generally accepted, they can form liability regimes that define what should be considered reasonable due care. "If every standard basically says you need to have a bill of materials and you need to track what your dependencies are, and you're not doing it, a case could be made in a lawsuit that you were failing to take reasonable steps to avoid gross negligence," Fox explained.
"The other aspect of this that we see time and time again is that leaders tend to overemphasize or overestimate how effective they actually are at solving this problem."
—Brian Fox
Gain confidence in your risk-mitigation strategies
Another poll question asked how confident organizations are in their current strategies for mitigating risk across their supply chains. Nearly half the audience responding to the question (47%) said they are "somewhat confident" in their current strategies. "That sounds to me like people sitting on the fence a little bit," observed the webinar’s moderator, Colin Whittaker, founder and director of Informed Risk Decisions.
Forum participant Andrew Dorminey, a GRC specialist and solutions engineer at OneTrust, said that was surprising to him. "I typically would see more on the neutral side," he said.
More than a quarter of the audience (27%) are neutral about the question, while 11% are not very confident or not very confident at all in their strategies for mitigating risk, in contrast to 13% who are very confident in their strategies.
The forum's audience was also polled on which controls are the obligation of the software buyer to implement. Nearly two out of five (42%) said sensitive information protection, software license compliance, and application hardening were all controls that are the software buyer's responsibility to implement. Very few members of the audience — 6% — chose the option of none of the above.
ReversingLabs' Jones said that does not align with the expectations of the industry. "Essentially, you have no one or very few saying none of the above. That can actually serve as a realization that people are maybe overextending their control obligations and spending time and resources for something they aren't really expected to manage," he said.
"Things like license compliance, for example, would be very difficult for a buyer of software to manage. The industry is expecting that of the publisher instead."
—Charlie Jones
Software supply chain threats: How big, how bad?
The forum also asked its audience about the origin of threats to their software supply chain. An overwhelming number of audience members (84%) said the biggest threats to their software supply chains come from third-party or open-source software.
Although only 8% of the respondents considered firmware a big threat to their software supply chains, participant Paul Asadoorian, principal security evangelist at Eclypsium, cautioned organizations about that threat. "I think a lot of organizations don't give a high enough priority to updating firmware and updating their infrastructure components,” he said.
Asadoorian said that to make sure you incorporate in your vulnerability management and patching programs the things that live in the shadows: network appliances, components, and firmware. “Identify those in your environment, fix the issues that are there, and collect data so you can detect and respond if there is an attack in these areas,” he said.
"Despite what some might believe, [network appliances] don't come from the vendor secure by default all the time. You have to apply updates and manage the security of those appliances, even though they come in kind of a pre-installed package for you."
—Paul Asadoorian
OneTrust's Dorminey urged organizations to attain an overall understanding of their operational environments, from both an internal and external perspective.
“You need to create dynamic processes to understand the risk that you need to react to and have proper protocols, controls, and methodologies in place to get in front of supply chain risk and mitigate it as much as you can and just create an environment that enables you to take action instead of being the subject of one of these attacks."
—Andrew Dorminey
To learn more, see the full IT GRC Forum replay, complete with audience questions.
