Software Supply Chain Attacks Are Hiding in Your Dependencies

Applications commonly contain direct and transitive dependencies. Direct dependencies are explicitly selected by developers, while transitive dependencies are introduced by other packages. As dependency trees grow, maintaining visibility into every component becomes increasingly difficult.

Attackers exploit this complexity through compromised maintainer accounts, malicious package releases, typosquatting, and dependency confusion. A package may retain its legitimate name and distribution channel even after its publishing credentials have been compromised.

CI/CD pipelines introduce additional risk because package installation and build processes may execute code with access to environment variables, repository credentials, or deployment resources.

Software Composition Analysis (SCA) tools identify known vulnerabilities and help organizations track dependency versions. However, malicious packages may not have a published CVE or security advisory.

A Software Bill of Materials (SBOM) provides an inventory of software components, but it does not establish that those components are trustworthy. Organizations should combine dependency inventories with integrity verification, controlled package sources, restricted publishing permissions, and monitoring of unexpected changes.

The OWASP Software Component Verification Standard provides guidance for establishing component verification practices.

Security teams should maintain visibility into production dependencies, enforce approved package registry configurations, and review new or unexpected components. Lockfiles and integrity checks can improve reproducibility, while package signatures and provenance attestations provide additional evidence about artifact origin and integrity.

Build pipelines should follow least-privilege principles. Credentials must be restricted to the processes that require them, and untrusted code should not have access to privileged release workflows.

These controls complement broader security investments. As discussed in Why Spending More on Cybersecurity Won't Save You From a Breach, security effectiveness depends on the controls implemented and validated, not simply the resources allocated.

Modern applications rely on third-party libraries and open-source packages. These components often introduce additional dependencies, known as transitive dependencies, which developers may not directly review or even know are present.

For example, an application might use a trusted logging library that depends on another package. If an attacker compromises that package and publishes a malicious version, the application could include the malicious code during its next build—even when its own source code remains unchanged.

The risk increases when dependency versions are not controlled. Automatically downloading updated packages can introduce vulnerable or compromised components without a dedicated code review.

Organizations should maintain a Software Bill of Materials (SBOM) to identify the components used in their applications. Dependency lockfiles, version pinning, package integrity checks, and continuous vulnerability scanning help reduce the risk of malicious or vulnerable packages reaching production.

Software supply chain security extends beyond identifying vulnerable libraries. Organizations must understand what enters their development environments, establish confidence in component integrity, and limit the impact of compromised dependencies.

The security of an application depends not only on the code an organization develops, but also on the components and processes used to build and distribute it. However, even trusted software can become a delivery mechanism for malicious code when vendors or distribution systems are compromised. In the another article, When Trusted Software Becomes the Attack Vector, we examine how these attacks occur and how organizations can reduce the risk.