The Dependency Problem

How attackers are hiding inside the tools developers trust

Security teams have long focused on keeping attackers out. Perimeter defenses, phishing controls, endpoint protection. The assumption underlying all of it is that adversaries are trying to break in. That assumption is increasingly outdated.

A growing class of attacks does not break in at all. Instead, attackers are poisoning the tools, libraries, and pipelines that developers already trust. By the time malicious code executes, it is running inside a legitimate environment, with real credentials and real permissions, looking no different from normal build activity.

How the Attack Works

Unlike conventional intrusions, supply chain attacks follow a patient, multi-stage model. The attacker does not need to exploit a vulnerability in your infrastructure. They only need to compromise something you already trust.

The anatomy of a modern supply chain attack typically unfolds across five stages:

Injection — The attacker introduces malicious code into a component that appears entirely legitimate: an open-source library on npm or PyPI, a Docker image, a GitHub Action, or a developer plugin. This is the hardest step for defenders to catch because the component arrives from a known source.
Distribution — The poisoned component propagates through the ecosystem. Developers install it directly, or it is pulled in as a transitive dependency — a dependency of a dependency — with no explicit decision made to include it.
Execution — When a developer installs the package, a CI/CD pipeline runs an automated build, or an infrastructure script fires during deployment, the malicious code executes automatically inside a trusted environment. No further user interaction is required.
Credential Harvest — That trusted environment typically has access to secrets: API keys, cloud credentials, GitHub tokens, SSH keys, and environment variables. These become the real target.
Exploitation — With those credentials, attackers move laterally into cloud infrastructure, enumerate storage and databases, escalate privileges, and ultimately exfiltrate data or embed persistence for future campaigns. No exploit required. Just legitimate access, used maliciously.

Flow diagram showing the five-stage software supply chain attack: attacker injects malicious code into an open-source component, which is distributed via package registries, executed inside a trusted build environment, used to harvest credentials, and finally exploited for cloud access, data exfiltration, or persistent backdoor access. — The five-stage supply chain attack flow. No vulnerability is exploited at any point — trusted access does all the work.

Why This Matters

Security teams have invested heavily in endpoint detection, email security gateways, and network monitoring. These tools are effective at what they were designed to do. The problem is that supply chain attacks are designed to avoid exactly those detection paths.

Several structural weaknesses make this class of attack particularly difficult to catch:

Implicit trust in package registries means that if a component arrives from a known source, it is generally assumed safe without further scrutiny.
CI/CD pipelines receive little of the same monitoring depth applied to endpoints, creating a largely invisible execution environment.
Secrets are frequently exposed as environment variables or embedded in pipeline configurations, making them accessible to any code that runs during a build.
Developer workstations operate with elevated privileges and often fall outside strict security monitoring, creating natural entry points.

The Broader Security Trend

Abusing trusted platforms is not a new concept. Attackers have previously used cloud storage for malware hosting, messaging services for data exfiltration, and social media for command delivery. Supply chain compromise follows the same logic: hide inside something legitimate.

What makes the current environment more dangerous is scale and automation. The modern development ecosystem depends on enormous webs of open-source dependencies, automated pipelines, and shared infrastructure. Each node in that web is a potential insertion point.

Supply chain attacks are also increasingly combined with other techniques. Social engineering, dependency poisoning, credential abuse, and cloud exploitation are being layered together into attack chains that are quieter, more scalable, and harder to attribute than traditional intrusions.

As development environments grow more automated and AI-assisted tooling becomes more common, the attack surface will only expand. Pipelines that once required human review are increasingly executing autonomously, reducing the opportunities for manual detection before code runs at scale.

Defensive Takeaways

Organizations operating modern development environments should consider the following practices as part of a supply chain security posture:

Lock down dependency management

Use version pinning and validate package integrity where possible. Avoid automatic updates in production pipelines. Treat dependency updates as a change management event, not a background process.

Treat CI/CD as a high-risk execution environment

Apply the same monitoring discipline to build pipelines that you apply to servers. Restrict pipeline token permissions, separate build and deploy environments, and require approval gates for workflows triggered by external contributors.

Secure secrets at the infrastructure level

Move away from environment variables as the primary secrets delivery mechanism. Use dedicated secret managers, rotate credentials regularly, and audit what is accessible during pipeline execution.

Control code execution paths

Require human review for pull requests from external contributors before any automated workflow runs. Disable triggers such as unrestricted pull_request_target that allow untrusted code to execute with privileged access.

Add behavioral monitoring to build environments

Look for anomalous outbound connections during builds, unusual environment variable access, and unexpected token usage. Correlate these signals with recent dependency changes or pipeline modifications.

Final Thoughts

Defending against this requires extending security thinking upstream, into the development environment, the dependency graph, and the build pipeline. These are not traditionally security-owned spaces. That is precisely what makes them effective entry points.

Security monitoring must evolve to treat the software supply chain as part of the attack surface. Understanding how trusted components can be turned against you is the first step toward building defenses that can keep pace.

← Back to Insights