Most organizations know their perimeter. They know their firewall rules, their patching cadence, and their endpoint coverage. What they often don't know is what their software is actually built from and who else has had their hands on it. That's the gap ransomware operators and state-aligned groups have spent the last two years learning to exploit with remarkable precision. The threat isn't theoretical. It's already inside your build pipeline.

The CVE Noise Problem Is Worse Than You Think

There's a common assumption that more vulnerability disclosure means better security visibility. In practice, the opposite is often true. Of the 48,000-plus CVEs published in 2025, only 58 posed a genuine supply chain threat, meaning security teams sifting through the full catalog are spending most of their time on vulnerabilities that will never be weaponized in the wild.

That signal-to-noise problem is one of the central challenges Black Kite's latest supply chain research addresses. The question isn't how many CVEs exist; it's which ones are being actively integrated into attack chains and by whom. Without that lens, organizations default to patch everything or patch nothing, and neither approach maps well onto actual risk.

Open-Source (News - Alert) Ecosystems Are Being Treated as Attack Infrastructure

The threat model has shifted. Open-source registries like npm and PyPI are no longer just distribution platforms; they're being treated as deployment infrastructure by adversarial groups running industrialized malware campaigns at scale. Repository abuse now shows up in over half of logged malicious packages, with threat actors automating publication and iterating rapidly across package namespaces.

Groups like Lazarus concentrated their 2025 campaigns overwhelmingly in npm, exploiting the fact that the registry doesn't require namespace validation and that tooling defaults to pulling the latest versions, meaning poisoned dependencies can propagate through transitive dependency chains into CI/CD systems and production environments with minimal friction. This is not opportunistic exploitation. It's systematic, and it's getting faster.

2025 marked the point where isolated incidents became integrated campaigns; attackers proved that software supply chain intrusions are now among their most reliable weapons. For Linux and open-source environments particularly, the implications are difficult to overstate.

When Your Security Tools Become the Attack Vector

Perhaps the most unsettling development in recent months has been the targeting of security tooling itself. Between late February and March 2026, a group tracked as TeamPCP systematically compromised widely trusted open-source security tools, including the vulnerability scanners Trivy and KICS, meaning the exact tools many organizations bolt onto their CI pipelines to detect malicious dependencies were themselves turned into malicious dependencies.

The common target across these attacks was credentials stored in environment variables, .env files, and credential helper caches on machines that also execute package installs or run CI/CD pipelines. The architectural lesson is clear: any machine that executes code from a public registry and also holds privileged credentials is a single point of failure. That describes most developer workstations and a significant portion of build infrastructure.

Adversaries are increasingly adopting "shift-left" tactics to subvert build runners and poison development dependencies before code reaches production, which means detection at the production boundary is already too late.

Ransomware Groups Are Leveraging the Same Entry Points

The connection between open-source supply chain compromise and ransomware deployment isn't incidental. Ransomware groups, including Qilin, Kraken, and RansomHub, weaponized Linux kernel exploits in 2025 to hit more than 700 organizations across 62 countries, targeting backup infrastructure, escaping container boundaries, and gaining root access on systems that were waiting for patches that hadn't yet been deployed.

The pattern that emerges across these campaigns is consistent: initial access through a compromised dependency or developer credential, followed by privilege escalation via a kernel or container vulnerability, followed by lateral movement toward backup systems before ransomware deployment. Each stage exploits gaps that exist independently in many organizations, but together they form a complete attack chain.

TeamPCP's toolkit evolved through late 2025 into early 2026 to include a cloud credential stealer, a cryptocurrency miner, and eventually VECT ransomware deployed using credentials stolen by earlier tools in the same chain. This staged, multi-payload approach reflects a maturity in operational planning that goes well beyond what most incident response frameworks were built to handle.

What Linux and Open-Source Environments Need to Get Right

A few concrete areas deserve attention:

• Dependency provenance: Know where your packages come from and validate them against known-good hashes. Assume nothing about a package just because it's widely used.
• CI/CD credential isolation: High-value credentials should never live on machines that execute code from public registries. Scoped, short-lived tokens via a dedicated secrets manager are the structural fix.
• Kernel patching cadence: The Linux kernel continues to accumulate actively exploited vulnerabilities, with CISA adding confirmed in-the-wild exploits to its Known Exploited Vulnerabilities catalog on an ongoing basis. Waiting for a quarterly patch window is no longer defensible.
• Third-party visibility: Knowing your own stack isn't enough. Nth-party dependencies, the packages your packages depend on, are where a growing share of supply chain intrusions begin.

Visibility Is the Prerequisite for Everything Else

The supply chain security problem isn't primarily a technical one. It's a visibility problem. Organizations that got through 2025 without a major supply chain incident weren't necessarily better defended; many were just lucky or not yet on the target list. A single poisoned package, a compromised vendor, or a cloud misconfiguration can trigger widespread operational disruption across interconnected supply chains.

The organizations that will fare better going forward are those that can answer, with confidence, what's actually running in their environment, and whether any of it has been tampered with.

If your current supply chain visibility doesn't extend to transitive dependencies, build infrastructure, and third-party vendor risk, that's where the work starts. Audit your pipeline, isolate your credentials, and treat your security tooling with the same skepticism you'd apply to anything else from a public registry. The attackers already do.