How to match MCUboot vulnerabilities when OSV uses a Go PURL for an embedded C component? #7271

Hi,

I am evaluating Dependency-Track 5.1.0 for continuous vulnerability monitoring of CycloneDX SBOMs generated for embedded C/C++ firmware.

I encountered an interesting case with MCUboot and would like to understand what the recommended component representation is, or whether this is currently a limitation of the available vulnerability data / matching.

Component in the SBOM

Our firmware contains MCUboot 1.7.2. We model the upstream MCUboot component in CycloneDX as:

pkg:github/mcu-tools/mcuboot@v1.7.2

with the CPE:

cpe:2.3:a:mcu-tools:mcuboot:1.7.2:*:*:*:*:*:*:*

This is an embedded C implementation of MCUboot, so representing it as a Go package would not accurately describe the component.

Dependency-Track imports the component correctly, but currently reports no vulnerabilities for it.

CVE-2024-32883

CVE-2024-32883 is relevant to MCUboot and is present in the Dependency-Track vulnerability database:

There is also an OSV entry GO-2024-2799.

I checked the Dependency-Track database and the alias correlation appears to work correctly. Both vulnerabilities belong to the same alias group:

There is also the following alias assertion:

OSV / GO-2024-2799 -> NVD / CVE-2024-32883

So Dependency-Track correctly knows that these vulnerability identifiers refer to the same issue.

Affected software representation

The interesting part is the affected software record associated with GO-2024-2799.

Dependency-Track has it stored as:

pkg:golang/github.com/mcu-tools/mcuboot

with:

VERSIONSTARTINCLUDING = 0

The component in our CycloneDX SBOM, however, is:

pkg:github/mcu-tools/mcuboot@v1.7.2

Therefore the identities used for matching are effectively:

SBOM:

pkg:github/mcu-tools/mcuboot@v1.7.2

OSV / Dependency-Track affected software:

pkg:golang/github.com/mcu-tools/mcuboot

As expected, Dependency-Track does not match these PURLs and CVE-2024-32883 is therefore not reported for the MCUboot component.

GitHub Advisory data

I also enabled the GitHub Advisories mirror. The mirror completed successfully and other vulnerabilities with SOURCE = GITHUB are present in the database.

However, GHSA-m59c-q9gq-rh2j, which corresponds to this MCUboot vulnerability, does not appear as a separate GITHUB vulnerability record in my Dependency-Track database.

So currently the usable affected-package information for this vulnerability appears to come from OSV, where MCUboot is represented as a Go package.

Question

What is the recommended way to represent an embedded C/C++ project such as MCUboot in a CycloneDX SBOM so that Dependency-Track can correlate it with vulnerabilities such as CVE-2024-32883?

Changing the component PURL to:

pkg:golang/github.com/mcu-tools/mcuboot

would make the package identity correspond to the OSV data, but that does not seem semantically correct because the firmware contains the native embedded C MCUboot implementation, not a Go package.

Is pkg:github/mcu-tools/mcuboot@v1.7.2 the appropriate representation for this case?

If so, is there currently a way for Dependency-Track to correlate vulnerability information across these two package identities, or is this a known limitation of ecosystem-specific OSV package identifiers?

I would also be interested to know whether the absence of GHSA-m59c-q9gq-rh2j from the mirrored GitHub vulnerability records is expected.

Thanks!