Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best way to dependency-track .NET CVEs #8336

Open
Falco20019 opened this issue Mar 29, 2023 · 4 comments
Open

Best way to dependency-track .NET CVEs #8336

Falco20019 opened this issue Mar 29, 2023 · 4 comments

Comments

@Falco20019
Copy link
Contributor

Falco20019 commented Mar 29, 2023

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
Copy link
Member

cc @blowdart

@blowdart
Copy link
Contributor

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
Copy link
Contributor Author

@blowdart Any response from MSRC? :)

@blowdart
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants