What is dependency chain abuse (OWASP CICD-SEC-3)?

Dependency chain abuse, CICD-SEC-3 in the OWASP Top 10 CI/CD Security Risks, is an attacker's ability to exploit how engineering workstations and build systems fetch dependencies, so a malicious package is pulled and often run immediately. It is about the fetching process, not about known bugs in packages you chose.

How is this different from a vulnerable dependency?

Most teams scan for packages with known vulnerabilities. OWASP points at a different gap: controls over the process that decides which package gets downloaded. A misconfigured client may fetch something other than what the engineer intended, and install scripts can run it the moment it lands. Scanning for known flaws will not flag a package that was malicious from the first day.

What are the four attack vectors?

OWASP lists four.

• Dependency confusion. An attacker publishes a package in a public repository using the same name as one of your internal packages, hoping clients choose the public one.
• Dependency hijacking. The attacker takes over a maintainer's account on a public repository and uploads a new, malicious version of a widely used package.
• Typosquatting. A package with a name close to a popular one, waiting for a misspelling.
• Brandjacking. A malicious package named to look like it belongs to a trusted brand.

Constructed example for confusion: your company has an internal package called acme-billing-utils, used by many services. Someone publishes a package with that name to the public registry at a higher version number. A build whose configuration allows both sources picks the higher version and runs its install script on the build server, which holds deploy credentials.

What is the impact?

OWASP says the aim is to run malicious code on the host that pulls the package, either a developer workstation or a build server. From there it can steal credentials and move sideways, or the code can make its way to production from the build server. The malicious package often keeps the original working behavior, which lowers the chance of discovery.

What does OWASP recommend?

The guiding principle: no client that pulls packages should be allowed to fetch directly from the internet or untrusted sources.

• Pull third-party packages through an internal proxy, which gives a place for controls and records for investigation.
• Where possible, disallow direct pulls from external repositories. Point clients at internal repositories holding pre-vetted packages, and enforce that client configuration.
• Turn on checksum and signature verification.
• Avoid pulling the latest version. Pin pre-vetted versions or ranges, and lock them with your package manager's tools.
• Use scopes: register private packages under your organization's scope, reference them by scope, and force that scope to resolve only from your internal registry.
• Run installation scripts in a separate context with no access to secrets and other sensitive resources.
• Keep package manager configuration files, such as .npmrc, in the project repository so they override insecure settings on the client.
• Avoid publishing names of internal projects in public repositories.

OWASP also says complete prevention is far from trivial, given how many package managers and configurations exist. So add detection, monitoring and mitigation so an incident is found fast and does limited damage, and harden the related systems per CICD-SEC-7.

How to check or apply this

1. Inventory every package manager your teams use, and where each resolves packages from.
2. Reserve your internal package names and scopes in the public registries, and set resolution so internal scopes never go outward.
3. Route all external fetches through a proxy and block direct internet pulls from build runners.
4. Commit lockfiles and fail the build when they drift.
5. Verify checksums and signatures where the ecosystem supports them.
6. Run installs on runners with no deploy credentials, and give publish keys only to the release stage.
7. Alert when a build resolves a package from a source it has never used.

Where Safeguard fits

Safeguard's SBOM and dependency scanning gives you the inventory that step 1 needs, and policies and gates can block a pull request that introduces a package outside your approved set. The Gold open source registry and the free in-browser scan at gold.safeguard.sh/scan (100 dependencies) offer a quick look at what a manifest pulls in.

Quick check

Sources

• OWASP Top 10 CI/CD Security Risks: CICD-SEC-3 Dependency Chain Abuse
• OWASP Top 10 CI/CD Security Risks, overview

Last reviewed: 18 October 2026.