Two stories broke this week that, taken individually, look like standard vulnerability disclosures. Taken together, they describe something more significant: a sustained, deliberate campaign to compromise the software supply chain by attacking the tools that developers and security teams use to build and secure software.
The first involved Trivy, the open-source vulnerability scanner used across thousands of CI/CD pipelines to assess container images and infrastructure-as-code configurations. A path traversal vulnerability (CVE-2026-33634) allows an attacker who controls a scanned repository to write arbitrary files to the host running the scanner — meaning that the tool your pipeline uses to find vulnerabilities can itself be exploited to compromise the build environment.
The second involved LiteLLM, an AI model routing framework, where a malicious package named litellm-patch was published to PyPI. The package mimicked a legitimate dependency update and exfiltrated credentials from developer machines during installation. Developers who ran a standard pip install to update their environment became victims before the package was pulled.
Neither of these is a novel attack class. Supply chain compromise through package repositories and exploitation of developer tooling have both been documented for years. What has changed is the sophistication, frequency, and targeting of these attacks — and the security posture of most organisations has not kept pace.
Why Developer Tooling Is the Target
The logic is straightforward from an attacker’s perspective. Production environments are defended. Networks have segmentation, endpoints have EDR, authentication has MFA. The attack surface has contracted significantly over the past decade as enterprise security investment has matured.
Developer environments have not received equivalent attention. Developers run with elevated privileges on local machines to enable rapid iteration. They install packages from public registries without cryptographic verification of provenance. Their build pipelines have direct access to source code repositories, cloud credentials, container registries, and production deployment infrastructure. A single compromised developer machine can yield credentials and access that a network-level attacker could not obtain through months of lateral movement.
More fundamentally, CI/CD pipelines are trusted by design. The entire model of modern continuous delivery depends on automated systems being trusted to deploy code to production. That trust, unexamined, becomes a structural vulnerability.
The Dependency Problem
The average enterprise application depends on hundreds of open-source packages. Those packages depend on their own transitive dependencies. The total dependency tree of a moderately complex application can contain thousands of packages, maintained by individuals and small teams with no security vetting, no liability, and no formal relationship with the organisations consuming their code.
This is not a criticism of open-source software — it is a description of an ecosystem that has delivered enormous value and created a corresponding attack surface that is only beginning to be addressed systematically. The XZ Utils backdoor demonstrated in 2024 that sophisticated threat actors are willing to invest significant time — in that case, years — into compromising a widely-used library through social engineering of its maintainer.
LiteLLM’s compromised PyPI package required no such patience. Typosquatting and dependency confusion attacks exploit the gap between package name expectations and package registry verification. Package names are not trademarks. Nothing prevents a malicious actor from registering litellm-patch on PyPI. The only defence is verification before installation.
What Needs to Change
The tools exist to substantially reduce supply chain risk in software development environments. The gap is implementation, not availability.
Software Bills of Materials (SBOMs) — machine-readable inventories of every package in an application’s dependency tree — are now a US federal requirement for software sold to government agencies, and are increasingly expected in regulated industries. Without an SBOM, an organisation cannot answer the question “do we use this package?” when a malicious dependency is discovered. That question is currently being asked daily.
Package signing and verification via frameworks like Sigstore allows developers to verify that a published package was signed by the expected maintainer key. PyPI has enabled Sigstore-based provenance for packages that opt in. Organisations should configure their build tooling to reject unsigned packages from public registries.
Isolated build environments prevent a compromised scanner or build tool from reaching production credentials. If Trivy runs in a sandboxed environment with no access to deployment credentials, the path traversal vulnerability described this week is substantially less useful to an attacker. Many organisations run their CI/CD pipelines with ambient access to production systems that no scanner or build tool should require.
Dependency pinning and lock files prevent automatic acceptance of new package versions. An attacker publishing a malicious update to PyPI cannot reach an environment that has locked its dependencies to verified versions and reviews changes before applying them.
The Posture Question
The deeper issue is whether organisations treat their development pipeline as part of their attack surface in the same way they treat their network perimeter or endpoint estate.
Most do not. Security teams defend production. Developer environments are owned by engineering. The CI/CD pipeline is managed by a DevOps team that may or may not report into a function with security oversight. This fragmentation means that the most direct path to production — the build pipeline — receives the least security scrutiny.
That is the structural problem these attacks are exploiting. The tools are available to address it. The organisational will to treat software supply chain security as a first-class security problem, not a compliance checkbox, is what most organisations still lack.
Share this article