sbomdiff ignores "group" leading to confusing output for NPM components

[Edward-Knight]

sbomdiff treats two components/packages as the same if their names are the same. This works for many pieces of software, but runs into issues in the NPM ecosystem in particular.

---

NPM offers two levels of name-spacing, an optional user level and the package name itself.

This is often represented in an SBOM by using group and name. For example, https://www.npmjs.com/package/@types/react is represented like so:

{
    "type": "library",
    "group": "@types",
    "name": "react",
    "version": "18.3.28",
    "purl": "pkg:npm/%40types/react@18.3.28",
    "bom-ref": "pkg:npm/%40types/react@18.3.28",
    "description": "TypeScript definitions for react"
}

Although this package is called "react", it's just some type definitions. This is usually written as @types/react. The "proper" react package https://www.npmjs.com/package/react is represented like so:

{
    "type": "library",
    "name": "react",
    "version": "18.3.1",
    "purl": "pkg:npm/react@18.3.1",
    "bom-ref": "pkg:npm/react@18.3.1",
    "description": "React is a JavaScript library for building user interfaces."
}

This has no group as it's a top-level package without using the optional user-level namespace.

---

sbomdiff doesn't differentiate between these two packages as the name key is the same for both. I found this issue as my project has three components named "react", (@floating-ui/react being the third), and when comparing the output of two different SBOM generators using sbomdiff I get incorrect output like:

[VERSION] react: Version changed from 0.27.7 to 18.3.1

even when no versions have changed. The exact output depends on the ordering of the components in the SBOM.

---

I recommend sbomdiff uses something like {group}/{name} as a key for packages (or just {name} where group is unset) to help disambiguate these cases. It would be even better if it could detect if the chosen key is unique within the SBOM and either correct and use a unique key or warn about this situation.

---

Thank you for the tool, I find it really useful! Before I was trying to diff JSON documents and found it very painful 😅

[anthonyharrison]

@Edward-Knight Thanks for your comment and support.

sbomdiff is designed to be very simple and agnostic to both the format of the SBOM and the ecosystem of the components. It's primary purpose was to detect achanges in versions of a component between SBOMs - the subtlies of npm in terms of distinuishing betwwen types and librairies isn't detected due to the simple comparison being performed

Group is a cycloneDX only attribute and as sbomdiff has to work for both SPDX and CycloneDX SBOMs, I can't assume that the group attribute is present. Howver, I agree that improving the handling of multiple versions of the same package in an SBOM (often seem in npm SBOMs!), would be a useful improvement. This would require that packages are now handled asa tuple (name, version) rather than just a name.

Note that if the group attribute is to be handled, this would require a change to the underlying library lib4sbom which is used to do all of the SBOM parsing.

[Edward-Knight]

Group is a cycloneDX only attribute and as sbomdiff has to work for both SPDX and CycloneDX SBOMs

Ah yeah, I forgot about non-CyclondeDX formats! That does make my proposed change a fair bit harder as you point out...

Howver, I agree that improving the handling of multiple versions of the same package in an SBOM (often seem in npm SBOMs!), would be a useful improvement. This would require that packages are now handled asa tuple (name, version) rather than just a name.

I think a bit of code that warns if a "name" is non-unique in a given SBOM would be good - it would help avoid the confusion of versions seeming to change when they don't