Why Your Build Pipeline Is Already Compromised by Third-Party Dependencies

TLDR: Supply chain attacks are no longer theoretical, as demonstrated by recent compromises of high-profile packages like libxz and PyTorch-nightly. This talk introduces Dependant, a tool that enforces strict admission control and security scanning on third-party dependencies before they hit your build environment. By treating dependencies as untrusted inputs and applying automated policy checks, you can significantly reduce the risk of malicious code injection in your CI/CD pipeline.

Modern software development relies on a massive, interconnected web of third-party code. When you run a build, you are effectively executing thousands of lines of code written by strangers, often without any meaningful verification. Attackers have caught on to this reality, shifting their focus from exploiting application vulnerabilities to poisoning the supply chain itself. If an attacker can compromise a single, widely-used dependency, they gain a foothold in every environment that pulls that package.

The Mechanics of a Supply Chain Breach

The core of the problem is the implicit trust we place in package managers. Whether you are using pip, npm, or cargo, the default behavior is to pull the latest version of a package and its dependencies, often without verifying the provenance or integrity of the code. Attackers exploit this by using techniques like dependency confusion or by simply injecting malicious code into a legitimate package update.

In the case of PyTorch-nightly, attackers uploaded a malicious package with the same name as a legitimate dependency to the Python Package Index (PyPI). Because the malicious package had a higher version number, the build system automatically pulled the attacker's code instead of the real one. Once the malicious code executes in your build environment, it can exfiltrate environment variables, steal secrets, or inject backdoors into your production binaries.

Moving Beyond Simple Provenance

Verifying provenance is a necessary first step, but it is insufficient. Knowing that a package was signed by a specific developer does not guarantee that the code is free of vulnerabilities or malicious intent. We need to move toward a model of continuous, automated admission control.

Dependant addresses this by acting as a gatekeeper between the public internet and your internal artifact registries. Instead of allowing developers to pull directly from upstream, all requests must pass through a series of automated checks. These checks can include:

• Package Maturity: Is the package widely used and actively maintained?
• Vulnerability Scanning: Does the package have known CVEs?
• License Compliance: Does the package license align with your organizational requirements?
• Threat Intelligence: Does the package exhibit suspicious behavior or have a history of security issues, as tracked by services like socket.dev?

By implementing these checks as code, you can enforce security policies that are consistent across all your projects.

Implementing Admission Control in Your Pipeline

For a pentester, the goal is to identify where these checks are missing. During an engagement, look for build pipelines that pull dependencies directly from public registries without any intermediate proxy or scanning. If you can identify a package that is used by the target but lacks a clear security review process, you have a potential entry point.

The implementation of these controls in Python is straightforward. You can define custom policies that run as part of your CI/CD process:

def prep_admission_control_check(package):
    # Check if the license matches our approved list
    if not check_package_license(package):
        raise SecurityException("License not approved")
    
    # Query external APIs to verify package health
    if not check_package_maintainer_quality(package):
        raise SecurityException("Package maintainer quality check failed")

When a developer requests a new package, the system should require a justification and a manual review if the package is new or has a low trust score. This adds a small amount of friction, but it is a necessary trade-off to prevent the silent, automated inclusion of malicious code.

The Defensive Reality

Defending against supply chain attacks requires a shift in mindset. You must assume that any third-party code is potentially compromised. This means implementing network-level controls to prevent your build servers from reaching out to unauthorized registries. It means using tools like osv.dev to continuously monitor your dependencies for newly discovered vulnerabilities.

The most effective defense is to minimize your attack surface by reducing the number of dependencies you use. Every new package you add is a new potential vector for an attacker. Before adding a dependency, ask yourself if the functionality is worth the risk. If you must use it, ensure it is vetted, scanned, and pinned to a specific, verified version.

Supply chain security is not a one-time configuration; it is an ongoing process of monitoring, verification, and policy enforcement. As we continue to build more complex systems, the ability to control and audit our dependencies will become a critical component of any mature security program. Stop blindly trusting the code you pull from the internet, and start treating your dependencies with the same level of scrutiny you apply to your own production code.