Monorepo Dependency Security — Vulnerability Scanning Across Packages

A monorepo can look like one repository, but security teams should treat it as many applications living under one roof. One repo may contain 10 frontend packages, 5 backend services, 3 shared utility libraries, 2 mobile apps, and one root lockfile that does not tell the full story by itself.

Monorepo dependency security means scanning the root dependency graph, every workspace package, shared libraries, lockfiles, and generated SBOMs. If you scan only one file, you may miss the vulnerable package that ships in production.

Why Monorepos Create Unique Vulnerability Challenges

Monorepos centralize multiple packages, apps, services, and libraries inside one repository. This improves code sharing, dependency alignment, refactoring, CI caching, and cross-team collaboration. It also creates a security problem: one repository can contain many different dependency trees, owners, deployment targets, and risk profiles.

A typical JavaScript or TypeScript monorepo may include apps/web, apps/admin, apps/api, packages/ui, packages/auth, packages/logger, and packages/config. Each package may have its own package.json. Some packages are deployed to production. Some are internal libraries. Some are build-only tools. Some are used by every app. A vulnerability in one package can affect one app, many apps, or the whole repo depending on how dependency relationships are structured.

The biggest issue is shared code. If packages/auth depends on a vulnerable version of jsonwebtoken, every application that imports packages/auth may be affected. If packages/ui uses a vulnerable utility such as lodash, every frontend app that consumes that UI package may inherit the same risk. If a build tool dependency is compromised, the risk may appear during CI/CD rather than runtime.

Real CVEs show why this matters. CVE-2021-23337 affected lodash through command injection in template handling. CVE-2022-31129 affected moment through inefficient parsing that could cause denial of service. CVE-2022-23529 affected jsonwebtoken and could allow remote code execution in vulnerable configurations. A monorepo does not reduce the impact of these vulnerabilities unless dependency ownership, scanning, and remediation are well managed.

A monorepo is one Git repository, not one dependency risk boundary.

Warning: Do not assume a clean root scan means every workspace package is safe. Workspace-specific dependencies can still introduce vulnerabilities.

The Hoisting Problem — Why Scanning One File Is Not Enough

Dependency hoisting happens when package managers install shared dependencies higher in the directory tree, often at the root node_modules, so multiple workspaces can use one copy. npm and Yarn workspaces commonly use hoisting behavior, while pnpm uses a stricter content-addressable store and symlinked layout. The goal is efficiency, but the security consequence is that the installed dependency may not live beside the package that uses it.

This creates confusing scan results. A package in packages/web may rely on a dependency physically installed at the root. If you scan only packages/web/package.json, you may miss the exact installed version. If you scan only the root lockfile, you may see the vulnerable package but lose context about which workspace actually uses it. If you scan only root package.json, you may miss dependencies declared inside individual workspace manifests.

The right approach is to scan both the root and workspace level. For npm workspaces, review the root package-lock.json and every workspace package.json. For Yarn, review yarn.lock plus workspace manifests. For pnpm, review pnpm-lock.yaml and workspace manifests. For mixed monorepos, also check pom.xml, build.gradle, requirements.txt, go.sum, Gemfile.lock, Cargo.lock, and SBOM files where present.

# Find all package manifests in a JavaScript/TypeScript monorepo
find . -name "package.json" -not -path "*/node_modules/*"

# Find common lockfiles
find . \( -name "package-lock.json" -o -name "yarn.lock" -o -name "pnpm-lock.yaml" \) \
  -not -path "*/node_modules/*"

Hoisting also affects remediation. If one vulnerable version is hoisted and shared, fixing that one version can remove the vulnerability across many packages. But if several packages pin incompatible versions, the repo may contain multiple copies of the same package. Security teams need to know whether they are dealing with one vulnerable version or several.

Tip: Treat the root lockfile as the installation truth, but treat each workspace manifest as the ownership and usage map.

The Right Scanning Strategy for Your Monorepo

