The Arrests That Put a Face on a Long-Running Threat
Australian federal authorities recently arrested two individuals tied to a cybercrime group accused of running the most prolonged software supply chain attack campaign on record. The group, known as TeamPCP, allegedly embedded malicious code inside open-source packages that organizations around the world downloaded as part of routine software operations. KrebsOnSecurity reported on the arrests and the investigation in detail at krebsonsecurity.com.
Two arrests are a meaningful development. But the more important story for any business owner or operations leader in Greater Phoenix is the attack pattern itself, because it does not require your business to be specifically targeted. It requires only that you use software, which every business does.
The scale here isn't a fringe concern. Third-party involvement in data breaches doubled year over year, from 15 percent to 30 percent, according to the Verizon 2025 Data Breach Investigations Report, the largest single-year shift the report has ever recorded. When a supply chain compromise does succeed, IBM's 2025 Cost of a Data Breach Report puts the average cost at $4.91 million and the average time to identify and contain it at 267 days, the longest lifecycle of any breach type IBM tracks. That combination, rapidly growing frequency and an unusually long window before anyone notices, is what makes this attack pattern worth taking seriously even for a business with no in-house developers.
What a Software Supply Chain Attack Actually Is
Most cyberattacks are aimed directly at a victim. A supply chain attack works differently. Instead of breaking into your business, attackers compromise something your business trusts and downloads automatically: a software library, a package, a dependency buried inside a tool your team uses every day.
Here is how the pattern typically works:
- A developer publishes a legitimate open-source library that thousands of applications pull in as a building block.
- An attacker gains access to that library, either by compromising the original developer's account, publishing a look-alike package with a nearly identical name, or taking over an abandoned project.
- Malicious code is inserted into a new version of the library. Because the package comes from a trusted source and passes the same automated checks as before, it gets downloaded without triggering alarms.
- Any application that updates to the poisoned version now runs attacker-controlled code inside a trusted process, often with full access to the data and credentials that application can reach.
The attack is effective for a straightforward reason: it hides inside something you already decided to trust. Your perimeter controls, your email filters, your antivirus, none of them are positioned to catch malicious code arriving inside a software update from a publisher you have used for years.
Why This Matters Even If You Do Not Write Software
The most common reaction from small and midsize business owners when this topic comes up is some version of: "We don't use open-source software." In almost every case, that assumption is incorrect.
Open-source components are embedded throughout the tools that run ordinary business operations. Consider where they appear:
- Web platforms and content management systems. WordPress, Drupal, and comparable platforms are built on open-source foundations and pull in hundreds of third-party components. Plugins and themes each introduce additional dependency chains.
- Accounting and finance integrations. Cloud-based accounting tools frequently connect to open-source libraries for data formatting, API communication, and reporting functions.
- Cloud services and SaaS platforms. Every SaaS product your team logs into was built by engineers who used open-source libraries. You are consuming those components indirectly every time the software updates.
- Development and automation tools. Businesses with any internal scripting, reporting automation, or IT tooling almost certainly run on Node.js, Python, or similar ecosystems, each of which draws from large public package repositories.
- IT management and monitoring software. The tools your Managed Service Provider (MSP) uses to patch, monitor, and support your environment are themselves software products with their own dependency chains.
This is not a reason to stop using software. It is a reason to understand that software vetting and inventory management are now a real part of ongoing IT operations, not a one-time setup task.
The Four-Part Framework: What Managed IT Does About Supply Chain Risk
Supply chain attacks do not have a single silver-bullet defense. What they require is a set of overlapping operational practices that collectively reduce the window of exposure and increase the likelihood that something unusual gets caught early. Here is how that responsibility is divided in a well-run managed IT engagement.
1. Application Inventory and Source Vetting
You cannot protect software you do not know you have. A managed IT program maintains a current inventory of applications running across endpoints and servers. When new software is introduced, or when an existing tool requests a significant update, the source is checked: Is this coming from the official publisher? Does the update behavior match what is expected? Has anything flagged this package in the broader security community?
This does not mean every update gets manually reviewed line by line. It means the process of software introduction and update is governed rather than ad hoc, so unusual patterns surface rather than pass silently.
2. Application Control (Default Deny)
One of the most effective controls against supply chain attacks is restricting which applications are permitted to run in the first place. An application allowlisting approach means only explicitly approved software executes on managed endpoints. Everything else is blocked by default.
This matters for supply chain risk because a poisoned dependency that attempts to run new or unexpected executable code is stopped before it can operate, even if the parent application that pulled it in is itself trusted. The malicious payload cannot launch if it is not on the approved list.
Equally important is what happens after an application is allowed to run. Ringfencing controls limit what approved applications can do once they are running: which other applications they can interact with, which parts of the file system they can reach, and whether they can make outbound network connections they have no legitimate reason to make. A compromised library running inside a trusted application still cannot reach your credentials or your data if ringfencing prevents that interaction.
3. Monitoring for Unexpected Outbound Traffic
When a supply chain attack succeeds in running code, that code typically needs to reach back out to infrastructure controlled by the attacker, to exfiltrate data, receive commands, or establish persistence. Outbound traffic monitoring is often where an otherwise-invisible compromise becomes visible.
A managed IT program with endpoint-level network controls and monitoring can identify when a known application begins reaching out to destinations it has never contacted before, at unusual times, or in volumes inconsistent with normal operation. That anomaly triggers investigation, which is the practical point at which a quiet, months-long supply chain compromise gets discovered and stopped rather than simply running undetected.
This is also where Managed Detection and Response (MDR) adds operational value. Real analysts reviewing behavioral signals, rather than an automated system matching against known-bad signatures alone, are better positioned to catch the subtle behavioral drift that a supply chain payload produces when it first activates.
4. Patch Management With Source Awareness
Prompt patching is still the right posture for the vast majority of known vulnerabilities. But supply chain attacks create a nuanced situation: the malicious update itself is the attack vector, which means a policy of "apply all updates immediately from all sources automatically" can, in some configurations, accelerate exposure rather than reduce it.
A managed IT program addresses this by staging updates through a tested channel rather than pushing every vendor update directly to production endpoints the same day it is released. The delay is measured in days, not weeks, and it does not create meaningful unpatched-vulnerability exposure. What it does create is a brief window during which the security community can identify a poisoned release before it reaches your environment.
What Onsite Technical Services Does in This Area
Onsite Technical Services builds the operational practices described above into client engagements through the Managed Security and Support line and the Layered Cybersecurity and Threat Defense service stack. The specific controls relevant to supply chain risk include:
- Application allowlisting and ringfencing, which prevent unauthorized code from executing and limit what approved applications can reach.
- Endpoint Detection and Response (EDR), which watches device behavior continuously for the signals that indicate something unexpected is running.
- Managed Detection and Response (MDR) with 24/7 analyst coverage, so behavioral anomalies get human review rather than waiting for a signature match.
- Endpoint patching managed through a tested update process rather than direct automatic application.
- Malware and web content protection, which filters traffic at the network level and can catch known-malicious outbound destinations even when the process initiating the connection is itself trusted.
No single control eliminates supply chain risk entirely. The value of a managed program is that these controls operate together and are actively maintained, not deployed once and left to run without oversight.
Questions to Ask Your Current IT Provider
If you are evaluating your current IT and security posture in light of supply chain risk, these are the operational questions worth asking:
- Do we have a current inventory of software and applications running across our endpoints and servers?
- Is there a process for reviewing and approving new software before it is introduced to managed devices?
- Does our endpoint security include application allowlisting, or does it rely primarily on antivirus and signature-based detection?
- Are software updates staged and tested, or applied automatically and immediately from all sources?
- Is anyone monitoring outbound traffic for behavioral anomalies, and what happens when something unusual is found?
- If a supply chain compromise were active in our environment right now, how would we know?
The last question is the most important one. An MSP that cannot answer it specifically is likely operating a reactive security model, responding to incidents after they become obvious rather than catching the quiet early signals that supply chain attacks produce.
The Broader Point: Trusted Software Is Still Software
The TeamPCP campaign, as described in the KrebsOnSecurity reporting, is notable for its duration. This was not a brief opportunistic attack. It was a sustained effort to embed malicious code in tools that businesses routinely trusted, over an extended period, precisely because sustained and quiet is more profitable than loud and fast.
That pattern has an important implication for how businesses think about IT risk. The question is not only whether an attacker can get past your defenses directly. It is also whether something you already trust has been quietly turned against you, and whether your IT environment is structured to catch that distinction.
Most small and midsize businesses do not have the internal staffing to operate the monitoring, inventory, and behavioral-analysis functions that supply chain risk requires on an ongoing basis. That operational gap is exactly what a well-scoped managed IT engagement is designed to fill.
