Open Source Still Powers Modern Software

Open-source software powers web applications, cloud platforms, developer tooling, AI systems, and internal business applications. For most organizations, it is not optional. It is simply part of how software gets built today.

That is exactly why recent software supply chain incidents have drawn so much attention. When a well-known package is compromised, the risk is not limited to one developer making a bad choice or installing a suspicious file from an unknown source. The bigger issue is that organizations are often relying on software they already trust, from ecosystems they use every day, and that trust can be abused in ways that are easy to miss.

Recent Incidents Show How the Risk Is Changing

Recent incidents involving axios and LiteLLM make that point clearly. In both cases, the concern was not a fake package trying to trick users with a similar name. The concern was that legitimate packages in active use were affected, creating a scenario where normal development and deployment activity could expose organizations to real risk.

The axios incident is a good example of how quickly this can happen. Axios is a widely used JavaScript HTTP client library embedded in countless web applications and build pipelines. According to Snyk, malicious versions 1.14.1 and 0.30.4 of the real axios npm package were published through a compromised maintainer account. Those versions pulled in a malicious dependency, plain-crypto-js@4.2.1, which delivered a cross-platform remote access trojan. The malicious releases were available for a short window (hours), but that short window was still enough to create meaningful exposure for systems that automatically pulled fresh installs.

The LiteLLM incident tells a similar story, but from a slightly different angle. LiteLLM is commonly used as a Python library and proxy layer that helps route requests across multiple LLM providers. LiteLLM’s incident report states that versions 1.82.7 and 1.82.8 on PyPI were compromised, while the main codebase itself was verified as safe. LiteLLM also noted that its official Docker deployment path was not affected because it pinned dependencies differently. That distinction matters because it shows how the problem is often not just the source code repository itself. It can also involve packaging, publishing, and release workflows.

A clean source code repository does not automatically guarantee that the packages published to a public registry are safe.

This Is Not Just a Vulnerability Problem

Organizations often frame software risk primarily around known vulnerabilities, missing patches, and outdated libraries. Those risks are still real, but recent supply chain incidents have shown that software trust has to extend further. It also includes how packages are published, who is allowed to publish them, what dependencies they bring with them, and whether build and deployment pipelines are verifying what they consume.

The future of open source is not really a question of whether it remains viable. Open source is deeply embedded in modern software development and is not going away. The better question is how organizations will adapt to a world where use of open source keeps growing, dependency chains keep getting deeper, and attackers continue to target the software ecosystem itself in ways that are harder to ignore.

Trust Now Has to Extend Beyond the Code

In practical terms, the future of open source will likely involve a stronger focus on release integrity. For years, many teams have been comfortable trusting packages based on project reputation, popularity, or community adoption. Those things still matter, but they are often no longer enough on their own. A trusted project can still have a compromised account. A legitimate package can still publish a malicious release. A normal-looking dependency update can still introduce hidden risk.

This is also where automation cuts both ways. Modern development pipelines are built for speed and convenience. They automatically install packages, resolve dependencies, run builds, and deploy code. That efficiency is useful, but it also means a compromised package can move through an environment very quickly if the right checks are not in place. The problem is not that automation exists. In many environments, package consumption has been automated faster than trust and verification controls have matured around it.

The LiteLLM case also points to another important reality. Recent supply chain incidents have shown how interconnected these risks can be. LiteLLM states it believes the compromise originated from a Trivy dependency used in its CI/CD security scanning workflow and the broader release path around package publishing. That means organizations cannot think about package security only at the point of install. They also have to think about upstream tooling, publishing workflows, and the broader paths through which trust can be inherited and then abused.

Moving Forward With Open Source  

Open source is not going anywhere, but the way organizations use it is going to keep maturing. The companies that handle it well will be the ones that put more structure around how software is introduced into their environments. That means keeping a better inventory of dependencies, tightening control over build pipelines, validating where releases come from, and being ready to respond quickly when a trusted package is suspected to be compromised.

