Is transitive pinning a real solution for mitigating vulnerabilities found in framework assemblies with framework-dependent builds?

[radlohac]

Everybody lists transitive pinning as the solution for package with vulnerabilities, so I guess most folks use this as a way to mitigate vulnerabilities.

What nobody asks is, what about vulnerabilities found in framework assemblies?

The problem that I keep encountering is that we have a .NET 8 web app, up-to-date regarding NuGet packages, that somehow has System.Text.RegularExpressions 4.3.0 (e.g.) as a transitive dependency (observed in the dependency tree). Now, this is a well-known vulnerable package.
However, on the CI pipeline we build this targeting .NET 8 with an up-to-date SDK version and we build it framework-dependent and deploy on Azure.

The unfortunate thing is that afterwards, analyzers like mend.io complain about this vulnerability but I don't think it really exists. Being a framework-dependent build, there's no actual System.Text.RegularExpressions assembly in the build output as it is a framework one, and in Azure or wherever it is run, it will actually load a version deployed by the .NET runtime which is of course recent and not vulnerable.
My assumption is that even if we build self-contained, the version of the assembly contained in the package would be from the recent .NET SDK, not 4.3.0.

So then, is transitive pinning for framework assemblies useful in any way (except making mend.io shut up) or is this actually useful only for 3rd party assemblies?

[jeffkl]

This will be fixed in a future release through a mechanism in NuGet which allows us to prune package references that aren't needed.

https://github.com/NuGet/Home/blob/dev/accepted/2024/prune-package-reference.md

This feature was developed for precisely this reason where you get notifications in regards to using vulnerable packages when they are not actually used.