Improving Nuget detectors to track packages being consumed.

[8Gitbrix]

Per OSE support thread "MerlinBot doesn't read PackageReferences correctly?", they're wondering if the nuget detectors can be improved to only look at packages being consumed instead of looking at csproj files in isolation.

Interesting points from my conversation with Parker:

• NET has assembly binding redirects that can be applied so that even if the app or a dependency asks for a vulnerable version, and Nuget downloads one, only non-vulnerable versions may be packaged or consumed
• .NET Core can also do this, but with different settings and with <PackageReferene> and assets.jsons rather than packages.config.

Would it be possible to leverage something like this to improve our nuget detectors?

[frankshearar]

For example: project Sub contains something that transitively references a naughty package version. Sub is part of Super, some top level project (exe, Azure Cloud Service worker role, whatever). Super has a direct reference to the nice package version.

Sub gets flagged up as being vulnerable, even though it's not - because of the pin in Super. If you examined the DLLs in Super's bin/ you'd see the nice package version.

[8Gitbrix]

Adding some more info here after discussion on support issue "Re: Component Detection - System.Security.Cryptography.X509Certificates v4.1.0". The component causing the alert is in the nuget cache on the build machine, but not the one being packaged and shipped.

So we'd get more accurate info on the packages that are (the proper version for example) actually being consumed by checking the dll

[frankshearar]

Checking the compiled DLL would definitely be more accurate. Binding redirects mean that you might have compiled against the vulnerable package version but not actually be using it. At least we'd cut down on false positives like that which resulted in this thread.