We’re Thinking the Wrong Way About Technology Supply Chain Risk

The limits of expertise in managing unpredictable cybersecurity threats

Introduction

In October 2024, Graham “Dingo” Dinkelman, a popular snake conservationist tragically died after being bitten by a highly venomous Eastern green mamba. As part of his conservation efforts, Dingo had a popular YouTube channel and frequently posted videos in which he handled and interacted with the deadly reptiles while sharing his wealth of knowledge and love for the species.

I remember watching his videos with my wife and son and feeling very uneasy when he would do things that, in this non-snake handler’s opinion, appeared absurdly dangerous. Stunts like laying down on the ground near the snake provided little to no margin for error if the snake decided to strike. Yet day after day, Dingo relied on his extensive experience and deep understanding of the behavioral patterns of each species to guide his actions and to keep him safe.

I vividly remember our discussions at the time and wondering out loud, “He obviously knows what he’s doing, but what about all the things that are out of his control? What if the cameraman gets in the way when he has to move? What if he has to sneeze right when the snake comes towards him? What if there is a bit of wet grass and he slips on it? What if the sun peaks through the trees momentarily impairing his vision?” And the ultimate question, “How many times can he do this before something goes wrong?”

We’ll come back to this later.

What are supply chain attacks?

In cybersecurity, a supply chain attack refers to a tactic where threat actors compromise a third-party, for example cloud service providers, software or hardware vendors, and business process outsourcing (BPO) vendors. Instead of attacking a business directly, attackers first exploit vulnerabilities in a third-party supplier. Sometimes a smaller supplier is the path of least resistance into a larger company. Sometimes a commonly used supplier is a gateway into many companies; hack once, compromise hundreds (or more).

Supply chain attacks are not new, but there does seem to have been a recent and significant rise in their frequency and severity. In fact, IBM’s descriptively titled, Cost of a Data Breach Report 2025, indicates that 15% of the data breaches in their study started with a supply chain attack, second only to phishing, which weighed in at 16%. 2025 was the first year supply chain attacks appeared in their report, and to debut at #2 indicates a sudden rise in the frequency of these attacks. IBM also notes that supply chain attacks take the longest, on average, to identify (196 days) and contain (an additional 71 days).

Source: IBM – Cost of a Data Breach Report 2025

Examples

The phrase “supply chain attack” by itself doesn’t paint a great picture of what it is. So, I summarized some of the more famous attacks, as well as some recent attacks to help crystalize the concept and illustrate the incredible diversity of ways that these attacks can happen.

• 2013 – Target Credit Card Breach

In the famous Target breach, hackers reportedly stole login credentials used by Fazio Mechanical, an HVAC vendor, to connect to Target networks. The hackers used the stolen credentials to install data stealing malware on point-of-sale machines.

The malware eventually exfiltrated over 40 million payment cards and personal information of 70 million people.

Total costs, not including the impact to the stock price, approached $300 million.

Source: Krebson Security – Target Hackers Broke in Via HVAC Company 

• 2020 – Solar Winds – Orion

Hackers compromised the source code SolarWinds’ Orion software, an enterprise network monitoring solution. When Orion’s automatic updates were deployed to over 18,000 businesses, the hacker’s malicious code was deployed as well, providing them remote access to victim networks.

Interestingly, in 2024, the SEC charged four of the victim companies for misleading disclosures related to the Orion breach. Each agreed to pay civil penalties:

• • Unisys – $4 million
  • Avaya – $1 million
  • Check Point – $995,000
  • Mimecast – $990,000

Source:  SEC –SEC Charges Four Companies With Misleading Cyber Disclosures 

• July 2025 – Clorox Seeks $380 million in damages from IT provider

According to Reuters, who obtained a copy of the lawsuit, Clorox is suing Cognizant, an IT services company that was retained by Clorox to provide IT help desk services.

“Cognizant was not duped by any elaborate ploy or sophisticated hacking techniques…The cybercriminal just called the Cognizant Service Desk, asked for credentials to access Clorox’s network, and Cognizant handed the credentials right over.”

Reuters reports that, “The 2023 hack at Clorox caused $380 million in damages, the suit said, about $50 million of which was tied to remedial costs and the rest attributable to Clorox’s inability to ship products to retailers in the wake of the hack.”

Source: Reuters- Clorox accuses IT provider in lawsuit of giving hackers employee passwords

