Do you know anyone who still plugs parking lot USBs into computers? Maybe you do. Do you know anyone who pulls code directly from a public GitHub repo? Without a doubt. However, if we think about the underlying concepts (bringing unverified, public data into an organization’s ecosystem), aren’t these actions fundamentally the same? What is a public GitHub or npm if not a digital parking lot for code?

This idea is at the heart of many supply chain attacks that have been recent front-page cybersecurity headlines. But while supply chain woes are nothing new to the cybersecurity industry, there has been a marked increase in the number of successful attacks being seen year over year due to open-source repositories being used as a launchpad. As a reference, ReversingLabs’ 2026 Supply Chain Security Report saw a 73% increase in malicious open-source packages from 2024 to 2025. While this increase may seem extreme, the upswing in incidents is the direct result of new methodologies we’re seeing in use by threat actors, which provide increased attack surface area and a decreased time to compromise.

Given such a massive change in the threat landscape, it’s no surprise that we’ve seen a corresponding shift in customer conversations toward broader software supply chain security. Truthfully, in 2026, most organizations (and certainly their developers) have a general idea of the risks that they can own and mitigate within their ecosystem. Whether we’re talking about static code analysis (SAST), dynamic application testing (DAST), software composition analysis (SCA) tools, or even implementing a software development lifecycle (SDLC)—these are typically not new concepts to clients. Moving past what is within an organization’s walls and into the conversations of open-source security we are having more and more with clients today, the picture becomes somewhat murkier.

Customers are facing the daunting task of securing workflows built around resources that they do not own and cannot manage. Put another way, these clients are asking how to apply digital risk management strategies at scale to the numerous and disparate open-source resources that they leverage daily. This is a topic K logix has considerable experience to draw on—we’ve talked about Digital Supply Chain Risk Management and written in-depth about cybercriminals like TeamPCP leveraging continuous integration/continuous delivery (CI/CD) pipelines to compromise numerous organizations quickly and at scale. But to determine how an organization can properly mitigate the risks presented by open-source attack vectors, it is necessary to understand why these attacks are increasing.

Why Open-Source Attacks Are Accelerating

In the past, traditional supply chain attacks often required time, skilled resources, and a healthy measure of stealth in a targeted campaign to compromise a software vendor’s environment and sneak malicious code into trusted proprietary software (à la the infamous 2020 SolarWinds incident). But a shift in tactics has significantly lowered the barrier for entry as cybercriminals have identified a much more impactful, much less secured target in non-proprietary, open-source software.

The truth of why public repos have become a popular target, and why these attacks are so impactful, has everything to do with three main factors at the core of open-source ecosystems:

• Trust
• Scale
• Automation

Trust

It’s an open-source open secret that every developer, even security-minded ones, is not checking libraries or applications they’re importing from public repositories. When a developer is working on a project that requires a certain JavaScript library, the developer’s workflow does not involve checking the library’s recent update history and reading the library line by line for potential malicious code. Instead, a developer will insert an “import” command at the start of their code that downloads the latest version of the library, and then move on to their next task. And thus, with one line of code, a new supply chain risk is unknowingly introduced for the organization. Whether the library is malicious at this point is actually immaterial; because the source is public, much like a parking lot USB, it is an active risk vector.

One example of these risks in action was a supply chain attack in early 2026 where North Korean threat actors compromised a developer account for the popular JavaScript library Axios. This compromise resulted in versions of the library pushing WAVESHAPER.V2 malware to any system that downloaded it. For context, Google’s Threat Intel Group cited the two impacted versions of Axios’ libraries as having a combined 183 million downloads a week. A single external compromised developer account handing North Koreans a backdoor into your environment is the stuff of cybersecurity nightmares and should highlight exactly why open-source resources can never be inherently trusted and must have additional safeguards built around them.

Scale

Taking the conversation around the Axios compromise a step further leads to the next factor: scale. 183 million downloads a week is an astonishing attack surface, enabled by the unique ubiquity and interconnectedness of open-source software. In the age of every company having its own app and “internal” code repositories, it can be easy to lose sight of how much of our world depends on open-source software, but the research is clear: Black Duck’s 2026 Open Source Security and Risk Analysis Report states that 98% of all codebases contain open-source components. And even if an organization believes it operates within the 2% margin, can it say the same for its vendors or its vendors’ vendors?

