fix(parser): five-path cap leaves gaps in the SBOM dependency graph

[sonukapoor]

Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.

Problem

upsertPackage in src/parsers/utils.ts caps stored dependency paths at five per package:

existing.paths = uniquePathArrays([...(existing.paths ?? []), ...(candidate.paths ?? [])]).slice(0, 5);

That bound is fine for remediation output, where a representative path is enough to explain why a package is present. It becomes visible once those paths are used to build a dependency graph, because any package reachable by more than five routes loses edges.

Concrete case

Scanning this repo with --sbom spdx --prod-only produces 51 DEPENDENCY_OF edges. Snyk's SPDX for the same repo produces 52. The single missing edge is:

semver@7.7.4 -> node-abi@3.89.0

semver@7.7.4 is genuinely reachable through node-abi, but its five recorded paths all run through jest:

["project","jest","@jest/core","@jest/reporters","istanbul-lib-instrument","semver"]
["project","jest","@jest/core","@jest/transform","babel-plugin-istanbul","istanbul-lib-instrument","semver"]
["project","jest","jest-cli","@jest/core","@jest/reporters","istanbul-lib-instrument","semver"]
["project","jest","@jest/core","@jest/reporters","@jest/transform","babel-plugin-istanbul","istanbul-lib-instrument","semver"]
["project","jest","@jest/core","jest-config","babel-jest","babel-plugin-istanbul","istanbul-lib-instrument","semver"]

There is a second effect worth noting. Paths come from loadNpmLockGraph, which is not prodOnly-aware, so under --prod-only a package can retain only paths that traverse packages excluded from the output. The parent lookup then finds nothing and the package ends up with no parent edge at all, which is what happens to semver above.

Why it matters

Dependency relationships are one of the seven NTIA minimum elements that Executive Order 14028 points to. Packages are always complete in our SBOM; only the edges between them can be partial. That is currently documented as a known limitation in website/docs/spdx.md, but a partial graph is a weaker artifact for the compliance audience SPDX serves.

Possible directions

Not yet decided, and each needs measuring before committing:

1. Raise or remove the cap. Simplest, but the bound exists to keep large trees manageable and the memory cost on a big monorepo needs measuring first.
2. Make path retention prodOnly-aware so a prod-only scan keeps prod-reachable paths rather than the first five found.
3. Keep the cap for remediation output but compute graph edges from the full lock graph separately, so SBOM completeness does not depend on a display-oriented bound.

Option 3 looks most promising because it decouples the two use cases, but it needs a look at what loadNpmLockGraph can expose without a second traversal.

Notes

• In-house: parser internals and per-package data structures.
• Related prior art on path completeness: fix: preserve multiple pnpm dependency paths for repeated package versions #335 (pnpm), feat: improve Yarn parser to preserve multiple dependency paths to the same package #421 (Yarn), feat: improve Bun parser to preserve multiple dependency paths to the same package #422 (Bun).

[sonukapoor]

Scale data, measured after filing.

The single missing edge on this repo understates the problem. Measured on examples/lit (@lit-internal/monorepo, 2060 packages in the SBOM, 2664 DEPENDENCY_OF edges):

• 110 of 2060 packages (5.4%) have no parent edge at all, not merely a reduced set of edges (the 111th is the root, which correctly has no parent).
• 38 of those are a second-or-later version of a name that appears multiple times, consistent with the five-path cap dropping routes.
• The remaining ~72 are single-version packages, which suggests a second contributing cause on workspace monorepos where recorded paths do not resolve against the root the same way.

So the failure mode is worse than "some edges missing": whole packages can be disconnected from the graph. That weakens the NTIA dependency-relationship element specifically on the large enterprise repos where an SBOM matters most.

website/docs/spdx.md has been updated to state the measured 5 percent figure rather than describing the limitation qualitatively.

Worth investigating the workspace-monorepo case separately when this is picked up: it may be a distinct bug from the path cap rather than the same one.