Dotnet-Portable-Executable-Cataloger uses wrong component version for dotnet runtime libraries

[AndreasAndoerfer]

What happened:

When executing syft to analyse a docker image with a dotnet application it is generating component entries with the file version of the dll and not the assembly version.
This causes a wrong cpe.

In my example it is the .net 8.0 System.Security.Cryptography.Xml.dll

Output of syft:

The library is just one example. This problem exist for all runtime libraries because the file version does not match the assembly- / runtime-version!

What you expected to happen:
I would expect to have the same version displayed in nuget and in the *.deps.json file of the project:

*.deps.json:

Output of syft with dotnet-deps-cataloger:

Steps to reproduce the issue:

• create a docker image with an dotnet web application
• run syft on the docker image

Anything else we need to know?:

Environment:

• Output of syft version: 1.12.2
• OS (e.g: cat /etc/os-release or similar): alpine image

[willmurphyscode]

This is probably related to #2697.

[kzantow]

Hi, @AndreasAndoerfer -- Syft looks at a few different properties in the PE files to attempt to determine the package and version, but we have found that these fields are not used in a consistent manner across various projects. Perhaps you could shed some light on improvements? We have tests of some set of PE files and the code which attempts to determine the package and version available to review.

[AndreasAndoerfer]

Hi @kzantow,
while digging in this issue I also found it quite frustrating that the file versions and other properties are not consistent and that the howl versioning in dotnet is a complete chaos.

First of all I want to clarify my use case to make my points more plausible:
I create a docker container with an dotnet runtime and my developed dotnet web app. I need the SBOM for DTrack analyses to determine what security issues might exist in my running docker containers.
Therefore:

• I need proper cpe values for DTrack to match it to the CVE.
• I only want relevant entries to prevent false positives

All statements below refer to this use case.

My issues:

First of all I do not think that the PE file analysis is a proper way to identify dotnet dependencies.

• The nuget packages do not need to define a proper file version as it is optional (https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/versioning#assembly-file-version)
• The file version is define as "Major.Minor.Build.Revision" but the package version is independent and defined as Major.Minor.Patch[-Suffix] therefore only Major and Minor part of the file version could be used
• I actually have not a dependency to single PE but to a whole runtime

Quick & Dirty ... and not correct:

It seems that the Product-Version fits better than the file version for latest runtime versions. (Just a intuition)

A version = string.Split(versionResources["ProductVersion"],"+")[0] should deal with it.

But this is not really correct:

• Each runtime library also exists as nuget package with a different version. I do not know why and I find it very very stupid but this is reality

For example System.Text.RegularExpressions:

This is the nuget package with a vulnerability CVE-2019-0820 which is fixed in version V4.3.1.

With .NET 8.0 the result using the product version would be
pkg:nuget/[email protected]
and
cpe:2.3:a:System.Text.RegularExpressions:System.Text.RegularExpressions:8.0.8:*:*:*:*:*:*:*

With .NET 6.0 the result using the product version would be
pkg:nuget/[email protected]
and
cpe:2.3:a:System.Text.RegularExpressions:System.Text.RegularExpressions:6.0.33:*:*:*:*:*:*:*

Both results are not correct because there exists no nuget package in this version and in the end the CVE would not match.
Furthermore DTrack would not recommend an update because the version is higher than the existing V4.3.1

And to dig a little bit deeper: Even if the nuget package System.Text.RegularExpressions in version 4.3.0 is installed it is not used!
What will be used is the runtime DLL what makes it even more confusing. (I mentioned this in another issue already with another account https://github.com/anchore/syft/issues/2347)

What really matters:

In the CVE for the above vulnerability the package name is not part of the CPE at all. (e.g.: cpe:2.3:a:microsoft:.net_core:2.2:::::::*)
And if I understand it correctly the .NET 7.0 runtime (that I used at that time) was not compromised.

That brings me back to my point that I have dependency to a runtime as a whole.

If there is any issue with any of the runtime libraries I will update my runtime as a whole and not a single DLL.
For me it is way more important to get an info of my outdated runtime than on any of the libraries that belong to it.
As mentioned above, updating the nuget package from 4.3.0 to 4.3.1 wouldn't fix anything because the runtime DLL will be used.

In my case to get a secure application I have to update the linux-musl-x64 but I think this SBOM entry is not provided by any of the Dotnet catalogers.

Final thoughts:

1. For the dotnet nuget package dependencies it should be focused on the deps.json because I think it is the most accurate.
   Therefore the deps-cataloger should be optimized to ignore runtime dlls.
   I mentioned in my other issue the idea to analyze the "runtime"-part of the json to determine which entry in the "libraries"-part is really used and what is actually provided by the installed runtime.

2. Implement or extend a cataloger to identify the dotnet runtime version and add a proper entry in the SBOM.
   In my case with a docker container it works somehow allready but if I only analyze my dotnet application the most important dependency (the runtime) is not listed in the SBOM.

Sorry for this long answer but I hope it helps with this issue.
Kind regards
Andreas