如何解释/处理这个 dotnet list 包 -- 有漏洞的结果
我已使用 dotnet list package --vulnerable --include-transitive 扫描了易受攻击的 NuGet 包。我得到以下信息：
Project `MyProject` has the following vulnerable packages
[net6.0]:
Transitive Package Resolved Severity Advisory URL
> System.Net.Http 4.3.0 High https://github.com/advisories/GHSA-7jgj-8wvc-jh57
如您所见，我正在使用 .NET 6。在检查我的 packages.lock.json 时，我看到 System.Net.Http 4.3.0 依赖于NETStandard.Library 1.6.1。当阅读咨询 URL 上发布的信息时，它说只有某些 .NET Core 1 .x 和 2.x 运行时容易受到攻击。同样，我使用的是 .NET 6，因此我预计此漏洞不适用于我。
我很困惑如何处理这个问题。
如果该漏洞与我无关，我非常希望不要收到有关该漏洞的通知。恕我直言，考虑到目标框架，dotnet list package 应该自动处理这个问题，但这是另一个问题。无论如何，这是作为 CI 构建的一部分完成的，因此误报很烦人。我不想因为与我无关的内容而收到警告或构建错误的垃圾邮件。
我可以安装最新版本的 System.Net.Http 作为直接依赖项，但由于可能有数百个传递包，这是一个无法扩展的解决方案：我不想保留最新的数百个软件包，据我所知，如果我的其他依赖项发生变化而导致它们过时，则没有简单的方法可以自动删除这些“直接安装的传递依赖项”。我特别希望避免这一切，因为我似乎没有受到影响。
我的首选解决方案可能是去找依赖于易受攻击的软件包的软件包的作者并告诉他们进行更新，但首先，由于与上述相同的原因，这不会真正扩展（并且会延迟我获取补丁，特别是如果传递依赖项是从我这里删除的几个步骤，和/或如果其中一个步骤没有主动维护），其次，这个包仅由 NETStandard.Library 引用，这不是您的正常情况NuGet 包。
我应该如何处理这个问题（特别是这个例子，以及一般问题），以维护安全最佳实践（特别是修复漏洞）并且不会增加噩梦般的维护负担？
I have scanned for vulnerable NuGet packages using dotnet list package --vulnerable --include-transitive. I get the following:
Project `MyProject` has the following vulnerable packages
[net6.0]:
Transitive Package Resolved Severity Advisory URL
> System.Net.Http 4.3.0 High https://github.com/advisories/GHSA-7jgj-8wvc-jh57
As you can see, I am using .NET 6. When inspecting my packages.lock.json, I see that System.Net.Http 4.3.0 is depended on by NETStandard.Library 1.6.1. When reading the information posted at the advisory URL, it says that only certain .NET Core 1.x and 2.x runtimes are vulnerable. Again, I am using .NET 6, so I expect this vulnerability doesn't apply to me.
I am confused about how to handle this.
I would very much like to not be notified about the vulnerability if it's not relevant to me. IMHO dotnet list package should handle this automatically, taking into account the target framework, but that's another issue. In any case, this is done as part of a CI build, so false positives are annoying. I don't want to be spammed with warnings or build errors due to stuff that's not relevant to me.
I could install the most recent version of System.Net.Http as a direct dependency, but with potentially hundreds of transitive packages, that is a solution that won't scale: I don't want to keep hundreds of packages up to date, and there is as far as I know no easy way to then automatically remove these "directly installed transitive dependencies" if my other dependencies change in a way that makes them obsolete. I'd particularly prefer to avoid all of this since I don't seem to be affected.
My preferred solution might be to go to the authors of the packages that depend on the vulnerable package and tell them to update, but firstly, that won't really scale for the same reason as above (and would delay my getting the patch, particularly if the transitive dependency is several steps removed from me, and/or if one of the steps is not actively maintained), and secondly, this package is only referenced by NETStandard.Library, which is not your normal NuGet package.
How should I handle this (both specifically this example, and the general issue) in a way that maintains security best practices (notably, fixes vulnerabilities) and does not add a nightmarish maintenance burden?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在您的示例中，有一个引用 System.Net.Http 4.3.0 版本的包。
这会导致您的应用解析 4.3.0。这意味着您的项目确实安装了该版本。查看您的 bin 文件夹进行确认。换句话说：它与您相关。
要避免使用此版本，您所需要做的就是按照咨询网址的建议安装 4.3.4。
这意味着修复方法是在 .csproj 上添加所需的版本，例如。
这将导致您的项目解析包含修复程序的版本，并且您无需联系中间包的作者。
In your example there is a package that references the System.Net.Http 4.3.0 version.
This causes your app to resolve 4.3.0. This means your project literally have that version installed. See your bin folder to confirm. In other words: it is relevant to you.
To avoid using this version all you need to do is install 4.3.4 as recommended by the advisory url.
This means that the fix would be to add the required version on the .csproj eg.
This would cause your project to resolve a version with the fix, and you do not need to contact the authors of intermediary packages.