• 2024 – XZ Utils Backdoor

In early 2024, a database developer (accidentally) discovered a malicious backdoor in an open-source Linux data compression tool called XZ Utils, which is deeply integrated into SSH, a system protocol for secure remote system access.

The developer, a modern-day digital hero, Andres Freund, noticed a roughly half-second delay when accessing systems via SSH, decided to investigate, and eventually found the backdoor. The backdoor would have allowed hackers to secretly log into millions of infected Linux systems, which power most of the Internet’s server infrastructure.

The infected library was already integrated into development versions of major Linux distributions and was weeks away from being released into Ubuntu 24.04 LTS. Ubuntu is the most popular Linux distribution.

The vulnerability earned a rare 10.0 CRITICAL severity rating. The attack required the malicious developer to build an online reputation as an open-source contributor, gain contribution rights to the XZ Utils source code, and develop an ingenious way to embed and hide the backdoor in the software. As a result, most analysts think it was the work of a nation state.

Officially, we can categorize this one as a near miss, but it is astonishing just how narrow a miss it was and how catastrophic the result would have been had it not been caught by an intrepid developer. It also makes you wonder if there have been similar attacks that have been successful that we just haven’t noticed yet.

Source: NIST- CVE-2024-3094 Detail

• 2024 – Polyfill.io DNS Takeover

Background – How Polyfill works

Whenever you visit a website, there’s a virtual guarantee that your web browser is downloading JavaScript code, and it’s highly likely that some of that code is served by third-party content delivery network (CDN), both of which are totally normal. JavaScript is the language of the web, and it provides the interactivity that we enjoy on websites and elsewhere.

With the passage of time, JavaScript has improved and new language features have shipped. However, when old web browsers try to run modern JavaScript, website user interfaces do not function.

Enter Polyfill.io. In short, the goal of Polyfill was to automatically fill the functionality gaps between a user’s browser and the code on the website when the user visits the website. Polyfill allowed developers to use the more modern, developer friendly JavaScript functions without breaking the website for users with older browsers. Very helpful!

The Attack

In 2024, Funnell, a Chinese company purchased the polyfill.io domain name, which gave them control over what code was served to browsers through the Polyfill CDN. They added their own malicious code that stole user browsing data (such as data entered into online forms) and redirected users to scam websites.

Impacted company websites were perfectly fine one day, compromised the next, and without the threat actor ever directly attacking company servers.

Source: Qualys Community –Understanding the Polyfill.io Supply Chain Attack and Its Impact 

• 2025 – Salesloft AI Chatbot Disaster

Salesloft provides an AI chatbot called Drift that integrates with Salesforce. Salesloft customers, like Google, Cloudflare, and others, gave Drift access to their Salesforce data, which allowed the chatbot to provide relevant information to the chatbot users.

Attackers reportedly compromised Salesloft’s GitHub account, which is where they store and manage the Drift source code. Attackers leveraged that access to gain access Salesloft’s Amazon Web Services (AWS) environment from which they stole the access keys used by Drift to access companies’ Salesforce environments. In total, over 1.5 billion records were stolen from 760 organizations including prominent tech giants like Google, Cloudflare, SentinelOne, Zscaler, and Palo Alto Networks.

Source:  TechCrunch – Salesloft says Drift customer data thefts linked to March GitHub account hack

• 2025 – NPM Mayhem

npmjs.com, the world’s largest repository of open-source code libraries, is used by over 17 million software developers across the world. In September alone, npm was successfully attacked twice. One of the attacks was a self-propagating malware called Shai-Hulud, so named after the giant sandworms in Frank Herbert’s Dune universe. It tunneled its way into roughly 700 software developer libraries, which were downloaded billions of times by developers and automated build systems. Among the effects, attackers were able to steal over 400,000 highly sensitive authentication tokens, such as those that allow privileged system-to-system communications. Months later, as of the time of this article, new methods to bypass npm’s fixes have been discovered and remain unpatched.

Source:  Bleeping Computer – Hackers can bypass npm’s Shai-Hulud defenses via Git dependencies

• 2024 – CDK Global

15,000 automotive dealerships were forced to pen and paper after CDK systems, including their dealer management systems, were disabled in a ransomware attack. The outage lasted for three weeks and damages exceeded $1 billion. CDK reportedly paid the $25 million ransom.

