-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nuget package dependency - nearest wins in DevAudit #154
Comments
Here is an example to make it more clear.
Running DevAudit against this I get one vulnerability reported with NewtonSoft.Json 9.0.1:
So because the minimum version of Newtonsoft.Json that the Microsoft.NET.Test.Sdk package can use has a vulnerability it is reported (which is Newtonsoft.Json 9.0.1 in this case). However the Newtonsoft.Json package version that would actually be used in the application is 13.0.1 according to the nearest wins solution. Note too that Newtonsoft.Json 13.0.1 has no vulnerabilities reported. So really the vulnerability in this example should not be reported. |
UPDATE: workaround for this The csproj file provides the packages we need to build the project but it does not provide info on which versions of the dependencies we would actually be using based on how NuGet solves package dependencies. So I found that a way to get around this is to instead have dev_audit scan the deps.json files which is updated post build. This will include all of the dependencies used in the project with the exact package versions being used. Thus changing the dev_audit to scan deps.json files actually reports that the vulnerability was fixed in the example above. |
@ken-duck - any recommendations for this problem? |
When finding vulnerabilities DevAudit does not consider the nearest wins solution for nuget package dependency: https://docs.microsoft.com/en-us/nuget/concepts/dependency-resolution#nearest-wins
For example in a csproj file if I am referencing a Nuget package that has a dependency where the minimum version has a vulnerability DevAudit would always report the vulnerability ignoring nearest wins. According to the nearest wins solution this vulnerability should not happen if I am referencing a version of the dependency closer to the application.
Could there be a way for DevAudit to consider the nearest wins solution?
The text was updated successfully, but these errors were encountered: