Aki Eldar is the CEO and co-founder of Mirato, provider of an AI-enabled third-party risk management (TPRM) intelligence platform.
Software supply chain attacks show no sign of slowing and can have devastating consequences. These attacks can expose organizations and their customers to greater risk when an attack on a third party’s software supply chain unknowingly compromises their systems.
Many proprietary software applications are built on third-party code and open-source software to keep up with rapid innovation. While this is highly beneficial, it also introduces additional risks, increasing the need for new methods to quickly identify erroneous code that can be exploited, as well as malicious code.
According to the 2021 Open Source Security and Risk Analysis report (registration required), 84% of codebases audited included one or more open-source vulnerabilities, 60% had high-risk vulnerabilities and 65% contained open-source software with license conflicts.
Recent incidents, such as the attacks involving SolarWinds and Kaseya, demonstrate the potential impacts of malicious code, while Log4j serves as an example of the ramifications of incorrect code. The hack involving SolarWinds was partially due to software being compromised by malicious code, infecting a product that was then distributed to customers.
Log4j is a piece of software that is found within systems that power a wide range of products and applications. Because of faulty code, it contains a vulnerability that bad actors can leverage to take over computer servers and cause widespread damage.
The effects of these types of cyberattacks and coding flaws can extend beyond the primary user’s system—often into their third parties’ systems and beyond—making the impact exponentially worse.
The software bill of materials helps to provide more visibility into the software supply chain.
Better visibility into the software supply chain has become essential, including understanding the “ingredients” contained within a software package. This has led to new mandates in highly regulated industries that require software vendors to generate a software bill of materials (SBOM). One example is the Executive Order on Improving the Nation’s Cybersecurity issued in May 2021. In addition to helping mitigate the risk of software supply chain attacks, the benefits of SBOMs potentially include reducing cost, license risk and compliance risk.
In highly interconnected industries, such as banking and financial services, a third party utilizing a software package containing a widespread vulnerability could increase operational risk by causing disruptions, such as a downed system. For instance, suppose an incident transpires that affects a commercial or open-source software package supplied by a third party. A bank would have to be able to identify its potential impact immediately. SBOMs can be used to identify vulnerable software quickly, assess its usage and understand the risk involved.
Unfortunately, banks rarely have one view of third-party risk because it requires much manual effort to pull information and monitor it for risk. Today, many banks do not have an efficient method to screen thousands of software ingredients in documents dispersed throughout the organization on an ongoing basis. In this case, a response would occur after the breach is discovered—at that point, the damage is done.
Continuous risk assessment and analysis of the SBOM helps organizations understand the potential impact of software ingredients.
There are multiple ways to understand whether an organization’s third parties utilize a specific software package. This information is typically collected during the vendor onboarding process and may be included in questionnaires, open-source lists or other documents, such as business continuity plans. The most rudimentary method is to have someone physically monitor those lists manually to flag known vulnerabilities.
Another way is to compile all collected SBOMs or software package lists onto one storage device, such as a hard drive. Then, when a potential vulnerability like Log4j is detected, a text-based search can be performed to uncover the key term of interest.
However, a potential problem with these methods is the lack of proactive notifications, as the search is being performed reactively after an event. A larger problem is that a software ingredient may be included in thousands or tens of thousands of packages and may fly under the radar in a manual search. It also takes a long time to find them—sometime weeks—and requires many people to do so.
Risk practitioners should instead think like software developers by adopting a “shift left” approach—a practice used to find and prevent defects early in the software delivery process—and apply that concept to third-party risk management. This enables risks to be discovered and mitigated as early as possible. Whereas the previous methods move from the right of the development curve and implement protections after the event has occurred, the shift left approach involves continuously performing risk assessments to prevent the risk.
Third-party risk management (TPRM) intelligence technology, powered by artificial intelligence and natural language processing, is one way to help continuously monitor SBOMs and minimize risk. Instead of managing disparate spreadsheets or programs with manual processes, TPRM intelligence allows information to be compiled into a central system for continuous monitoring and mitigation, enabling near real-time alerts about the potential impacts of emerging threats based on concentration risk analysis—ultimately helping to ensure software supply chain attacks are prevented instead of defended.
AI can uniquely handle and evaluate unstructured data, allowing TPRM intelligence solutions to extract data from many sources to create actionable insights about an enterprise’s risk exposure to potential software vulnerabilities. TPRM intelligence also includes the capability to incorporate added data sources that provide more information, including cyberthreat intelligence, attack surface discovery, negative news announcements and more. As a result, CISOs, CIOs or risk managers can more easily monitor risk events and their possible effects across the entire software supply chain.