When scanning a folder containing Ghostscript Windows binaries (gswin32c.exe, gsdll32.dll), Syft identifies them but assigns a non-canonical CPE that Grype later cannot match to any known CVEs.

Affected versions

Syft: 1.33.0 (latest at time of writing)
Platform: Windows 10 / 11 x64

Steps to reproduce

Download Ghostscript Windows binaries, e.g. from
https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs9540

It contains gswin32c.exe, version 9.54.0, which is vulnerable, see: WID-SEC-2025-2101.

Generate an SBOM:

syft dir:C:\path\to\ghostscript-9.54.0 -o cyclonedx-json > sbom.cdx.json
Inspect the Ghostscript components in the SBOM.
Syft emits GPL_Ghostscript:GPL_Ghostscript as vendor/product, and no purl.
Grype (or other similar tools) cannot therefore report any vulnerabilities.

{
  "name": "GPL_Ghostscript",
  "version": "9.54.0",
  "cpe": "cpe:2.3:a:GPL_Ghostscript:GPL_Ghostscript:9.54.0:*:*:*:*:*:*:*"
}

The file’s version info (from Windows):

CompanyName: Artifex Software, Inc.
ProductName: GPL Ghostscript
ProductVersion: 9.54.0

Expected behavior

The correct canonical identifiers are:

Vendor: artifex
Product: ghostscript

Example CPE: cpe:2.3:a:artifex:ghostscript:9.54.0:::::::*
Example purl: pkg:generic/ghostscript@9.54.0

Output example:

"cpe": "cpe:2.3:a:artifex:ghostscript:9.54.0:*:*:*:*:*:*:*",
"purl": "pkg:generic/ghostscript@9.54.0",

Proposed fix

Normalize the PE cataloger output for Ghostscript binaries to use canonical vendor/product, mapping GPL_Ghostscript → artifex:ghostscript.

Impact

Because of this mismatch, users who bundle Ghostscript executables or DLLs in their products get a false “no vulnerabilities found” result, even when shipping known vulnerable versions.

This is not only about Ghostscript — it’s an example of a more general gap in the PE cataloger’s CPE normalization logic.
The cataloger should leverage CompanyName (vendor) and ProductName (product) separately, apply canonical normalization, and/or use a vendor alias mapping.