Source: Cyberscoop – Wallets tied to CDK ransom group received $25 million two days after attack
Source: PSM – Understanding the CDK Cyber Attack: What Happened and What Businesses Can Learn

• 2025 – Discord

The service desk software used by Discord, the world’s largest structured community chat platform, was breached by attackers who were able to obtain access credentials from 5CA, the company to whom Discord outsourced service desk operations. Hackers stole 1.5 terabytes of support data, including images of 70,000+ government IDs. Some security experts believe the data is likely to be a treasure trove for predators to target minors.

Source: Geek Blog – Discord confirms 70,000 government IDs exposed in customer support data breach

• 2025 – Notepad++

The extremely popular and free text editor was compromised after attackers gained access to the online update system. Users who thought they were just updating their software to the latest version were redirected to the hacker’s servers and were given a malicious payload instead.

The Notepad++ developer, Don Ho, wrote that it was his hosting provider (i.e., a vendor of his) that was compromised, rather than a direct compromise of the Notepad++ application. He further claims that it was the work of a nation state level attacker.

Source: Notepad ++ – Notepad++ Hijacked by State-Sponsored Hackers

Examples summary

Supply chain attacks have enormous diversity in how they can occur. In this short list, we see examples of:

• Service provider personnel being targeted.
• Nation state attacks on deeply embedded server code.
• Malicious corporate takeovers.
• Compromised source code delivered through automatic updates.
• Compromised source code delivered through web browsers.
• Compromised source code spreading to more source code.
• And service providers failing to protect the secrets used to integrate their systems with customer systems.

The ignored supply chain risk

Vendor risk management, third-party risk management, supply chain risk management are all terms used to describe the policies and procedures used by organizations to analyze the risk of external services and technologies. Although there are distinctions between them, for most companies, at an extremely high level, the process is:

1. Identify vendor/software/component etc.
2. Analyze risk (review SOC reports, security questionnaires, etc.)
3. Approve or Deny
4. Periodically (at least annually) reassess risk.

This process is perfectly reasonable. Of course it makes sense to analyze the risk before integrating a vendor or technology into your enterprise IT environment. The “trust me bro” model has never worked. The AICPA’s Trust Services Criteria (TSC), which are the foundation of SOC 2 reports, start with “trust” for a reason. User organizations need a basis to trust the security of their service providers, and the rigor of a properly executed SOC 2 examination can be a foundation for that trust.

But no amount of third-party risk management can eliminate all risk. Said another way, each vendor or technology in an enterprise IT environment adds some amount of risk that cannot be controlled or mitigated, regardless of the amount of vetting we do.

In a recent presentation, I put it this way:

As organizations integrate more third-party technologies into their enterprise IT environments – the cumulative likelihood of a successful supply chain attack asymptotically approaches certainty.

And that is the ignored risk. Vendors are largely treated one by one in a vacuum. Organizations do not account for the aggregate risk that accumulates with each new vendor or technology. Nobody is taking a step back and asking: Gee, there’s ten different third-party integrations that require privileged access to our systems, is that too many? Do our employees really need five different web browsers? Why do we have three different Linux distributions in our server infrastructure? How many SaaS providers with sensitive data is too many? Is the value from that chatbot really worth the added risk of it having access to our entire CRM?

It’s like going full Cookie Monster on a sleeve of Chips Ahoy! and only counting the 53 calories in the last one you choked down before your wife catches you.

How many cookies did you just eat?

nom nom nom… One!

I was discussing this with my colleague and truly brilliant cybersecurity professional, Jon Derrenbacker, and he reminded me that – Every company has some percentage chance of a data breach each year. Each third party that holds your data compounds that risk. Two copies of your data mean twice the exposure; ten SaaS platforms mean ten times the exposure. Nail on head. The more vendors/technologies with access to your systems and data the greater the likelihood of a successful supply chain attack. Worse yet, you don’t know who, you don’t know when, and you don’t know how. Failure to account for this uncontrollable and unpredictable risk just doesn’t make sense.

Back to Dingo

I remember wondering one day why I hadn’t seen a new Dingo video in my YouTube feed. A quick search later and I found the news.

