dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
21.03k stars 4.9k forks source link

Best way to dependency-track .NET CVEs #8336

Open Falco20019 opened 1 year ago

Falco20019 commented 1 year ago

We are looking into how to best track vulnerabilities for dependencies of our application (build on .NET 6) and the shared frameworks.

I am aware that https://github.com/dotnet/core/blob/main/release-notes/6.0/cve.md is listing vulnerabilities per version. Looking at some of the latest ones, I found multiple ways that would work (each with it's own caveats). As an example for the following, let's just use CVE-2023-21808.

I also know, that Microsoft is working on dependency tracking (especially for more low-level things like platform dependencies) as part of #5651 which is also interesting for the future but unrelated for this issue and still around phase 1.

Tested approaches

Using CPE 2.3

Checking the NIST NVD, you get a list of affected CPEs. When using cpe:2.3:a:microsoft:.net:6.0.0:*:*:*:*:*:*:* for tracking the installed framework, we would get all CVEs for any .NET 6 version, even already fixed ones (see NIST NVD). That's because only that one enumerator is used in any CVE. For other CPEs like cpe:2.3:a:microsoft:visual_studio_2022:... this is a lot more detailed with explicit listings per version affected.

When using cpe:2.3:a:microsoft:.net:6.0.13:*:*:*:*:*:*:*, you will not get a single CVE (see NIST NVD) for the aforementioned reason although one should be detected. This makes CPE hard to use.

For 6.0.1 and 6.0.2 they had been maintained properly as seen in CVE-2022-34716.

Using PURL

When using GitHub Advisories, it's possible to find vulnerabilities by tracking Microsoft.NetCore.App.Runtime.win-x64 instead. https://github.com/advisories?query=Microsoft.NetCore.App.Runtime.win-x64 would find it. So by using PURL and directly defining pkg:nuget/Microsoft.NetCore.App.Runtime.win-x64@6.0.13 as a framework component in dependency tracking (like with a CycloneDX SBOM) could work.

Best practices

I was not able to find any best-practices on how to track in the SBOM what .NET framework it's relying on. The <AppName>.runtimeconfig.json is having the tfm and frameworks with the min. version required, but it's hard to find a good way to track CVEs for them. The best approach seems to have a SBOM for the application that is not referencing .NET in any way and having a separate (machine-related) SBOM for tracking what frameworks are used using a PURL to reference the NuGet framework package for tracking the installed versions.

I would have preferred to be able to use the CPE as that's more related to the full runtime than specifying each framework expected with the installed version and maintaining them. Are there any plans to use the full list of affected versions for the cpe:2.3:a:microsoft:.net:6.0.x (like it's done up until 6.0.2) or is PURL my best option?

/CC @mthalman @rbhanda

mthalman commented 1 year ago

cc @blowdart

blowdart commented 1 year ago

Oh interesting. MSRC are responsible for all the cves, tagging etc., we basically write the description.

So I'm going to flag this over to them and see what they say.

Falco20019 commented 1 year ago

@blowdart Any response from MSRC? :)

blowdart commented 1 year ago

So part of this is being rolled up into some feature requests for nuget information, and for CVEs they're considering it, but you'd see it on windows first, and everything else a lot later.

We're quite aware that scanners are getting things frustratingly wrong, there's a wider effort going on to drive instructions on how to scan deps.json etc. correctly, but there's no time frame here, because it'll need the various scanners to pivot. When it is released though it'll be public, probably in a repo of its own to be a living document.