`-sp#` suffix treated as prerelease in version comparison

[ChristophRh]

Hello again,
I'm still having issues in creating a CycloneDX SBOM such that Grype finds the matching vulnerabilities, that obviously are in the database.
Vulnerability IDs:
CVE-2023-48242 - CVE-2023-48266

I was using "version": "V1500-SP2" which lead to this issue.
Now I tried many variations of the name like nexo-os nexo os nexo NEXO-OS and versions 1000 1300 1500-sp2
but found 0 vulnerability matches across 1 packages.
And it seems like type has to be "type": "application", otherwise it says 0 packages if type is "device", "operating-system" or "firmware".
That is how my simple CycloneDX looks like:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2025-11-10T10:00:00Z",
    "component": {
      "type": "device",
      "bom-ref": "Nexo-nutrunner",
      "manufacturer": {
        "name": "Bosch Rexroth AG"
      },
      "name": "Nexo-Cordless-Nutrunner",
      "version": "1500-sp2"
    }
  },
  "components": [
    {
      "type": "application",
      "bom-ref": "nexo-application",
      "name": "nexo-os",
      "version": "1500-sp2"
    }
  ]
}

It would be nice if you could try the same and give me feedback on what I'm doing wrong.
Best Regards

[kzantow]

It looks like you haven't included any CPEs, so Grype won't perform CPE matching. It looks like the other issue noted:
cpe:2.3:o:bosch:nexo-os:1500-SP2:*:*:*:*:*:*:*, I suggest building the CPE and including that with your component? This seems to work for me:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2025-11-10T10:00:00Z",
    "component": {
      "type": "device",
      "bom-ref": "Nexo-nutrunner",
      "manufacturer": {
        "name": "Bosch Rexroth AG"
      },
      "name": "Nexo-Cordless-Nutrunner",
      "version": "1500-sp2"
    }
  },
  "components": [
    {
      "type": "application",
      "bom-ref": "nexo-application",
      "name": "nexo-os",
      "version": "1500-sp2",
      "cpe": "cpe:2.3:o:bosch:nexo-os:1500-SP2:*:*:*:*:*:*:*"
    }
  ]
}

[ChristophRh]

Okay, I didn't know that Grype is completely dependent on CPEs.
I thought it would use "type", "name" and "version" information.

Regarding my second question on "type": "application", why doesn't it work to specify "type": "operating-system"?
In this case Nexo-OS is an operating system, according to its CPE as well.

[kzantow]

Grype is not dependent on CPEs, but in order to match by a package name, it needs to know the ecosystem to use. The package you've provided does not have any information that would help determine an ecosystem. Take, for example: postgres in NPM is a client, so reporting Postgres database vulnerabilities is not appropriate. If you supply a PURL, this will have enough to determine an ecosystem, but there isn't enough information elsewhere in a CycloneDX record for that as far as I know. Since you haven't provided a PURL, and there is no ecosystem, the only other matcher that will apply is by CPE.

As for the second question: depending on the component type, import may not consider the it to be a package in the data model, you can see the behavior here.

[ChristophRh]

Thanks for the explanation!

Regarding the component type I don't see the point why it is implemented like that.
Wouldn't it make sense to evaluate type operating-system as well by checking the CPE instead of just ignoring some types?

I don't know the details, so if there is good reason feel free to close this issue.
Best Regards

[ChristophRh]

I just found another problem, maybe a bug?
When I put NEXO OS version v1500 Grype does not report the vulnerabilities.
cpe:2.3:o:bosch:nexo-os:v1500:*:*:*:*:*:*:*

Other versions like v1000 - v1400 and v1500-SP1 work perfectly.
Even using v1500- is okay.

Maybe a problem in version comparison such that v1500 is ranked higher than v1500-SP2?
The vulnerabilities should be found in versions >= v1000 , <= v1500-SP2

[kzantow]

Regarding OS components: the issue is that Syft doesn't really have a place in the data model for OSes aside from the LinuxRelease, I think. We should be trying to capture more information from SBOMs not created by Syft, though, so, I would definitely be happy to figure out how to capture the operating system records in some meaningful way. We currently have a problem that there is data loss to the syft model, and we are keen to solve that. But some of the talk has been to store data in some format-specific passthrough, which wouldn't really help Grype then reading said data. I am not sure that an operating system falls under the "artifact" nomenclature, that we use, either. But we're definitely open for suggestions here. Maybe it would be fine, we just add package type to represent OSes. Though we then run into an issue that we have a separate Linux release, but maybe we can kick that can down the road to Syft 2.0.

[kzantow]

As for the version mismatch, I am not entirely sure what the issue is, but maybe the sp2 is being considered a prerelease somehow? I don't think it should be, if it is. I believe this will be falling-back to using the fuzzy version comparison, which is difficult to make work correctly for every possible version scheme people use. Definitely happy to understand why the particular v1500 seems greater than v1500-SP2, we would probably be happy to have a patch that fixes that assuming it doesn't break other comparisons in the tests.

[ChristophRh]

Thank you for the explanation!
From my side you can close the issue unless you want to keep it due to the mentioned problems.
Many Thanks for your help :)

[kzantow]

Apologies, this issue has evolved a bit. It sounds like we might have an issue comparing versions that may be possible to fix, although, it's tricky to understand what to do here: I did a little debugging and the version is being parsed as a semantic version and as I suspected, the sp2 portion is determined to be a prerelease due to the semantic version spec. I don't want that to get lost, since sp#, specifically, seems like it generally wouldn't be for a prerelease.

We also may want to modify the behavior to include operating system components. Would you mind opening a separate issue in the Syft repository for that? and we'll keep this one open to see if there's a reasonable solution to the version comparison.

[kzantow]

Doing a little bit of debugging, it looks like the go-version library is determining 1500-sp2 to be a semver, when constructing constraints. This is resulting in a semver constraint comparison due to this code setting it on the fuzzy matcher. We think a couple things might be done differently here: possibly a single number despite being technically semver should be treated differently. And we should probably have a way to indicate that sp# is a post release rather than a prerelease, but we will need to get input from the team about the right way to handle this.