标签：#vulnerabilityscanning

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-202