[Feature]: Add tracing to NuGet to identify all possible sources of package downloads #11782
Description
NuGet Product(s) Involved
NuGet.exe, Visual Studio Package Management UI, Visual Studio Package Manager Console, MSBuild.exe, dotnet.exe, NuGet SDK
The Elevator Pitch
Component Governance is important to help identify potential vulnerabilities in a repository.
Today component governance detects direct references, but also side-effects of restore -- the assets file, packages downloaded, binaries in the output. These are all good indicators but sometimes are hard to trace to the root cause.
One example we've noticed that's exceptionally hard for folks to identify is eclipsed packages. NuGet will download packages in the graph if it cannot "know" at the time of the download if that package will eventually win or not. These packages will appear in a local packages folder and could be used by the repository, so they are flagged by component governance.
Take one example which we hit in some dotnet repositories. Imagine package C1 is vulnerable and flagged by component governance.
Project > A > B1 > C1
Project > D > B2 > C2
In this case there is nothing inside the repository's intermediates that tells the repo owner "why" NuGet downloaded C1. They could find the reference in other packages downloaded and try to walk back up to some package which does appear in intermediate assets files, but that's a ton of work and not really feasible for the majority of our users.
Can we make it crystal clear why a package was downloaded? Potentially through opt-in tracing? NuGet knows this information and can make it available through some simple logging. Doing so would save repo owners everywhere many hours of time and make the ecosystem better by helping folks make more educated decisions in their repos around dismissing issues, working around them, or asking dependencies to update.
Additional Context and Details
No response