.NET运行时库漏洞修复疑问：更新SDK后仍检测到风险？

1. dotnet list package的检测逻辑限制 #

dotnet list package --vulnerable是基于项目依赖图中声明的包版本进行检测，而非运行时实际加载的版本。即使CI服务器的.NET运行时已经升级到包含修复的8.0.7版本，只要项目的.csproj或packages.lock.json文件中，间接依赖的System.Formats.Asn1仍记录为8.0.0版本，工具就会判定该版本存在高危漏洞并触发告警。

2. global.json的rollForward设置未作用于依赖版本 #

global.json中的rollForward: latestMinor仅控制SDK版本的选择逻辑，它会让dotnet CLI自动使用当前安装的最新8.x系列SDK，但不会主动修改项目的NuGet依赖版本。这个设置和项目依赖包的版本更新完全无关。

3. 间接依赖的版本锁定机制 #

System.Formats.Asn1是通过Microsoft.Extensions.Configuration.Xml间接引入的，而NuGet的依赖解析会在首次还原时将所有间接依赖的具体版本写入packages.lock.json文件并锁定。除非你主动更新Microsoft.Extensions.Configuration.Xml到包含更高版本System.Formats.Asn1的版本，或者强制重新解析依赖，否则锁定的8.0.0版本不会自动升级。

• 混淆运行时更新与依赖包更新：.NET运行时的修复是系统级的组件更新，但NuGet漏洞检测针对的是项目声明的依赖包版本。即使运行时已经修复漏洞，只要项目依赖图里的包版本仍在漏洞范围内，工具就会触发告警——二者的检测维度完全不同。
• 误解global.json的作用：rollForward不是依赖自动更新开关，它仅解决SDK版本的 fallback 问题，无法干预NuGet依赖的版本选择或更新。
• 忽略packages.lock.json的锁定作用：很多开发者以为依赖会自动跟进上游修复，但实际上.lock文件会固定所有依赖版本，必须主动执行更新操作（比如dotnet add package Microsoft.Extensions.Configuration.Xml --version <最新版本>或dotnet restore --force）才能升级间接依赖。

内容的提问来源于stack exchange，提问作者Ar Es