There is no single scan mode that fits every monorepo. A small repository with 4 packages can scan everything on every pull request. A large repository with 200 projects may need affected-only scanning in CI and full scheduled scans at night. The best strategy combines speed for developers with complete coverage for security.

Root-only scans are fast, but they may hide ownership. Per-workspace scans give clearer accountability, but they can be slower and may duplicate findings. Aggregate SBOM generation is best for audits and fleet visibility, but it requires tooling discipline. A mature monorepo security process usually combines all three: root lockfile scan, workspace manifest scan, and scheduled aggregate SBOM generation.

Monorepo vulnerability management should also classify packages by deployment risk. A package that builds a public API has different urgency than a Storybook-only package. A shared auth library has higher blast radius than a small internal utility used by one admin tool. Scan results should include package type, owner, deployment target, and whether the package ships to production.

The most practical approach is simple: scan affected packages on pull requests, scan all packages on a schedule, and generate an SBOM for release builds. This gives developers fast feedback without losing fleet-wide coverage.

Nx and Turborepo — Integrating Security Into Your Build System

Nx and Turborepo help teams run tasks across monorepos. Security scanning should become one of those tasks. Instead of creating a separate script outside the build system, add dependency scanning as a project target. This makes it easier to run scans for affected projects, cache results, and keep scanning consistent across applications and packages.

Nx supports affected commands that run tasks only for projects changed by a pull request and projects that depend on those changes. That is useful for CI because a small change in packages/ui may affect multiple frontend apps, while a change in one isolated service may not require scanning the entire repo.

{
  "targetDefaults": {
    "security-scan": {
      "cache": false,
      "inputs": [
        "{projectRoot}/package.json",
        "{workspaceRoot}/package-lock.json",
        "{workspaceRoot}/yarn.lock",
        "{workspaceRoot}/pnpm-lock.yaml"
      ]
    }
  }
}

# Run security scan only for affected Nx projects
nx affected -t security-scan --base=origin/main --head=HEAD

Turborepo uses turbo.json to define tasks. You can add a security task that depends on workspace package files and lockfiles, then use filters to run it for selected packages or changed packages. Turborepo’s filtering lets teams scope tasks to packages instead of running everything on every commit.

{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "security-scan": {
      "cache": false,
      "inputs": [
        "package.json",
        "package-lock.json",
        "yarn.lock",
        "pnpm-lock.yaml"
      ],
      "outputs": [
        "security-reports/**"
      ]
    }
  }
}

# Run a scan for one package
turbo run security-scan --filter=web

# Run scans for packages changed since main
turbo run security-scan --filter=[origin/main]

Warning: Affected-only scanning is not enough by itself. New CVEs can appear in unchanged packages, so run scheduled full scans too.

Dependency Deduplication — When One Fix Fixes Everything

Dependency deduplication is one of the biggest security advantages of monorepos. When several packages use the same version of a dependency, a single upgrade can remove a vulnerability across many apps. The same centralization that increases blast radius can also speed remediation when managed correctly.

For example, if many packages use lodash, upgrading the shared resolved version may fix every affected workspace at once. If several apps use jsonwebtoken, a repo-wide override can force a fixed version while teams update direct dependencies properly. This approach is useful during urgent remediation, but it should not replace long-term package maintenance.

Use package-manager override features carefully. npm supports overrides. Yarn supports resolutions. pnpm supports overrides in workspace settings. These features can force a transitive dependency version across the repo, which is useful when a vulnerable nested dependency has a fixed release but the parent package has not updated yet.

npm overrides

{
  "overrides": {
    "lodash": "4.17.21",
    "jsonwebtoken": "9.0.2"
  }
}

Yarn resolutions

{
  "resolutions": {
    "lodash": "4.17.21",
    "jsonwebtoken": "9.0.2"
  }
}

pnpm overrides

overrides:
  lodash: 4.17.21
  jsonwebtoken: 9.0.2

After applying overrides, reinstall dependencies, regenerate the lockfile, run tests, and scan again. Overrides can fix vulnerabilities quickly, but they can also break packages if the forced version is incompatible. Always document why the override exists and remove it once upstream packages update.