It also means putting more attention on how software gets published and verified. In recent years, more of the discussion has shifted toward release integrity, package provenance, and reducing reliance on long-lived credentials in publishing workflows. That is a good direction. If organizations are going to keep building on open source at scale, they need stronger ways to verify that what they are pulling into development and production environments is actually what it claims to be.

What This Means for Business Leaders

For business leaders, the takeaway is not that open source has become too risky to use. That would be unrealistic. The more practical lesson is that open-source security can no longer be treated as only a developer or tooling issue. It is a business risk issue because software supply chain problems can affect production systems, internal operations, customer trust, and incident response timelines.

Leaders should care about more than whether teams are patching known vulnerabilities. They should also care about whether the organization has visibility into its dependencies, reasonable controls around build and deployment pipelines, and a clear plan for responding when a trusted package is suddenly no longer trustworthy. In other words, this belongs in conversations about governance, procurement, engineering standards, third-party risk, and business continuity, not just in the backlog of the development team.

Organizations that recognize that shift earlier are likely to be in a stronger position than those that continue treating trusted software packages as safe by default. Many organizations already have access to tools that can improve dependency visibility and reduce software supply chain risk. In practice, the challenge is often not awareness, but implementation. For many organizations, that means getting outside help to evaluate current dependency management practices, integrate appropriate checks into CI/CD, and build governance around how open-source risk is monitored and addressed over time.

How Teams Can Respond

For technical teams, the response does not need to be complicated, but it does need to be intentional:

• Pin versions in production. Pair pinning with intentional upgrade review and verification so compromised versions are less likely to enter your lockfiles in the first place. Avoid overly loose version ranges that automatically pull the newest release. Short-lived malicious releases are much more dangerous when environments grab fresh packages by default.
• Introduce a minimum-age (cooling-off) policy for newly published dependencies in automated builds, so short-lived malicious releases are less likely to be pulled immediately.
• Limit install-time script execution in build environments where feasible, since many supply chain compromises trigger via install-time hooks.
• Use lockfiles and review dependency changes closely. Do not just look at the top-level package update. Pay attention to what changed underneath it, especially new or unexpected transitive dependencies.
• Use software composition analysis in CI/CD. Teams should use software composition analysis (SCA) tools to automatically identify open-source components, flag vulnerable dependencies, and catch risky package changes before deployment. These checks should be built into the CI/CD process, so they run consistently whenever code is committed, built, or prepared for release.
• Use available tools for dependency review. Organizations do not have to build this from scratch. Tools such as OWASP Dependency-Check, Snyk, GitHub Dependabot, and Aikido can help teams monitor dependencies and reduce exposure. Some teams also fold these checks into broader pipeline tooling, but the bigger point is that solutions exist, including options that do not require major licensing costs.
• Keep dependencies lean. Every package adds another trust relationship. Smaller, better-understood dependency trees are easier to monitor and easier to defend.
• Protect developer and CI/CD environments. Build systems, publishing credentials, and developer endpoints should be treated as high-value assets. If those are compromised, trusted software channels can become delivery paths for malware.
• Have a response plan for dependency compromise. Know how to identify affected versions, contain impacted builds or endpoints, review recent installs, rotate credentials if needed, and communicate clearly when a trusted package turns out not to be trustworthy.

What the Future of Open Source Will Require

Open source will remain central to modern software development. What is changing is the level of discipline required to use it well. Incidents like axios and LiteLLM are reminders that trust in software cannot stop at project reputation or package popularity. Organizations need to think more carefully about how software is published, how dependencies are introduced, and how build and deployment pipelines verify what they consume.

The future of open source will require a more mature trust model. The organizations that benefit from it most will be the ones that pair open source adoption with stronger verification, better operational discipline, and a clearer understanding of what software trust now requires.

Have questions? Talk to us today.