fix(deps): treat packages with same version but different dependencies as separate packages

[knqyf263]

Overview

Currently, Trivy treats packages with the same version but different dependencies as duplicates and excludes them. This leads to inconsistent results when scanning the same project multiple times.

See #8775 for details.

Current Behavior

When scanning a project that has the same package version but with different dependencies, Trivy treats them as duplicates and excludes one of them. This results in non-deterministic output.

Example:

{
  "ref": "pkg:npm/@aws-crypto/[email protected]",
  "dependsOn": [
    "pkg:npm/@aws-sdk/[email protected]",
    "pkg:npm/@aws-sdk/[email protected]",
    "pkg:npm/[email protected]"
  ]
}

vs

{
  "ref": "pkg:npm/@aws-crypto/[email protected]",
  "dependsOn": [
    "pkg:npm/@aws-sdk/[email protected]",
    "pkg:npm/@aws-sdk/[email protected]",
    "pkg:npm/[email protected]"
  ]
}

Expected Behavior

Packages with the same version but different dependencies should be treated as separate packages. This will ensure consistent results when scanning the same project multiple times.

Related Issues

• Similar issue in Java: bug(sbom): Duplicate SBOM packages for multi-module pom.xml files #7824

Discussed in #8775

[knqyf263]

Upon further consideration, I realized that this difference in the dependency graph also affects how parent packages are handled. In the example above, @aws-crypto/[email protected] actually has two separate instances with different downstream dependencies. Suppose @aws-sdk/client-sts is the parent package of one such @aws-crypto/[email protected]. Under that parent, the subtree might be:

@aws-crypto/[email protected] → @aws-sdk/[email protected]

or it might be:

@aws-crypto/[email protected] → @aws-sdk/[email protected]

See the diagram:

flowchart TD
  root --> clientStsA
  clientStsA["@aws-sdk/client-sts@3\.186\.4 (instance A)"]
  clientStsA --> cryptoUtilA
  cryptoUtilA["@aws-crypto/util@2\.0\.2 (instance A)"]
  cryptoUtilA --> utf8A
  utf8A["@aws-sdk/util-utf8-browser@3\.6\.1"]

  root --> clientLocation
  clientLocation["@aws-sdk/client-location@3\.186\.4"]
  clientLocation --> clientStsB
  clientStsB["@aws-sdk/client-sts@3\.186\.4 (instance B)"]
  clientStsB --> cryptoUtilB
  cryptoUtilB["@aws-crypto/util@2\.0\.2 (instance B)"]
  cryptoUtilB --> utf8B
  utf8B["@aws-sdk/util-utf8-browser@3\.186\.0"]

Loading

In other words, @aws-sdk/client-sts could also have two distinct instances. If we only look at a package’s direct dependencies, we can’t tell them apart—both instances list @aws-crypto/[email protected] as a direct dependency, even though their subgraphs differ. Therefore, we must compare entire subgraphs to determine whether two instances are truly identical.

Treating every unique package path as a separate instance—like npm does (e.g. node_modules/@aws-crypto/crc32/node_modules/@aws-crypto/util and node_modules/@aws-crypto/util)—is simpler, but it can suddenly expose what appear to be duplicate packages and confuse users. I currently believe it’s best to filter out any instances whose entire subgraphs are identical.