你的 ASP.NET Core API 真的安全吗？一个传递依赖就可能带来高危漏洞

引言

现代 ASP.NET Core 应用程序很少只依赖 .NET 框架本身。一个稍微复杂一点的项目，往往会引入几十甚至上百个 NuGet 包，用于身份认证、日志记录、JSON 序列化、数据库访问、API 文档、缓存、消息队列、云服务、测试以及可观测性等功能。问题也正是从这里开始的——应用程序的代码即使写得没有问题，也并不意味着整个系统就是安全的，因为项目实际运行时依赖的不只是我们自己写的代码，还包括大量第三方组件。如果其中某个 NuGet 包存在安全漏洞，那么这个漏洞同样可能进入我们的应用程序。

更麻烦的是，开发者通常不会每天手动检查项目中的所有依赖。如果仅仅依靠每隔几个月进行一次安全审查，那么在两次检查之间，新披露的漏洞可能已经存在于生产环境中。因此，依赖安全不能只依赖人工检查，而应该尽可能集成到 CI（持续集成）流程中。一个真正有价值的依赖安全流程，不应该只是简单地生成一份“发现了几个漏洞”的报告，而应该能够回答几个实际问题：当前项目到底依赖了哪些包？哪些是直接依赖，哪些是传递依赖？哪些依赖存在已知漏洞？这些漏洞的严重程度如何？是否会影响生产环境？发现漏洞之后，应该升级、替换、缓解，还是暂时申请安全例外？当风险达到一定程度时，CI 是否应该直接阻止构建或发布？只有把这些问题真正纳入开发流程，依赖漏洞检测才不会沦为一次形式化的安全扫描。

依赖漏洞的潜在风险与影响

存在漏洞的依赖项可能带来各种安全问题，例如远程代码执行、身份验证绕过、拒绝服务、信息泄露、权限提升、路径遍历、不安全的反序列化以及加密算法实现缺陷等。不过，需要注意的是，漏洞的 CVSS 严重程度并不能完全等同于应用程序实际面临的风险。例如，一个存在高危漏洞的组件，如果只在本地开发工具中使用且不会进入生产环境，那么它与一个部署在 ASP.NET Core API 服务器上、负责处理每一个 HTTP 请求的高危组件相比，实际风险显然不同。

因此，在评估漏洞时，除了关注漏洞等级，还应该考虑以下因素：该包是否会进入生产环境？应用程序是否实际使用了受漏洞影响的功能？攻击者是否能够访问对应的攻击入口？是否存在其他防护措施可以降低风险？其中，依赖安全中一个非常重要的概念，就是区分直接依赖和传递依赖。直接依赖是开发者在项目文件中显式声明的 NuGet 包，例如：

<ItemGroup>
  <PackageReference Include="Serilog.AspNetCore" Version="8.0.0" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="8.0.2" />
</ItemGroup>

这里的 Serilog.AspNetCore 和 Microsoft.EntityFrameworkCore.SqlServer 就属于直接依赖。而传递依赖则不同——假设应用程序依赖包 A，A 又依赖包 B，B 又依赖包 C，如果包 C 存在漏洞，那么即使项目文件中从来没有直接出现过包 C，应用程序仍然可能受到影响。因此，只扫描 .csproj 中显式声明的 NuGet 包是不够的，传递依赖同样必须纳入安全检查范围。

检查依赖图与持续集成检测的优势

在构建自动化安全检查之前，首先应该弄清楚应用程序实际依赖了哪些组件。.NET CLI 提供了一些非常实用的命令，可以帮助开发者查看项目的依赖关系。例如 dotnet list package 可以查看项目引用的 NuGet 包；dotnet list package --vulnerable 可以检查存在已知安全漏洞的依赖；如果需要查看传递依赖，可以加上 --include-transitive 参数，也可以组合使用：

dotnet list package --vulnerable --include-transitive

通过这些信息，开发者可以逐步了解几个核心问题：项目使用了哪些 NuGet 包？这些包当前使用的是什么版本？哪些是直接依赖，哪些是传递依赖？是否存在已知漏洞？漏洞是由哪个依赖链引入的？

相比于每隔几个月手动检查一次依赖，CI 可以提供更快的反馈。假设团队每季度进行一次依赖安全检查，1 月检查时没有发现漏洞，但 2 月某个 NuGet 包披露了一个高危漏洞，如果团队仍然按照季度检查，那么这个漏洞可能一直到下一次安全审查才会被发现，在这段时间内应用程序仍然可能持续构建和部署。而将依赖检查集成到 CI 后，流程变成：开发者提交代码 → 创建 Pull Request → CI 自动检查依赖 → 根据策略决定是否允许继续构建或发布，漏洞检测就被提前到了依赖进入代码库的最前面。不过需要注意，发现漏洞并不等于 CI 一定会自动失败，不同的命令、SDK 版本以及 CI 配置对发现漏洞后的退出码和行为可能不同，因此如果团队希望“发现某类漏洞后必须阻止构建”，还需要明确设计失败条件和安全门禁策略。

