CPE vs PURL

[mdouble]

Today we got aware of CVEs in "Telerik UI for WPF" (e.g. CVE-2024-8316, CVE-2024-75756) . We tried to monitor the component via Dependency Track.

In the uploaded SBOM the components have a Package URL as recommended (https://docs.dependencytrack.org/datasources/routing/) e.g.

• "purl": "pkg:nuget/[email protected]".
• "purl": "pkg:nuget/Telerik.Windows.Controls.FixedDocumentViewers.for.Wpf@2023.3.1010"
• "purl": "pkg:nuget/Telerik.Windows.Controls.FixedDocumentViewersUI.for.Wpf@2023.3.1010"
• "purl": "pkg:nuget/[email protected]"
• "purl": "pkg:nuget/[email protected]"
• "purl": "pkg:nuget/[email protected]"

etc.

In the JSON for the CVE the affected component is listed with the cpe ""cpe:2.3:a:telerik:ui_for_wpf::::::::"".

Although there are Vulnerabilities in the component we did not get a notification. Somehow I was expecting the internal analyzer to match PURLs to CPEs. Is this expectation wrong?

[mdouble]

I want to raise this question again because it is a serious problem and the question for us as a company is whether we can actually automate our vulnerability monitoring process here.

The problem in this particular case seems to be that there is no NuGet package for "Telerik UI for WPF". Because of this, CycloneDX does not create a purl that matches the CPE "cpe:2.3:a:telerik:ui_for_wpf::::::::" which leads to the missing warning for the vulnerabilities.

We can fix this by adding the CPE manually to our SBOM like

"components": [
    {
      "type": "library",
      "name": "Telerik_UI_for_WPF",
      "version": "2024.3.924",
      "cpe": "cpe:2.3:a:telerik:ui_for_wpf:*:*:*:*:*:*:*:*",
      "bom-ref": "[email protected]"
    }
  ],

However, this does not meet my expectations for an automated process and will most likely only work retrospectively in other cases. So is there a reasonable way to ensure that we are informed about all vulnerabilities in the components we use?

[nscuro]

Somehow I was expecting the internal analyzer to match PURLs to CPEs. Is this expectation wrong?

The viability of matching PURLs to CPEs is somewhere between impractical and impossible. You will see other tools doing it on a best-effort basis (i.e. Syft/Grype), but ultimately what they end up doing is fuzzing the CPE, which comes with an increased risk of false positives.

You can find some background on the general issue here: https://owasp.org/blog/2022/09/13/sbom-forum-recommends-improvements-to-nvd

Generally it's recommended to rely on PURL. However, since the NVD does not natively support PURL, alternative sources like GitHub Advisories, OSV, or OSS Index are needed to leverage them.

[mdouble]

@nscuro Thank you very much for your answer.

I am aware of the difficulties and I had also seen the linked article. I am definitely in favor of the NVD supporting PURLs. My question is more about a recommended procedure here and what to expect.

We have activated the internal analyzer and the OSS Index Analyzer. In the SBOM, all components are listed with a PURL. The SBOM is automatically generated by CycloneDX.

In addition, do we need to assign a CPE to each component to make sure we are notified of reported vulnerabilities?

What do the analyzers do? Should we “Enable fuzzy CPE matching on components that have a Package URL (PURL) defined” on the internal analyzer? How many false positives should we then expect?

Am I on the safe side with this or do we still have to scan the NVD manually?