Tip: During a critical CVE, use overrides as an emergency control, then follow up with normal dependency upgrades and tests.

CI/CD — Scanning Only Changed Packages

CI/CD needs a balance between speed and coverage. Developers should not wait 30 minutes for a full monorepo scan on every small change. Security teams also cannot rely only on changed-package scans because new vulnerabilities are disclosed after code is merged. The answer is a two-track model: affected scans for pull requests and full scans on a schedule.

For pull requests, run scans only for packages touched by the change and packages that depend on them. Nx and Turborepo can help here because they understand project graphs and task filtering. For scheduled scans, run across the full repository so new CVEs are detected even if no one changed the affected package that week.

name: Monorepo Security Scan

on:
  pull_request:
  push:
    branches: [ main ]
  schedule:
    - cron: "0 3 * * 1"

jobs:
  affected-scan:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Find workspace manifests
        run: find . -name "package.json" -not -path "*/node_modules/*"

      - name: Run npm audit for workspaces
        run: npm audit --workspaces --audit-level=high

      - name: Run Nx affected security task
        run: npx nx affected -t security-scan --base=origin/main --head=HEAD

For Turborepo, use filters to scope security tasks. Keep a separate scheduled workflow that scans all packages and uploads reports or SBOMs to your central vulnerability system.

# Turborepo changed-package scan
turbo run security-scan --filter=[origin/main]

# Full scheduled scan
turbo run security-scan

This model supports monorepo dependency security without blocking developer flow. Pull requests get fast feedback, while scheduled scans catch newly disclosed CVEs across packages that did not change.

How Vulert Fits Monorepo Security Workflows

Vulert helps teams monitor open source dependencies by analyzing manifest files and SBOMs against 458,000+ known CVEs. In a monorepo, each deployable app or workspace package can be uploaded as a separate application in Vulert. That gives service owners their own vulnerability view while keeping the whole repository visible to security and DevOps teams.

For JavaScript and TypeScript monorepos, upload the root lockfile plus workspace manifests where appropriate. For polyglot monorepos, upload each supported manifest file: package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, Pipfile.lock, poetry.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, or an SPDX/CycloneDX SBOM.

Vulert’s Dependency Health view groups CVEs by package. This matters in monorepos because one vulnerable package may create many findings across many workspaces. Instead of handling every alert separately, teams can see which upgrade removes the most risk across the repo.

Jira integration also helps route tickets to the team that owns each package or app. A frontend workspace vulnerability should go to the frontend owner. A shared auth library vulnerability should go to the platform or identity team. A backend service vulnerability should go to that service owner.

Key Takeaways

• Monorepos centralize code, but every workspace can still have its own dependency risk.
• Hoisting means scanning only one manifest may miss workspace usage or ownership context.
• Use a mix of root lockfile scanning, workspace manifest scanning, affected scans, scheduled full scans, and SBOM generation.
• Nx and Turborepo can run security tasks only for affected or filtered packages in CI.
• npm overrides, Yarn resolutions, and pnpm overrides can force fixed versions during urgent remediation.
• Vulert can support monorepo dependency security by monitoring workspace manifests and SBOMs with package-level fix guidance.

Frequently Asked Questions

1. Should I scan the root lockfile or each workspace package?

Scan both when possible. The root lockfile shows the resolved dependency graph, while each workspace manifest shows ownership and package intent. For large monorepos, use affected scans in pull requests and scheduled full scans for complete coverage.

2. How does dependency hoisting affect security scanning?

Hoisting can install a dependency at the root even when a workspace uses it. That means scanning only a workspace folder may miss the actual installed version, while scanning only root files may lose ownership context. Combine root lockfile scans with workspace manifest scans.

3. Can I use Vulert with a Nx or Turborepo monorepo?

Yes. Treat each deployable app or workspace package as a separate application where appropriate, and upload supported manifests or SBOMs. Vulert can help monitor vulnerable packages, provide fix guidance, and group findings by dependency.