构建安全门禁与漏洞分级处理策略

并不是所有漏洞都应该采用相同的处理方式。如果 CI 发现一个低危漏洞就立即阻止所有构建，很容易让开发团队产生大量无意义的阻塞，久而久之开发者甚至可能开始忽略安全警告——这就是常说的告警疲劳。更合理的方式是根据漏洞严重程度、生产环境暴露情况以及组织自身的风险承受能力制定分级策略。例如：严重漏洞默认阻止构建或发布并立即调查；高危漏洞通常阻止生产发布，要求在合并或上线前完成修复，除非经过正式风险评估；中危漏洞允许进入人工审查或设定修复期限；低危漏洞记录并跟踪，在后续版本中安排修复。

当然，这只是一个示例策略，并不是所有团队都必须完全按照这种方式执行。真正重要的是安全规则必须明确、可执行，并且能够被团队理解。如果所有漏洞全部采用“构建失败”的处理方式，开发流程可能会频繁被大量问题阻塞；但如果什么都不阻止，又会导致安全扫描失去意义。安全自动化的目标并不是让开发变得越来越困难，而是在不过度打断开发流程的前提下，把真正危险的问题拦截在生产环境之外。

在 CI 管道中集成依赖检查

一个典型的持续集成流程通常包括还原依赖、依赖安全审计、编译、单元测试、安全测试、构建产物和发布门禁等步骤。依赖扫描通常应该尽量靠前执行，因为如果项目刚刚还原依赖就发现存在严重漏洞，继续执行后面的完整构建、测试和打包流程可能没有太大意义。

在 GitHub Actions 等 CI 平台中，可以配置一个简单的工作流，在 Pull Request 或 Push 时执行依赖漏洞检查：

name: Dependency Security Audit

on:
  pull_request:
    branches: [ main, develop ]
  push:
    branches: [ main ]

jobs:
  dependency-audit:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Setup .NET SDK
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Restore Dependencies
        run: dotnet restore

      - name: Check for Vulnerable Packages
        run: dotnet list package --vulnerable --include-transitive

这段工作流的核心逻辑非常简单：代码发生变更后，CI 检出代码，安装指定版本的 .NET SDK，还原 NuGet 包，然后扫描直接依赖和传递依赖中的已知漏洞。如果生产环境使用的是 .NET 8，那么 CI 中也应该明确使用与项目兼容的 SDK 版本，而不是简单地追求“最新版本”。另外，仅仅执行 dotnet list package --vulnerable 主要解决的是“发现漏洞”的问题。如果希望实现发现严重漏洞时自动让 CI 失败、发现中低危漏洞时生成报告但允许继续构建，通常还需要结合 NuGet 审计配置、漏洞严重程度策略、脚本判断或专门的软件供应链安全工具来实现——真正的安全门禁不是一条命令，而是一套规则。

依赖版本控制与中央包管理

依赖版本如果完全不受控制，同样可能带来安全和稳定性问题。例如，一个大型解决方案中有十几个项目，每个项目都单独维护自己的 NuGet 包版本，项目 A 使用 8.0.1，项目 B 使用 8.0.2，项目 C 仍然使用存在漏洞的 7.x，项目 D 长期无人维护一直没有升级，这种情况下依赖升级很容易变得混乱。因此，依赖版本应该尽可能保持明确和可控。但需要注意，固定版本并不意味着永远不升级，一个健康的依赖生命周期应该是：固定或集中管理版本 → 持续监控漏洞 → 发现安全更新 → 进行兼容性测试 → 升级依赖 → 验证构建和运行结果。版本控制提供的是可重复性，漏洞管理解决的是安全更新问题，两者缺一不可。

对于大型 .NET 解决方案，可以考虑使用 NuGet 的中央包管理。通过 Directory.Packages.props 集中管理版本：

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageVersion Include="Serilog.AspNetCore" Version="8.0.0" />
    <PackageVersion Include="Microsoft.EntityFrameworkCore.SqlServer" Version="8.0.2" />
  </ItemGroup>
</Project>

项目中只声明使用哪个包，而不指定版本：

<ItemGroup>
  <PackageReference Include="Serilog.AspNetCore" />
  <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" />
</ItemGroup>

这样做的好处是依赖版本集中管理，当发现某个包存在漏洞时，不需要在几十个 .csproj 文件中逐个查找和修改版本，统一升级后通过 CI 完成构建和测试验证，管理起来更加容易。

传递漏洞的特殊处理与依赖覆盖测试

