Open Falco20019 opened 1 year ago
cc @blowdart
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.
@blowdart Any response from MSRC? :)
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.
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 likecpe: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 definingpkg: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 thetfm
andframeworks
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