Threat actors understand both how integral and vulnerable open-source resources are to all of us. As a result, they are actively developing malware to weaponize open-source infrastructure with the goal of rapidly spreading across it and impacting as many organizations as possible after an initial compromise.

Automation

All of this comes before taking into account the impact that AI and automation have had on the open-source community. For developing software, the advent of AI tools has served to greatly reduce the amount of time and effort needed in what were previously manual workflows, like detecting software vulnerabilities and writing code to support new features. However, on the other side of efficiency gains, it is now easier than ever for threat actors to generate malicious code, write exploits, and automate reconnaissance of public resources. But the real catch-22 is that both the positive and negative use cases arising from AI generate additional workflows for open-source teams, which they lack the manpower to keep up with.

To be clear, this is a problem being felt around the industry: NIST (maintainers of the National Vulnerability Database) has stated that their team’s “productivity is not enough to keep up with growing submissions.” At the same time, the latest reports on threat trends are advising that the time from a threat actor breaching the network to exfiltrating data is shrinking to mere minutes, or “39 seconds” per Palo Alto’s Unit 42. With the increase in vulnerabilities and decrease in exploitation window brought on by AI tools, even organizations with robust cybersecurity programs are realizing they cannot patch everything and must prioritize. However, if even well-funded organizations cannot keep up with the rising tide of vulnerabilities, what can we expect from the volunteer teams that maintain open-source software?

Taking each of these three factors into consideration paints a clear picture: The shift toward a softer target in underfunded, often volunteer, teams maintaining open-source code, coupled with AI and the interconnected nature of code dependencies, has resulted in more frequent, faster-moving incidents with often an industry-wide blast radius.

Why Traditional Defenses Are Not Enough

It can be tempting to apply the typical industry axiom of “your supply chain is only as strong as the weakest link” to these open-source concerns. But to state it bluntly, the security of open-source software is functionally impossible to assess, not because the industry lacks the tooling or inclination to do so, but because risk itself is built in to the open-source model by design as a feature. Open source’s eponymous feature is that it is open—which is to say that it is accessible by anyone and in turn can accept submissions from anyone. Cybercriminals know this and have opted to take on part-time work to help maintain these projects as a way of buying trust prior to slipping in a malicious backdoor (à la the 2024 XZ Utils incident). Practically, what this means is that even assuming a perfect-world scenario where all open-source projects have impenetrable account security such that their developers cannot be compromised, risk still exists inherently in the way these projects are maintained.

And this shift to open-source targets by threat actors is no coincidence. As organizations increasingly allocate time and resources to hardening their network perimeter, adopting zero trust network access (ZTNA) architecture, and continuously running counter-phishing operations against their personnel, traditional methods of compromise are getting harder to leverage. Not impossible, but harder. And that’s a meaningful distinction because threat actors can be counted on to always use the path of least resistance when trying to get into an environment. Thus, this becomes an equation with an obvious answer for cybercriminals: target the front gates of a single organization through concerted effort or target the entire industry’s shared digital parking lot at fractions of the overhead.

Given that these risks are ingrained into open source’s core principles, these inherent risks are unlikely to ever go away. Moreover, we can be certain that once threat actors identify a path that works, they will keep coming back to it as long as it does. That is why it is so critical to begin taking steps as an organization to secure your CI/CD pipelines and open-source dependencies.

What Security Leaders Should Be Thinking About

With these changes in the threat landscape, clients are now facing renewed concerns around creating and maintaining software inventories, insulating their development teams from open-source vulnerabilities, and mitigating risk when using software and libraries that they do not own or manage. Security leaders should be looking to answer the following about their organization:

• Do we have a way to view all open-source components running within our codebase?
• Do we have a way to verify the origin and integrity of these components?
• Are there controls in place to prevent malicious or tampered packages from entering our environment?
• How quickly can we identify a compromised dependency?
  
  

How K logix Helps

Every organization’s software supply chain is different. K logix works with organizations to identify software supply chain risks, evaluate their current approach, and develop practical strategies to better secure open-source software and development environments. To learn more, please reach out to our experts.