The Pattern Nobody Wants to Admit
We have been here before. Not with this specific vulnerability, but with this exact moment: the discovery of a critical flaw in some widely-used open-source component, the scramble to patch, the post-mortems that follow, and then the slow fade back into complacency. CVE-2025-XXXXX is just the latest iteration of a conversation we should have finished having five years ago. The difference this time is that we have actual data now, the kind that makes excuses harder to defend.
When I started working in infrastructure security in the early 2010s, supply chain attacks were theoretical. They were the nightmare scenario you discussed at conferences but never quite expected to encounter in your actual environment. That was naive thinking, and the industry has paid for it repeatedly. What has shifted is not the nature of the threat but our ability to measure it. We now have enough historical data to know that supply chain security was not a failure of execution. It was a failure of priority.
The numbers validate this bleak assessment. Open-source security researchers documented a 28 percent increase in critical vulnerabilities affecting npm packages from 2024 to 2025, and more troublingly, the average time between public disclosure and active exploitation has compressed to under 48 hours for high-profile flaws. That is not a window for deliberate patching. That is barely time to notify your stakeholders, let alone coordinate fixes across an organization with distributed infrastructure.
When Half-Measures Become the Standard
Google introduced the SLSA framework in 2021 as an answer to supply chain compromise. It was designed as a tiered system, starting simple with SLSA Level 1 and ascending through progressively stricter requirements for artifact integrity, build transparency, and provenance verification. By 2025, when SLSA reached version 1.1, you might have expected some meaningful adoption among major open-source projects. Instead, fewer than 12 percent of significant open-source projects had achieved even the baseline Level 1 compliance. Read that again. Twelve percent. After four years and substantial industry attention.
This is not a technical problem. The framework exists. The tooling is mature. The problem is institutional inertia combined with resource constraints that are real but often overstated. When maintainers of critical projects operate on volunteer time and institutional support remains unpredictable, asking them to implement elaborate build attestation systems feels like adding another layer of burden to an already overwhelming stack.
The pragmatist in me understands the tension. The security professional in me finds it unacceptable. We have built the foundation for better supply chain practices. What we have not done is make them the default expectation rather than the optional upgrade.
The Active Threat is Larger Than You Think
CISA publishes a catalog of known exploited vulnerabilities. As of the end of 2025, it crossed the 1,200 entry threshold. That catalog is not a complete inventory of all bad things happening in the wild. It is a curated list of vulnerabilities that are actively being weaponized by threat actors. When CISA reports that 67 percent of successful breaches affecting critical infrastructure involved at least one open-source component, they are describing a systemic failure mode in how we think about software risk.
Check the CISA Known Exploited Vulnerabilities Catalog yourself. The velocity is unsettling. You will see entries from 2025 sitting alongside older vulnerabilities that organizations still have not patched. The catalog is a real-time measure of how much of the digital infrastructure we all depend on remains exposed to known compromise techniques.
What makes this particularly acute is the asymmetry of effort. Attackers need to find one vulnerability you have not patched. You need to patch all of them. Scale this across thousands of organizations, millions of projects, and billions of dependencies, and you begin to see why supply chain security remains such a stubborn problem.
Malicious Packages Are Not Slowing Down
The Sonatype analysis of seven million open-source projects revealed something that should concern anyone managing dependencies: malicious package uploads increased 156 percent from 2024 to 2025. That is not a marginal worsening. That is a doubling plus change in the rate at which adversaries are actively attempting to inject compromised code into the supply chain. Typosquatting remains the dominant vector, where attackers register packages with names similar to legitimate ones, hoping developers will mistype and pull in the malicious version.
The sophistication of these campaigns has also increased. Early typosquatting attacks were obvious. Newer ones often include legitimate functionality alongside payload code, making them harder to catch through manual review. They target specific development frameworks and try to blend into build processes. See the Sonatype State of the Software Supply Chain Report for the full analysis, but the takeaway is stark: the attack surface is expanding faster than our ability to defend it.
Socket.dev, a startup focused specifically on blocking supply chain attacks, reported blocking over 10,000 malicious packages from reaching developer environments in a single quarter of 2025. That is an extraordinary number. It also represents packages that almost made it into production systems. The fact that this required a specialized vendor rather than being a standard capability of package managers tells you something about how we have structured these systems.
What Needs to Happen, and Why It Probably Won’t
If I were tasked with the impossible job of solving supply chain security today, I would focus on four concrete changes. First, make SLSA Level 1 compliance a hard requirement for any package admitted to major repositories. Not a nice-to-have. A requirement. Second, fund open-source security infrastructure the way we fund physical infrastructure, because that is what it is. Third, implement mandatory provenance tracking for every build artifact. Fourth, establish industry-wide standards for rapid vulnerability disclosure and coordinated patching windows.
Each of these is technically feasible. Each would have immediate impact. Each would face institutional resistance because they require coordination, impose friction, and cost money. The organizations with the most leverage to drive change are often the ones with the most to lose from transparency. This is the structural problem beneath all the technical problems.
CVE-2025-XXXXX will be patched. The immediate crisis will pass. Organizations will update their systems, and security teams will file their incident reports. Then we will return to the baseline state of managed chaos that characterizes modern supply chain security. The statistics will worsen next year because the incentive structures have not changed. Attackers will continue to scale their efforts. Defenders will continue to react.
I want to be wrong about this. I would welcome evidence that the industry has finally absorbed the lesson that supply chain security is not optional infrastructure but foundational to everything we build. Until I see sustained institutional commitment matching the scale of the problem, I will be planning my infrastructure defensive strategies based on the assumption that the next critical vulnerability is already in your dependencies. What specific supply chain vulnerabilities are you most concerned about in your current systems? I would appreciate hearing perspectives from people actively managing these risks.