What You Need to Consider For Managing Third-Party Risk
Managing third-party risk is not a high priority, Forrester data finds. And that’s concerning.
Juggling was a skill that organizations in the public and private sectors found themselves having to learn in the last two years because of the need to deal with new business priorities and strategic initiatives on top of managing lots of new security risks.
Mastering the art of keeping all the balls in the air is something security, compliance and risk professionals must master in 2023. A key part of that is managing third-party partnerships, which organizations depend on to meet their goals and carry out their strategies.
At the same time, organizations must be mindful of the risks that come with working with third parties. Many people won’t soon forget that 2022 started with the continued presence of the Log4j software vulnerability. This is a painful reminder that open-source software is third-party software.
Yet, surprisingly, third-party risk is ranked lower on the list of risk priorities than other enterprise risks, according to Forrester’s State of Third-Party Risk Management 2022 report.
Should You Be Concerned About Third-Party Risk?
Forrester’s data showed that the majority (69%) of enterprise risk management decision-makers surveyed said that a top management priority is improving their ability to identify and address risks from third-party providers. However, when asked about the types of risks that are the main concern for their organization, only 20% identified third-party risk.
The data also showed significant investments are being made in third-party risk management technology, and that having multiple TPRM tools is common. At the same time, many TPRM programs are still managed with spreadsheets. Even among survey respondents whose organizations are self-assessed as having the most mature third-party risk programs, the majority said that their third-party risk program is manual.
Cyberattacks on the Third-Party Ecosystem are Underestimated
Among security decision-makers who reported experiencing a breach in the last 12 monts, 55% said the incident or breach involved a supply chain or third-party provider, according to the report, citing 2021 Forrester data.
Overall, only 20% of ERM decision-makers who revealed that their enterprise had increased risks cited the threat of cyberattacks as a primary driver. But only 9% of respondents in the U.S. attributed increased risk to cyberattacks, compared to 25% in Europe. The attribution was highest among French respondents, at 36%, the report said.
“When factoring that the U.S. has experienced significantly more (3.3x) cyberattacks between 2006 and 2020 than any other country, this appears to be a gross underestimation of the impact cyber has on third-party risk,’’ Forrester said.
Why SBOMs are Critical For Managing Third-Party Risk
The Forrester data make a compelling case for why it is critical that organizations create a software bill of materials (SBOM), which helps provide more visibility in the software supply chain – including third-party components.
There are several benefits of SBOMs, including the ability to reduce costs, and license and compliance risk. But when an SBOM is static, it is limited in scope and requires manual updates, and this may not be ideal for environments that are constantly changing. A static SBOM can also lead to notification delays, which may increase risk.
When a manual search is conducted after an event, a software ingredient may not be flagged, given that there are a vast number of packages to sift through. It requires a lot of time and effort from multiple people.
A dynamic SBOM gives a real-time look at vulnerabilities as things change over time. Deploying a DSBOM automatically incorporates updates whenever changes or additions are made.
A DSBOM also provides context on how software components are dynamically used and executed and is critical for helping security teams determine which components are latent and which are active exploitable threats. That way, remediation efforts can be made on the applicable parts of the organization’s SBOM.
It will likely become a requirement to deploy DSBOMs at some point, but it makes sense to do so now, especially if your organization develops software on a regular basis. For those that have been victims of the Log4j vulnerability, there is no better time to integrate DSBOMs into the SDLC.