Dingo was a highly experienced snake handler, and he used that experience to reduce the likelihood of any one interaction resulting in a lethal bite to an acceptably low level, and certainly far lower than if I were trying to interact with a snake. However, given the number of interactions, it turned out to be just a matter of time before some uncontrollable and unpredictable variable squeaked itself into a situation, and it cost him his life, his wife a husband, and his children their father.

The admittedly grim corollary to supply chain risk is obvious, and although it doesn’t often create a mortal danger in the same way as snake handling, the risk is actually worse. In Dingo’s case, the risk actually was isolated to each interaction, i.e., the risk of his past interactions did not aggregate to create additional risk at the time of the lethal bite. Sometimes called the infinite monkey theorem, Dingo’s case shows simply that given enough trials, low probability outcomes eventually appear in the result set.

Whereas with supply chain risk, we get all the risk of the infinite monkey theorem with the added risk from the fact that supplier risk doesn’t magically vanish after the supplier is vetted and onboarded. It is still there, and each new supplier (and their respective supply chains) adds to that risk. It’s a bit like playing a version of Russian Roulette where you add a bullet to the cylinder each time the gun doesn’t fire.

Some practical suggestions

Moving to pen and paper is a surefire way to reduce the risk, and a surefire way to go out of business. So, what can organizations do?

As far as I can tell, none of the prominent security frameworks suggest considering the undeniably accretive nature of supply chain risk as part of the decision to obtain or retain a technology vendor. Not the CIS Critical Security Controls, not NIST SP 800-53 or the NIST Cybersecurity Framework, and not the AICPA’s TSC. NIST’s dedicated tome on the subject, NIST SP 800-161 – Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, comes the closest by discussing aggregating and contextualization of supply chain risk at the overall enterprise risk management level, but it stops short of suggesting already accumulated supplier exposure as a decision metric when evaluating a new or existing vendor.

Until our cyber oracles talk to the cyber gods and incorporate guidance into their respective frameworks, a lot of what needs to happen is subject to professional judgement. So, here are some practical steps you can take to help:

• Reduce overlapping solutions – For example, your company probably doesn’t need to support more than one or two web browsers. Look for overlap, keep the essentials, and eliminate the extras.
• Prefer solutions from existing suppliers – Each new solution and supplier adds new risk. If your needs can be met by existing suppliers, consider those first.
• Consider the number and nature of third-party access – When vetting a new vendor solution, consider how much access has already been granted to the same systems to other vendors.
• Software Developers – Where possible, prefer internally developed libraries to third-party libraries. Prevent CI/CD systems from blindly updating package dependencies; they may be installing malware instead of benign patches.
• Risk vs benefit – Consider the mission relevance. It may not be worth the risk if the access granted is high and the benefit tangential.

Effective implementation will be underpinned by executive buy-in. In smaller organizations, executives need to understand and consider this risk when approving new vendors. In larger organizations, there will be complaints when someone’s favorite toy is taken away or a new solution is denied due to a subjective interpretation of nebulous risk concepts. Leadership needs to support the decisions made by those charged with managing technology supply chain risk.

Conclusion

In Jurassic Park, Dr. Ian Malcom famously warned Mr. Hammond, the park’s owner:

“John, the kind of control you’re attempting… it’s not possible. If there’s one thing the history of evolution has taught us, it’s that life will not be contained… Life breaks free, expands to new territories, and crashes through barriers… life, uh, finds a way.”

Replace “life” with “hackers” and the same lesson applies to cybersecurity. The type of control we’re attempting with our existing risk supply chain risk management methods… it’s not possible.

The data is clear; supply chain attacks are on the rise. Threat actors recognize the efficiencies they gain by targeting a single supplier instead of separately targeting hundreds or thousands of user entities and they recognize that poorly defended suppliers may be the easiest way into an otherwise much harder target. Meanwhile, conventional supply chain risk management thinking has a significant blind spot. It ignores the reality of how risk aggregates. Even the best procedures on planet Earth will not reduce the risk to zero. So, the more vendors and technologies we add, the greater the likelihood of a successful supply chain attack.

Supply chain risk management needs to be rethought, and cybersecurity risk managers will need to venture off the beaten path and start considering how supply chain risk aggregates.

*This article was written and edited by actual humans.

Questions? Keiter’s Cybersecurity team can help you reassess your supply chain risk management approach, identify accumulated third-party exposure, and implement practical steps to reduce risk. Contact your Keiter Opportunity Advisor or Email | Call: 804.747.0000