传递依赖出现漏洞时，处理起来通常比直接依赖更复杂，因为首先需要回答一个问题：到底是哪个 NuGet 包把这个漏洞依赖带进来的？例如项目依赖包 A，A 依赖包 B，B 依赖存在漏洞的包 C。如果直接升级包 A 就能够解决问题，通常这是最理想的方案，因为包 A 的新版本可能已经调整了自己的依赖关系并经过了官方兼容性验证。

常见的处理方式包括：升级直接依赖；升级解决方案中的相关包；升级或替换引入漏洞的第三方组件；移除不必要的依赖；在确认兼容性的情况下对传递依赖进行版本覆盖。有些情况下，开发者可能会选择显式引用一个更安全的版本以影响 NuGet 最终解析出的依赖版本：

<ItemGroup>
  <PackageReference Include="System.Text.Json" Version="8.0.4" />
</ItemGroup>

这种方式有时确实可以作为临时缓解措施，但不能简单理解为“只要显式引用一个更高版本，漏洞就一定解决了”，因为最终是否能够成功替换还取决于 NuGet 的依赖解析规则以及其他包声明的版本范围。同时，升级底层传递依赖还可能引入 API 行为变化或二进制兼容性问题。因此，正确的处理流程应该是：首先查看完整依赖图，确认漏洞是由哪个包引入的；优先升级直接依赖；如果无法升级再评估是否可以覆盖传递依赖；修改之后重新还原依赖，再次执行漏洞扫描，最后执行完整的构建、单元测试和集成测试。不要为了消除漏洞报告而盲目修改依赖版本，真正的目标应该是既消除安全风险，又确保应用程序仍然能够正常运行。

可利用性分析与临时例外流程

漏洞扫描工具能够告诉我们某个 NuGet 包的某个版本存在已知漏洞，但它通常无法完全判断攻击者是否真的能够利用这个漏洞攻击当前应用程序。例如，一个漏洞可能只影响某个特定 API，而我们的应用程序虽然引用了这个包却从来没有使用对应功能；或者漏洞需要特定配置才能触发，而生产环境并不存在这种配置。因此，在漏洞修复优先级排序时，可利用性分析非常重要。不过这并不意味着“我们觉得没用到，所以忽略漏洞”，特别是高危和严重漏洞，如果没有经过明确的风险评估，不能简单地永久忽略。

有些漏洞可能暂时无法立即修复，例如升级 NuGet 包会导致重大 API 变化、第三方厂商暂时没有发布修复版本、升级会影响核心业务系统、短期内无法完成完整的兼容性测试等。这种情况下可以建立一个临时安全例外流程。一份完整的漏洞例外记录至少应该包含：包名称、当前版本、漏洞编号、严重程度、例外原因、当前缓解措施、负责人、创建日期、计划审查日期和明确的过期时间。最重要的一点是安全例外必须有过期时间，否则所谓的“暂时无法修复”很容易在几年之后仍然存在，最终演变成永久性的安全债务。

软件供应链安全与可重复构建

现代应用程序的安全边界已经不再局限于自己编写的源代码。一个 ASP.NET Core 应用程序可能依赖 .NET SDK、NuGet 包、传递依赖、构建工具、GitHub Actions、Docker 基础镜像、Linux 系统包、.NET Runtime 以及原生依赖库，这些组件共同构成了应用程序的软件供应链。因此，NuGet 漏洞扫描只是软件供应链安全中的一个环节。

另一个非常重要的问题是：同一份源代码，是否能够稳定地构建出相同的依赖图和产物？假设今天 CI 构建时还原了 A 包的 1.0.1，明天没有修改任何代码却因为依赖版本解析发生变化构建使用了另一个版本，那么当出现安全问题时，我们可能很难准确回答生产环境到底使用了哪个版本。因此，在适当的情况下可以结合依赖锁定文件和确定性构建实践提高构建结果的可重复性。例如，团队可以使用 NuGet 锁定文件：

dotnet restore --use-lock-file

生成并维护依赖锁定信息。在 CI 环境中还可以根据项目策略使用锁定模式，避免依赖图在没有明确变更的情况下发生意外变化。这样可以形成更加清晰的链路：源代码提交 → 确定的依赖图 → 可重复构建 → 已知构建产物，不仅能够提高安全性，也能在出现漏洞或生产事故时帮助团队更快进行排查。

此外，依赖安全检查不应该只发生在代码合并之后。当开发者在 Pull Request 中新增一个 NuGet 包时，审查者就应该能够看到这次依赖变化，并进一步考虑：为什么需要引入这个包？该项目是否仍然活跃维护？是否存在已知漏洞？会不会引入大量额外的传递依赖？是否存在官方库或更成熟的替代方案？版本是否合理？这些问题同样属于软件供应链安全的一部分。

容器镜像扫描与依赖生命周期分类

