feat(nuget): Parse deps specified as PackageReference in .csproj files #121
Conversation
|
|
|
From the CLA:
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? |
C# project files, with the extension .csproj, are XML files that can specify project dependencies in `<PackageReference>` tags. See also: * aquasecurity/trivy#2668 * https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Sjord
changed the title
Yes, thanks for signing. @DmitriyLewen Could you review this PR? |
|
I now put this in the |
PrivateAssets=all, ExcludeAssets=all, ExcludeAssets=runtime. There are more combinations possible, but these seem to be the most common values to indicate dependencies that are either not transitive, only available at compile time, or not available at all. PrivateAssets and ExcludeAssets can be specified in either an attribute or a tag, where the tag takes precedence. Values are separated by semicolons and case insensitive.
A floating version specifies a range of versions, such as `1.2.*`. This can't be parsed as an actual version. We strip all `.*` at the end, and reduce to a version such as `1.2`. This is not very accurate. Version 1.2 of a package may not even exist. However, I think it is acceptable for trivy when comparing actual versions with vulnerable versions. When packages before 1.2.5 contain a vulnerability, we want to flag 1.2.* as potentially vulnerable.
|
LGTM.
I think |
|
@knqyf263 This has been reviewed, could you merge this? |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 All subprojects are now generating a |
|
Dear Team, Any news about this ? Are you planning to merge it ? Thank you in advance |
C# project files, with the extension .csproj, are XML files that can specify project dependencies in
<PackageReference>tags.See also: