# Name vs Group in CycloneDX SBOMs **URL:** \ **Category:** Syft\ **Created:** [May 30, 2024, 1:45pm UTC](https://anchorecommunity.discourse.group/t/name-vs-group-in-cyclonedx-sboms/21 "2024-05-30T13:45:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\ **Post date:** [May 30, 2024, 1:45pm UTC](https://anchorecommunity.discourse.group/t/name-vs-group-in-cyclonedx-sboms/21/1 "2024-05-30T13:45:58Z")
Right now, when encoding an NPM package in CycloneDX (or Syft JSON), syft will make a name like `@octokit/core` for [@octokit/core - npm](https://www.npmjs.com/package/@octokit/core). However, other tools, like `npx -y @cyclonedx/cyclonedx-npm`, will write this component with the name `core` and the group `@octokit`. (Both tools make the correct PURL.) This causes issues because when Syft decodes the cdx JSON, it doesn’t know to rebuild the compound package name `@octokit/core`, and we end up with an NPM package just called `core` which doesn’t tell us anything and is wrong. (This in turn causes incorrect matching in Grype, e.g. [@jridgewell/gen-mapping incorrectly attributed GHSA-8rmg-jf7p-4p22 · Issue #1886 · anchore/grype · GitHub](https://github.com/anchore/grype/issues/1886)). One of the general tenets of Syft’s SBOM exporting is that we should be able to do a cycle of export / import / export and end up with the same SBOM we started with. In order to keep this tenet, should we make Syft _always_ write `@foo/bar` style npm packages using name + group in CycloneDX JSON? (This discussion was previously started at [Syft is dropping the "group" field from imported CycloneDX · Issue #1202 · anchore/syft · GitHub](https://github.com/anchore/syft/issues/1202) where it stalled out years ago, so I wanted to restart it and see if the new venue would help.) ---
**Author:** ![willmurphy](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/willmurphy/32/12_2.png) [@willmurphy](https://anchorecommunity.discourse.group/u/willmurphy)\ **Post date:** [May 30, 2024, 2:05pm UTC](https://anchorecommunity.discourse.group/t/name-vs-group-in-cyclonedx-sboms/21/2 "2024-05-30T14:05:13Z")
It’s also worth asking about how JARs should be described, since they also have a group property. Right now, running `syft -o cyclonedx-json spring-core-5.3.0.jar` produces a component in the SBOM with a PURL like `pkg:maven/org.springframework/spring-core@5.3.0` but no `group` field. This also seems incorrect. I think one of the outcomes of this discussion might be a list of package types that use the `group` field in CycloneDX. Here’s a link to the CycloneDX spec on the subject: [CycloneDX v1.6 JSON Reference](https://cyclonedx.org/docs/1.6/json/#components_items_group) It seems to me to clearly imply that the Group ID for JARs should be in there: > The grouping name or identifier. This will often be a shortened, single name of the company or project that produced the component, or the source package or domain name. Whitespace and special characters should be avoided. Examples include: apache, org.apache.commons, and [apache.org](http://apache.org). Besides NPM and Maven, are there other package managers that are namespaced into groups? ---
**Author:** ![kzantow](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/kzantow/32/17_2.png) [@kzantow](https://anchorecommunity.discourse.group/u/kzantow)\ **Post date:** [May 30, 2024, 2:38pm UTC](https://anchorecommunity.discourse.group/t/name-vs-group-in-cyclonedx-sboms/21/3 "2024-05-30T14:38:20Z")
I think there shouldn’t be a problem with the encode-decode if we do a specific thing for a specific ecosystem. In other words: for NPM we know that a name of the form `@some/thing` is a group and name. We know for Java Maven has a `groupId` and an `artifactId`, which correlate to these CycloneDX fields. So we can special case these package types to extract the group on the way out and just reverse it on the way in, right? I don’t really see how it’s any more contentious than that.