Open-source software has become the invisible infrastructure of modern technology. It runs inside websites, banking apps, cloud platforms, developer tools, artificial intelligence systems, and government services. Most users never see it, but almost every digital product depends on it.
That dependence is exactly why open source is now facing a trust crisis.
The issue is not that open source is unsafe by default. In many cases, open-source projects are more transparent, more widely reviewed, and more reusable than closed software.
The problem is that modern software development has turned open-source libraries into long dependency chains, where one small package can quietly reach thousands or millions of downstream systems.
A research paper titled “Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks” defines a software supply chain attack as the “injection of malicious code into a software package” to compromise systems further down the chain. The same paper notes that dependency managers now “automatically resolve, download and install hundreds of open source packages” during the software lifecycle.
That is the uncomfortable reality: developers may trust one package, but that package may trust dozens of others.
Trust Is Being Exploited at Package Level
Attackers no longer need to break directly into a company’s servers if they can compromise the software that developers already install.
The Backstabber’s Knife Collection paper analyzed 174 malicious software packages used in real-world attacks against open-source supply chains and distributed through npm, PyPI, and RubyGems.
The same Backstabber’s Knife Collection paper documented techniques such as malicious code injection, dependency tree abuse, and execution under different conditions, showing that package ecosystems can be attacked at several points before code reaches production.
This matters because developers often install packages for speed. A library can save hours or days of work. But that convenience also creates a trust shortcut. A package name, a download count, or a GitHub star count can look reassuring even when the security posture behind it is weak.
The XZ Utils Case Showed the Maintainer Problem
The 2024 XZ Utils backdoor was a turning point because it showed that open-source risk is not limited to obscure packages.
Reuters reported that the attempt to insert a “secret backdoor” into XZ Utils, a program “baked into Linux operating systems across the world,” may not have been an isolated incident.
The same Reuters report said the Open Source Security Foundation and OpenJS Foundation warned that at least three JavaScript projects were targeted by individuals asking for suspicious updates or maintainer access.
The danger here is not only technical. It is social. Open-source communities depend on trust, contribution, review, and maintainer access. Attackers can exploit those human systems through pressure, impersonation, social engineering, or slow reputation-building.
That makes the maintainer role one of the most important security positions in modern software, even when the maintainer is unpaid, overworked, or managing the project alone.
Old Dependencies Create Persistent Risk
Not every open-source risk comes from malicious actors. Sometimes the problem is simply that teams keep using vulnerable versions even after fixes exist.
The Sonatype 2024 State of the Software Supply Chain report says 95% of vulnerable downloaded releases already had a fix available.
The same Sonatype report found that 13% of all Log4j downloads were still vulnerable nearly three years after Log4Shell, even though a non-breaking, non-vulnerable version existed.
That finding is important because it changes the blame. Open source is not always failing to fix vulnerabilities. In many cases, the fixes already exist, but organizations are not updating their dependencies quickly enough.
The Sonatype report calls this a problem of open-source consumption and says persistent risk is driven more by consumption practices than by an inherent quality issue in open-source software.
In simple terms, open source may be maintained, but enterprise dependency management is often not.
Malicious Packages Are Growing More Aggressive
The open-source trust crisis is also getting worse because attackers are moving faster and targeting developer infrastructure directly.
ReversingLabs’ 2026 Software Supply Chain Security Report announcement said there was a 73% increase in detections of malicious open-source packages in 2025.
The same ReversingLabs report announcement said attackers are exploiting “trust, scale, and automation” across open-source and commercial software supply chains.
ReversingLabs also said npm malicious activity more than doubled in 2025 and accounted for nearly 90% of detected open-source malware.
That is why open-source security can no longer be treated as a background developer issue. Package repositories, CI/CD pipelines, GitHub tokens, cloud credentials, and developer machines are now part of the attack surface.
Maintainer Support Is a Security Control
The trust crisis is not only about detecting bad packages. It is also about supporting good maintainers.
The 2024 Tidelift State of the Open Source Maintainer Report found that paid maintainers are 8 to 26 percentage points, or on average 55%, more likely to implement critical security and maintenance practices than unpaid maintainers.
The same Tidelift report said paid maintainers were more likely to implement two-factor authentication, static code analysis, security disclosure plans, secrets management, signed releases, and artifact provenance.
This is a crucial point. Companies often treat open source as free infrastructure, but secure infrastructure is never free. Someone has to review code, patch vulnerabilities, rotate keys, sign releases, write security policies, and respond to reports.
If the internet depends on open-source maintainers, then maintainers need to be treated less like volunteers in the margins and more like critical infrastructure operators.
Better Trust Needs Better Signals
The answer is not to abandon open source. That would be impossible and undesirable. The answer is to build stronger trust signals around it.
OpenSSF Scorecard says it assesses open-source projects for security risks through automated checks and helps consumers make informed decisions about accepting security risks in their codebases.
The OpenSSF Scorecard GitHub page says Scorecard was created to help maintainers improve security best practices and help consumers judge whether dependencies are safe.
These tools do not solve everything, but they move the ecosystem away from blind trust. Security scores, software bills of materials, signed releases, provenance, dependency pinning, vulnerability disclosure policies, and automated update workflows all make trust more measurable.
The Real Crisis Is Not Open Source Itself
Open source still runs the internet because it works. It lets developers build faster, share knowledge, avoid duplicating effort, and improve software through public collaboration.
The crisis is not that open source is broken. The crisis is that the software industry built enormous commercial systems on open-source components without always investing in the people, processes, and verification systems needed to keep that foundation secure.
For developers, this means dependency choices must become security decisions. For companies, it means open-source consumption needs governance, monitoring, updates, and funding. For maintainers, it means the industry must recognize that trust cannot survive on goodwill alone.
Open source will continue to run the internet. But maintaining trust in it now requires more than downloading a package and hoping for the best.
