Datadog Supply Chain Firewall: Block Malicious npm and pip Packages Before They Install

Supply chain attacks against package registries have followed a consistent pattern: publish a malicious package with a plausible name (typosquatting, dependency confusion, package takeover), and wait for developers to install it. The attack surface is the install command itself — by the time the malicious code executes, the package is already on the developer’s machine.

Datadog Supply Chain Firewall (SCF) moves the detection point earlier: it intercepts the install command, evaluates the package against multiple threat databases, and blocks installation if the package matches known malicious patterns. The tool is open-source, supports npm, pip, and poetry, and integrates with Datadog Code Security for organization-wide policy enforcement.

How It Works

Supply Chain Firewall installs as a wrapper around the package manager’s install command. When a developer runs npm install, pip install, or poetry add, SCF intercepts the request before it reaches the registry, evaluates the requested packages, and either allows or blocks the installation.

The evaluation pipeline runs three checks in parallel:

GuardDog: Datadog’s open-source static analysis engine for package security. GuardDog scans package code for specific patterns: exfiltration calls during install scripts, unusual network connections, obfuscated code, credential-harvesting patterns. The analysis runs on the package’s install scripts and top-level code — the parts that execute at install time.

Malicious Software Packages Dataset: A curated dataset of packages that have been identified as malicious and reported to package registries or security researchers. This is the blocklist layer — known-bad packages are blocked immediately without requiring static analysis.

Datadog Security Research: Datadog’s internal threat intelligence feed. This layer adds packages identified through Datadog’s own research that may not yet appear in public datasets — zero-day supply chain threats and newly-identified campaign patterns.

If any check returns a positive signal, SCF blocks the install and presents the reason to the developer. The developer can override the block with explicit confirmation, add the package to an allowlist, or report a false positive.

What It Catches

npm worm attacks (the Shai-Hulud 2.0 pattern from earlier this year): npm packages that contain postinstall scripts that modify other installed packages, propagating malicious code through the dependency graph. GuardDog’s pattern matching catches the propagation logic before the worm executes.

Credential harvesting: Packages that, at install time, read environment variables, .npmrc files, credential stores, or SSH keys and send them to an external endpoint. This is one of the most common malicious package patterns — it runs at install time, not at application runtime, so it bypasses most runtime security scanning.

Dependency confusion attacks: Package names that match internal package names in organizations with public-registry misconfiguration. The Malicious Software Packages Dataset and custom blocklists can include internal-namespace reservations.

Installation-time malware: Packages with preinstall, install, and postinstall scripts that download additional payloads, modify system files, or establish persistence. These execute immediately on npm install regardless of whether the package is ever imported.

Organization-Wide Enforcement via Datadog Code Security

Individual developer installation is one threat vector. The higher-risk vector is CI/CD pipelines that install packages in production build environments — Dockerfile builds, GitHub Actions runners, deployment pipelines.

Datadog Code Security integration extends SCF from individual developer machines to the organization’s build infrastructure. When SCF detects a blocked package in any environment where Datadog Code Security is deployed, the incident is visible in the security dashboard with:

• The blocked package name and version
• The machine or runner that attempted the install
• The triggering detection rule
• The pipeline job or developer session that initiated the install

This creates an audit trail for supply chain attempts across the organization, not just on individual machines.

Custom Allowlists and Blocklists

Teams with internal packages, non-public registries, or known-clean packages that SCF flags as suspicious can add custom rules:

# .supply-chain-firewall.yaml
allow:
  - name: "my-internal-package"
    registry: "internal.registry.example.com"
  - name: "known-safe-package"
    version: ">=2.0.0"
block:
  - name: "rejected-vendor-package"
    reason: "not approved for production use"

Custom blocklists allow security teams to enforce package usage policies beyond malware detection — blocking packages with known vulnerabilities, packages that haven’t passed internal security review, or packages from vendors that haven’t completed procurement.

The Open-Source Model

Supply Chain Firewall is Apache 2.0 licensed. The GuardDog evaluation engine is also open-source, which means the detection logic is inspectable and extensible. Security teams can contribute detection patterns, submit false positives, and extend the analysis rules for their specific threat models.

The Malicious Software Packages Dataset is maintained by Datadog Security Research with community contributions. New malicious package reports can be submitted via the dataset’s GitHub repository.

Source: Datadog

Content created with AI assistance and reviewed for accuracy.