即使 NuGet 依赖扫描结果完全正常，也不能说明整个生产环境就是安全的。如果应用程序部署在 Docker 容器中，最终镜像中可能还包含基础操作系统、系统软件包、.NET Runtime、OpenSSL 等原生库以及其他 Linux 组件。因此，一个干净的 NuGet 依赖图并不能代表 Docker 镜像没有漏洞。更完整的安全策略应该包括：NuGet 依赖扫描、容器镜像扫描、应用程序安全测试，必要时结合 SAST、DAST 等安全检测。

同时，不同类型的依赖其风险优先级也不同。例如生产运行时依赖、开发依赖、构建依赖、测试依赖、代码生成工具等，一个只存在于测试环境中的漏洞包通常不会直接进入生产 API 的运行时环境，而一个处理 HTTP 请求、身份认证或 JSON 反序列化的运行时组件则可能直接暴露在攻击面上。因此，依赖漏洞不能只看“有没有”，还应该关注它在哪里使用、是否进入生产环境、是否暴露给外部用户、是否参与核心请求链路。这种依赖生命周期分类可以帮助团队更合理地安排修复优先级。

除此之外，还可以关注依赖的维护健康度。一个 NuGet 包即使当前没有公开漏洞，也可能已经多年没有维护。因此可以综合观察依赖是否长期未更新、是否存在已知漏洞、与当前主版本相差多少、维护者是否仍然活跃、传递依赖数量是否过多、是否存在更成熟的替代方案。这些指标可以帮助团队提前发现潜在的依赖风险，而不是等漏洞爆发之后才开始处理。

可操作的安全报告与发布门禁集成

一份好的安全报告不应该只是告诉开发者“发现了 3 个漏洞”，这种报告价值其实非常有限。开发者真正需要知道的是：哪个包有问题？当前使用什么版本？漏洞来自直接依赖还是传递依赖？漏洞严重程度如何？生产环境是否受到影响？建议升级到哪个版本？下一步应该做什么？例如，一份更有价值的报告可以是：

Package A
类型：直接依赖
状态：未发现已知漏洞
建议：保持当前版本

Package B
类型：直接依赖
严重程度：High
建议：升级到已修复版本，并执行兼容性测试

Package C
类型：传递依赖
严重程度：Medium
建议：检查由哪个直接依赖引入，并评估升级路径

Package D
类型：传递依赖
严重程度：Critical
建议：阻止生产发布，立即调查并修复

这种报告比简单输出一堆 NuGet 包名称更有意义，因为安全问题最终还是需要开发人员处理，如果报告不能告诉开发者下一步该做什么，漏洞扫描就很容易变成“扫描了，但没人管”。

对于生产发布流程，依赖安全也可以成为发布门禁的一部分：Pull Request → 依赖审计 → 构建 → 单元测试 → 集成测试 → 安全验证 → 发布门禁。当组织策略要求时，严重漏洞可以自动阻止进入生产环境。通常更推荐把安全门禁重点放在阻止高风险代码进入生产环境，而不是简单地让所有开发构建全部失败，这样既能保证安全，又能避免因为低风险问题造成大量开发阻塞。

常见错误规避与最佳实践总结

在依赖安全管理中，团队经常会犯一些典型错误：只扫描直接依赖而忽略传递依赖——实际上真正复杂的项目中大量依赖都是通过其他包间接引入的；每隔几个月才运行一次漏洞扫描——漏洞是持续出现的，依赖检查也应该持续进行；不管漏洞等级如何全部阻止构建——短期看起来非常严格，但长期可能导致开发人员对安全告警产生疲劳；永久忽略某个漏洞——任何安全例外都应该有负责人、缓解措施和明确的过期时间；看到传递依赖有漏洞就直接强制升级版本——可能导致依赖冲突或运行时兼容性问题；只关注 NuGet 包而忽略 Docker 基础镜像、操作系统依赖以及 CI 环境；把“扫描发现漏洞”直接等同于“应用程序一定可以被攻击”——漏洞扫描只能告诉我们已知漏洞是否存在，实际风险仍然需要结合攻击面和应用程序使用方式进行评估。

综合来看，一套相对成熟的实践应该包括：在 CI 中自动执行依赖漏洞检查，同时检查直接依赖和传递依赖；根据严重程度制定安全门禁，重点关注生产运行时依赖；保持依赖版本明确且可重复；在 Pull Request 中审查新增依赖；优先升级官方修复版本，谨慎处理传递依赖覆盖；对无法立即修复的问题建立临时安全例外，并设置负责人和过期时间；结合 NuGet 扫描、容器扫描和应用程序安全测试；持续关注依赖维护状态和版本老化问题；让严重漏洞能够阻止生产发布，让安全报告具有明确的可操作性；避免简单地全面忽略或抑制漏洞警告；维护完整、可审计的漏洞修复流程。