feat(nuget): Parse deps specified as PackageReference in .csproj files

[Sjord]

C# project files, with the extension .csproj, are XML files that can specify project dependencies in <PackageReference> tags.

See also:

• https://github.com/aquasecurity/trivy/issues/2668
• https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

[CLAassistant]

All committers have signed the CLA.

[Sjord]

From the CLA:

You represent that each of Your Contributions is Your original creation

Well, I copied pkg/nuget/config to pkg/nuget/csproj and modified things to get it to work on .csproj files. I guess that's OK, right?

[knqyf263]

Well, I copied pkg/nuget/config to pkg/nuget/csproj and modified things to get it to work on .csproj files. I guess that's OK, right?

Yes, thanks for signing.

@DmitriyLewen Could you review this PR?

[Sjord]

I now put this in the nuget directory, but I later saw that there is also a dotnet directory. Is csproj correct in the nuget dir, or does dotnet make more sense?

[DmitriyLewen]

LGTM.

Is csproj correct in the nuget dir, or does dotnet make more sense?

I think nuget is okay

[Sjord]

@knqyf263 This has been reviewed, could you merge this?

[knqyf263]

The result can be incomplete since it extracts only packages having exact versions, right? We're currently discussing whether we should display these incomplete results or encourage users to generate a lock file. If we show any result, it looks like we properly determined installed packages, but it is not the case actually. It can confuse users. Any thoughts? Please correct me if my above assumption is wrong.

[Sjord]

Yes, this is an opportunistic approach where we can verify some dependencies, but in some cases determining the exact version is not possible. I think this is preferable to not scanning dependencies at all, but I agree this may give false confidence. If a lock file is present, that should be scanned instead. If no lock file is present, it would be a good idea to report that to the user.

As a security consultant, I use trivy to scan my client's projects. Finding any vulnerable dependency allows me to point the client to the importance of keeping packages up to date, and advice them to use a lock file. So completeness is not very important to me, as I use this to indicate a general problem instead of finding which packages need updating.

[bjuraga]

Any chance this gets merged? As it is, it does have some limitations, but i would split the implementation to 2 phases, Optimistic and Deterministic. At the moment we have nothing in the SBOM, and with this implementation, we can at least get most of the package names.

[afrischk]

Any update on this?

[bjuraga]

Any update on this?

Might be better to use the *.deps.json from your bin folder. We have had a great success in doing so, and that file contains the actual dependencies instead of the requested ones.

[afrischk]

This holds true for .NET Core and .NET 5+. I was hoping to be able to use Trivy on an older .NET project with no .deps.json available but PackageReference in .csproj files.

[afrischk]

Ok, I found a solution. After reading the comment from @knqyf263 carefully I noticed 'encourage users to generate a lock file'. I read through microsofts docs about packages.lock.json and added a Directory.Build.props file with the following contents to the root directory of my solution.

<Project>
 <PropertyGroup>
   <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
 </PropertyGroup>
</Project>

All subprojects are now generating a packages.lock.json after a NuGet restore and Trivy happily parses them :-) I hope this is helpful for anybody having the same issue.

[itrf98]

Dear Team,

Any news about this ? Are you planning to merge it ?

Thank you in advance

[afrischk]

@itrf98 have you read @bjuraga , @knqyf263 and my comment about the json files? Is this a solution for you?