In order to prevent vulnerable, transitive dependencies, I added guard versions to the Directory.Packages.props file, used for Central Package Management (CPM) in Visual Studio 2022. Transitive pinning is enabled, of course:
<ItemGroup>
<!-- Minimum versions everywhere, preventing vulnerable dependencies -->
<!-- CVE-2024-32655 in <=6.0.10/8.0.2; can be removed when >=6.0.11/8.0.3 in all dependencies. -->
<PackageVersion Include="Npgsql" Version="8.0.3" />
<!-- now also vulnerable, => 8.0.1, but not actual part of the .NET runtime. -->
<!-- Name is misleading! -->
<PackageVersion Include="System.Runtime.Caching" Version="8.0.0" />
<!--CVE-2024-30105 -->
<!-- Part of .NET runtime since NET 8, 8.0.4 now also vulnerable. -->
<PackageVersion Include="System.Text.Json" Version="8.0.4" />
</ItemGroup>
Now, the System.Text.Json package version 8.0.4 has got another vulnerability and should be updated to 8.0.5.
I also noticed that System.Text.Json is now part of the .NET runtime (I think since .NET 8).
-
Specifying a PackageVersion no longer makes the build deliver a System.Text.Json.dll, so is the version now ignored?
-
I get a warning, both in Visual Studio and in later vulnerability scans, when I specify the package with version 8.0.4. But as I see, under .NET 8, it solely depends on the runtime version, so I suppose the warning is just in case that older .NET versions are used (which aren’t). Correct?
-
After removing the PackageVersion, the vulnerable version 8.0.4 still appears as a dependency of a 3rd party component, but without warning. Is this due to an outdated runtime on my DEV machine, and no issue if the application runs under an up-to-date runtime?
-
And a last question: If it’s best to not set PackageVersion for runtime components, how can I quickly find out which components have moved to the runtime, which weren’t there in NET 5 and 6?
You need to sign in to view this answers
