When Snyk flags a vulnerability in a scanned project, the first thing worth checking is where that package actually sits in the dependency tree. Running npm install express pulls in dozens of packages you never named yourself — qs, cookie, debug, send — any of which can carry a CVE. Snyk's scan output separates vulnerabilities in packages you declared directly in your manifest (package.json, pom.xml, Gemfile, requirements.txt) from vulnerabilities buried three, five, or ten levels deep in dependencies-of-dependencies. That split isn't cosmetic. It determines whether a one-line version bump closes the gap or whether you're waiting on a maintainer several hops away to cut a patched release. Here's how Snyk builds the dependency graph, matches known vulnerabilities to specific package versions, and calculates exposure paths for direct versus transitive dependencies — based on Snyk's publicly documented scanning approach.
What actually separates a direct dependency from a transitive one?
A direct dependency is any package your project's manifest file lists explicitly — the entries under dependencies in package.json, the <dependency> blocks in a Maven pom.xml, or the lines in a requirements.txt. A transitive dependency is anything pulled in because a direct dependency (or another transitive dependency) requires it, and it never appears in your manifest at all. In practice, the ratio skews heavily toward transitive: a project with 15-20 direct entries in package.json commonly resolves to several hundred, sometimes over a thousand, total packages once npm or Yarn walks the full tree. Snyk's own State of Open Source Security research has repeatedly found that the majority of known vulnerabilities in npm projects trace back to transitive packages rather than the ones developers deliberately chose, which is the core reason Snyk reports the two categories separately instead of a single flat vulnerability count.
How does Snyk build the dependency graph it scans?
Snyk parses the project's lockfile — package-lock.json, yarn.lock, pnpm-lock.yaml, Gemfile.lock, poetry.lock, go.sum, or the resolved Maven/Gradle dependency tree — rather than relying on the manifest alone, because the lockfile records the exact resolved version of every package, including cases where two branches of the tree pull in different versions of the same library. Running snyk test (or the equivalent CI integration) walks that resolved graph node by node, recording, for every package, which direct dependency introduced it and through how many intermediate packages. For monorepos and workspace setups such as npm workspaces, Yarn workspaces, or Lerna, Snyk builds a separate graph per workspace package, since two services in the same repo can resolve the same library to different versions depending on their own manifests. This graph is what makes path-level reporting possible later; without it, Snyk could only say a vulnerable package exists somewhere in the tree, not show the chain that put it there.
How does Snyk match a CVE to one specific package version and not another?
Snyk matches vulnerabilities using its own Vulnerability Database, which records each issue against a precise affected-version range rather than a package name alone. A CVE entry for lodash, for example, is stored as affecting something like >=1.0.0 <4.17.19, so a project pinned to lodash@4.17.20 is correctly marked as unaffected by that specific issue — CVE-2020-8203, a prototype-pollution flaw patched in that release — even though earlier or later CVEs against lodash might still apply. Snyk's in-house security research team curates this database by combining public sources, including the National Vulnerability Database, GitHub Security Advisories, and npm's and other ecosystems' own advisory feeds, with additional analysis to pin down the exact commit or release that introduced or fixed a flaw, since public CVE records are frequently vague about affected ranges. That extra step matters specifically for transitive exposure: if an affected-range boundary is wrong, every downstream calculation about which transitive packages in a tree are actually vulnerable inherits the error.
How does Snyk show the chain from your manifest to a vulnerable transitive package?
Snyk renders this as a dependency path, often labeled "Introduced through" in the CLI and web UI, showing the full chain from a project's direct dependency down to the flagged package — for example, your-app > express@4.16.0 > qs@6.5.2, where qs is the transitive package actually carrying the vulnerability. Because the same vulnerable version of a package can be pulled in by more than one direct dependency at once, Snyk counts and reports each path separately rather than collapsing them into a single finding; a project can show one vulnerable package version but three distinct paths into it, each of which may need its own remediation decision if a single blanket upgrade doesn't cover all three. This path data also feeds Snyk's fix tooling directly: knowing that qs@6.5.2 arrived via express@4.16.0 is what lets Snyk suggest "upgrade express to 4.17.3" as a fix for a package that was never installed directly.
Why does the same vulnerability get rated differently across two projects in Snyk?
Snyk's Priority Score, not the raw CVSS base score, is what determines the severity ranking shown in scan results, and that score weighs more than the vulnerability itself. Alongside CVSS, it factors in exploit maturity (whether public exploit code exists), whether an upstream fix is already available, and, for supported languages including Java, JavaScript/TypeScript, and Python, function-level reachability analysis that checks whether the calling project's own code actually invokes the vulnerable function at all. A high-CVSS flaw in a transitive dependency that a codebase never calls into can score materially lower in Snyk's prioritization than a moderate-CVSS flaw in a function called on every request, which is why an identical CVE can appear as high priority in one project and much lower in another, even when both are scanned against the same Snyk Intel data.
How does Snyk's fix advice differ for direct versus transitive vulnerabilities?
For a direct dependency vulnerability, Snyk's remediation is typically a straightforward version bump in the manifest itself, and snyk fix or a Snyk-generated pull request can apply that change automatically in most cases. For a transitive vulnerability, the fix usually isn't a manifest edit at all: Snyk instead looks for the minimum version bump to the direct parent dependency that would pull in a patched version of the transitive package, and if no parent upgrade resolves it cleanly, it surfaces manifest-level override mechanisms instead — npm's overrides field, Yarn's resolutions, or pnpm's overrides — each of which forces a specific transitive package version across the whole tree without waiting on every intermediate maintainer to republish. Snyk deprecated its older binary-patching feature, snyk protect, in 2023 in favor of these native package-manager override mechanisms, reflecting a broader shift toward fixes that live in the manifest rather than in a separate patch layer.
How Safeguard Helps
Understanding how a scanner like Snyk walks a dependency graph is genuinely useful, but exposure calculated purely from known-CVE matching is still bounded by what's already in a vulnerability database at scan time. It doesn't tell you whether a package was actually built from the source it claims, whether a maintainer account was compromised between releases, or whether a transitive dependency quietly changed hands and started behaving differently. Safeguard is built to sit alongside that layer of analysis rather than replace it. Safeguard continuously monitors the full dependency tree of a codebase, direct and transitive, for supply chain risk signals that fall outside CVE databases entirely: newly published package versions carrying suspicious install scripts, maintainer or ownership changes on packages already running in production, and drift between a package's published source and what actually ships in the registry artifact. For teams already relying on Snyk for known-vulnerability coverage, Safeguard adds provenance and integrity checks across that same dependency graph, so exposure isn't limited to what's already been assigned a CVE and disclosed publicly. If you want to see how that mapping looks against your own dependency tree, Safeguard's team can walk through a real scan of your repository.