引言现代 ASP.NET Core 应用程序很少只依赖 .NET 框架本身。一个稍微复杂一点的项目往往会引入几十甚至上百个 NuGet 包用于身份认证、日志记录、JSON 序列化、数据库访问、API 文档、缓存、消息队列、云服务、测试以及可观测性等功能。问题也正是从这里开始的——应用程序的代码即使写得没有问题也并不意味着整个系统就是安全的因为项目实际运行时依赖的不只是我们自己写的代码还包括大量第三方组件。如果其中某个 NuGet 包存在安全漏洞那么这个漏洞同样可能进入我们的应用程序。更麻烦的是开发者通常不会每天手动检查项目中的所有依赖。如果仅仅依靠每隔几个月进行一次安全审查那么在两次检查之间新披露的漏洞可能已经存在于生产环境中。因此依赖安全不能只依赖人工检查而应该尽可能集成到 CI持续集成流程中。一个真正有价值的依赖安全流程不应该只是简单地生成一份“发现了几个漏洞”的报告而应该能够回答几个实际问题当前项目到底依赖了哪些包哪些是直接依赖哪些是传递依赖哪些依赖存在已知漏洞这些漏洞的严重程度如何是否会影响生产环境发现漏洞之后应该升级、替换、缓解还是暂时申请安全例外当风险达到一定程度时CI 是否应该直接阻止构建或发布只有把这些问题真正纳入开发流程依赖漏洞检测才不会沦为一次形式化的安全扫描。依赖漏洞的潜在风险与影响存在漏洞的依赖项可能带来各种安全问题例如远程代码执行、身份验证绕过、拒绝服务、信息泄露、权限提升、路径遍历、不安全的反序列化以及加密算法实现缺陷等。不过需要注意的是漏洞的 CVSS 严重程度并不能完全等同于应用程序实际面临的风险。例如一个存在高危漏洞的组件如果只在本地开发工具中使用且不会进入生产环境那么它与一个部署在 ASP.NET Core API 服务器上、负责处理每一个 HTTP 请求的高危组件相比实际风险显然不同。因此在评估漏洞时除了关注漏洞等级还应该考虑以下因素该包是否会进入生产环境应用程序是否实际使用了受漏洞影响的功能攻击者是否能够访问对应的攻击入口是否存在其他防护措施可以降低风险其中依赖安全中一个非常重要的概念就是区分直接依赖和传递依赖。直接依赖是开发者在项目文件中显式声明的 NuGet 包例如ItemGroup PackageReference IncludeSerilog.AspNetCore Version8.0.0 / PackageReference IncludeMicrosoft.EntityFrameworkCore.SqlServer Version8.0.2 / /ItemGroup这里的Serilog.AspNetCore和Microsoft.EntityFrameworkCore.SqlServer就属于直接依赖。而传递依赖则不同——假设应用程序依赖包 AA 又依赖包 BB 又依赖包 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/checkoutv4 - name: Setup .NET SDK uses: actions/setup-dotnetv4 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 ManagePackageVersionsCentrallytrue/ManagePackageVersionsCentrally /PropertyGroup ItemGroup PackageVersion IncludeSerilog.AspNetCore Version8.0.0 / PackageVersion IncludeMicrosoft.EntityFrameworkCore.SqlServer Version8.0.2 / /ItemGroup /Project项目中只声明使用哪个包而不指定版本ItemGroup PackageReference IncludeSerilog.AspNetCore / PackageReference IncludeMicrosoft.EntityFrameworkCore.SqlServer / /ItemGroup这样做的好处是依赖版本集中管理当发现某个包存在漏洞时不需要在几十个.csproj文件中逐个查找和修改版本统一升级后通过 CI 完成构建和测试验证管理起来更加容易。传递漏洞的特殊处理与依赖覆盖测试传递依赖出现漏洞时处理起来通常比直接依赖更复杂因为首先需要回答一个问题到底是哪个 NuGet 包把这个漏洞依赖带进来的例如项目依赖包 AA 依赖包 BB 依赖存在漏洞的包 C。如果直接升级包 A 就能够解决问题通常这是最理想的方案因为包 A 的新版本可能已经调整了自己的依赖关系并经过了官方兼容性验证。常见的处理方式包括升级直接依赖升级解决方案中的相关包升级或替换引入漏洞的第三方组件移除不必要的依赖在确认兼容性的情况下对传递依赖进行版本覆盖。有些情况下开发者可能会选择显式引用一个更安全的版本以影响 NuGet 最终解析出的依赖版本ItemGroup PackageReference IncludeSystem.Text.Json Version8.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 扫描、容器扫描和应用程序安全测试持续关注依赖维护状态和版本老化问题让严重漏洞能够阻止生产发布让安全报告具有明确的可操作性避免简单地全面忽略或抑制漏洞警告维护完整、可审计的漏洞修复流程。