在微服务架构下，.NET 应用通常被打包成基于 mcr.microsoft.com/dotnet/aspnet 的容器镜像。这些镜像除了业务 DLL，还包含基础操作系统包、.NET 运行时以及通过 NuGet 还原的第三方库。任何一层存在已知漏洞，都可能成为攻击者进入集群的入口。Trivy 作为一款轻量且开源的漏洞扫描工具，能够无代理地解析镜像分层结构，将各层中的软件成分与漏洞数据库比对，从而给出易于理解的结果。
安装与准备 Trivy 扫描环境
要在本地对 .NET 容器镜像进行扫描，第一步是获取 Trivy 二进制。Linux 用户可以通过包管理器或官方发布的压缩包安装，Windows 用户则能直接使用 Chocolatey 或下载 exe 文件。安装完成后，建议先执行 trivy image --download-db-only 把漏洞库拉取到本地，这样后续扫描无需重复联网查询，速度更稳定。对于内网环境，还可以搭建私有镜像仓库的缓存代理，让 Trivy 指向本地漏洞库镜像。
准备阶段另一个重点是确认 Docker 或兼容的容器运行时可用。Trivy 默认会调用本机 docker 命令来拉取并挂载镜像层，如果是在 CI 机器上，需保证执行账号拥有访问 /var/run/docker.sock 的权限。若不想依赖 docker，也可使用 --input 参数直接读取保存好的 tar 包，比如先用 docker save 导出 .NET 镜像，再交给 Trivy 离线分析。这种方式在严格隔离的构建节点中非常实用。
针对 .NET 场景，我们还应当留意基础镜像的标签选择。很多团队习惯使用 aspnet:latest，但 latest 随时变动，会导致扫描结果不可复现。推荐在 CI 中固定到具体版本，如 aspnet:8.0.0，并在扫描命令里显式写出完整镜像名。这样当 Trivy 报出某个运行时漏洞时，你能明确知道它来自哪一个确切构建，而不是模糊的 latest 引用。
执行 .NET 镜像漏洞扫描的常用命令
最基础的扫描只需一行命令：trivy image mcr.microsoft.com/dotnet/aspnet:8.0.0。Trivy 会自动拉取镜像、解构层级并输出表格，列出每个漏洞的 ID、严重程度、所在包以及修复版本。对于 .NET 应用，你通常会看到两部分内容，一部分是 Debian 或 Ubuntu 基础系统的 CVE，另一部分是 .NET 运行时自身的公告，例如 ASP.NET Core 某个补丁级别的问题。
如果需要把扫描集成进脚本，可以使用 --severity 过滤高危项，并用 --exit-code 1 让发现中危以上漏洞时命令返回非零状态。例如下面这段命令会只关注 HIGH 和 CRITICAL，且遇到这类漏洞就中断流程：
trivy image --severity HIGH,CRITICAL --exit-code 1 mcr.microsoft.com/dotnet/aspnet:8.0.0
除了系统层，Trivy 也能识别项目源码目录里的依赖清单。在 .NET 工程根目录执行 trivy fs . 时，它会解析 .csproj 和 packages.lock.json，找出有问题的 NuGet 包。这弥补了仅扫镜像时可能遗漏的构建期依赖。不过要注意，若项目使用私有源且未还原锁文件，Trivy 只能基于已有文件推断，建议 CI 中先执行 dotnet restore 再扫描文件系统。
解读报告与在 CI 流水线中落地
Trivy 的输出表格中，每一行都包含漏洞编号如 CVE-2024-1234，以及对应的 Package 和 Current Version。以 .NET 为例，若看到 aspnetcore-runtime 出现在 Package 列，说明问题出在运行时层，通常需要升级基础镜像版本而非修改业务代码。而若是 Newtonsoft.Json 之类的 NuGet 包，则应在项目文件里提升版本号并重新构建。
在 GitHub Actions 或 GitLab CI 中，可以把扫描作为独立阶段。下面给出一个简单的 GitHub Actions 步骤片段，它先构建镜像，再用 Trivy 扫描，若发现严重漏洞则让任务失败：
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build image
run: docker build -t my-dotnet-app:ci .
- name: Trivy scan
uses: aquasecurity/trivy-action@master
with:
image-ref: 'my-dotnet-app:ci'
severity: 'HIGH,CRITICAL'
exit-code: '1'
落地时常见误区是只扫一次就完事。实际上 .NET 基础镜像几乎每月都有补丁，今天干净的镜像一个月后可能暴露新 CVE。因此应把 Trivy 扫描做成定时任务，比如每周对生产镜像重新检测，并把报告发送到团队安全频道。同时，建议在合并请求阶段也跑轻量扫描，避免已知漏洞合入主干。通过这种持续方式，容器安全才能真正左移，而不是发布前临时补救。
处理误报与定制扫描策略
在真实使用中，Trivy 偶尔会把某些已声明不受影响或已通过上游修复的包标记为漏洞，这就是误报。对于 .NET 团队，可能遇到 Debian 系统库被标记，但微软官方基础镜像其实已通过其他机制缓解。此时可以维护一个 .trivyignore 文件，按漏洞 ID 忽略特定项，并写明原因供审计追溯。
另外，Trivy 支持通过策略文件做更细粒度控制。比如你只关心直接打包进镜像的 NuGet 包，而不想被操作系统层干扰，可以在配置里关闭相关扫描器。反之，若监管要求连低风险也要记录，就去掉严重度过滤，把所有结果导出为 JSON，再用自定义脚本统计趋势。下面示例展示如何生成 JSON 报告：
trivy image --format json --output dotnet-scan.json mcr.microsoft.com/dotnet/aspnet:8.0.0
定制策略还应结合 .NET 版本生命周期。若产品仍运行在 .NET 6 这类已进入支持尾声的版本，Trivy 报出的运行时漏洞可能无法通过小版本升级解决，只能规划大版本迁移。把这些上下文写进团队的扫描说明文档，能让安全报告从单纯罗列 CVE 变成可执行的工程决策，而不是开发手里的一张作废清单。