trivy not detecting dependencies defined in .csProject files (.Net)

[nartreb]

Description

A client of mine ran a trivy scan on a .Net project and didn't see output (vulns, licenses) for dependencies I know the project is using.

If I read the documentation correctly, Trivy looks at packages.config or (preferably) packages.lock.json to tell it what dependencies are included in a .Net project. But this project uses PackageReference tags inside a .csproject file instead (example in attached screenshot).

Desired Behavior

Trivy should detect all listed project dependencies, even if they are listed as PackageReferences in the .csproject file and not packages.config

(I am told that PackageReference will be the default for .Net projects:
"This project targets .NET8 for Android which is the current/future LTS version for Microsoft (with .NET6 going end-of-life for support in November).

By default, .NET Core uses the PackageReference system, so going forward I would expect most Visual Studio projects would look this way." )

Actual Behavior

No output reflecting those dependencies - I'm pretty sure Trivy never looked at them (I suppose maybe they're all vuln-free and none has any license metadata, but that seems unlikely. It's not just one project or the few files in the screenshot.)

Reproduction Steps

1. Create a .Net project.
2. Download some dependencies, (store them in a folder that is not a subdirectory of the project but is on the system path for DLLs) list them in .csproject 
  (Pick dependencies known to be detected - license metadata and/or known vulns)
3. run Trivy -fs on the project (license or vuln, as appropriate)
4.  Observe that Trivy does not report any issues related to those dependencies
5.  Also note Number of language-specific-files = 0 in the debug log... I think that means it looked at zero files

Target

Filesystem

Scanner

Vulnerability

Output Format

Table

Mode

Standalone

Debug Output

2024-06-26T08:43:52-05:00	INFO	Vulnerability scanning is enabled
2024-06-26T08:43:52-05:00	INFO	Number of language-specific files	num=0

Operating System

Windows

Version

0.51.2 or thereabouts

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Trivy doesn't scan .csproj files (https://aquasecurity.github.io/trivy/v0.52/docs/coverage/language/dotnet/).

There is problem with scanning .csproj files.
These files can use version range - https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-version

We can't correcntly detect versions for dependencies with version range.
See aquasecurity/go-dep-parser#121 (comment)

Trivy supports the following files - https://aquasecurity.github.io/trivy/v0.52/docs/coverage/language/dotnet/
You may be able to choose a different file for your project.

Regards, Dmitriy

[nartreb]

Thanks for response. My use case involves scanning projects that I didn't create and know absolutely nothing about. "Choose a different file" as a prerequisite for running a scan seems backwards to me. I need a tool that will tell me what's in the build. A tool that only works after I've changed the build is not very useful.

I realize that not knowing exact versions of dependencies is fairly useless for security scanning, but it's much less important for license scanning, which is my top concern.

If the scanner finds a BOM file that it can't read, I want it to warn me, so I can investigate. And if it can sort-of-read it, I want it to warn me that results are not complete, AND show me the information it did find. In particular, the license scan should still work even if the security scan isn't much use.

I need to be able to tell clients "just run this tool and send me the output." If there's ANY technical steps involved beyond that, it makes my life vastly more difficult. I might be able to ask my clients to create packages.lock.json (that sounds harmless to their build) but it's decidedly sub-optimal.

I realize you can't be expected support every weird build system that's out there. But this is a very normal method of building .Net projects, and shouldn't be passed over in silence.

Pull #121 is a couple of years old now, I don't know if it's still valid, but it looks like it was stopped only for fear of giving users false confidence. @knqyf263 any chance of revisiting that decision? To me it's worse, in terms of false confidence, to completely ignore a valid BOM file. The scan result gave me no warning about that, I only got suspicious when the number of packages seemed low.

[knqyf263]

I realize that not knowing exact versions of dependencies is fairly useless for security scanning, but it's much less important for license scanning, which is my top concern.

It sounds reasonable to add license support, but I didn't find licenses in .csproj. Where can we get the license information?

[nartreb]

Just listing out the dependencies with "license: UNKNOWN" would be a huge help to me. I can google their licenses myself.
(In fact I would run a post-processing script with a lookup table, so I would google less and less each time I scan a project.)

I'm not a .Net developer myself, just have a client who wants to audit a .Net codebase. All I know about .csproject files is what I read here: https://learn.microsoft.com/en-us/nuget/concepts/package-versioning?tabs=semver20sort There's a passing mention in there of .nuspec and packages.config files, which seem like possibly useful places to look for exact version numbers (but might not exist in every project?). Oh, the next page mentions projects.assets.json, that might be even more interesting (but again, it's not entirely clear whether that file will always exist). But to answer your question to the best of my knowledge, none of these configuration files seems to contain license data.

It looks like PackageReference tags (inside " .csproj or other package version location (Directory.Packages.props) ") is now the preferred configuratoin method (replacing packages.config) but not fully supported yet. (Gotta love Microsoft.)
By default, PackageReference is used for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update) and later, with the exception of C++ UWP projects. .NET Framework projects support PackageReference, but currently default to packages.config. ... ASP.NET apps targeting the full .NET Framework include only limited support for PackageReference. C++ and JavaScript project types are unsupported.

[knqyf263]

Showing unknown versions and unknown licenses for all packages just confuses most users even if it's enough for you. It's better to say we don't support .csproj.