• 文档
• 教程
• 后端

导读

本文基于 nodebestpractices 仓库 Docker 实践章节中的"生产环境之前扫描整个镜像"（Scan the entire image before production）一节，为你讲解：为什么只扫描源代码依赖远远不够、Docker 镜像扫描器三大家族各自的定位，以及如何用 Trivy 在发布前对最终镜像做一次"E2E 级"的漏洞体检。读完本文，你将掌握在 CI/本地流水线中落地镜像扫描的具体命令、结果解读方法与阈值设置策略，把容器安全防线补全到"产物级"。

为什么只扫描代码依赖并不足够

很多团队会在 CI 中对package.json的依赖做漏洞扫描（例如npm audit、Snyk 的代码扫描），这是一项有价值的动作，但它无法覆盖所有潜在威胁，原因有两个：

1. 漏洞不仅存在于应用层依赖，也存在于操作系统层。Node.js 应用最终会在容器内执行 Shell、Tarball、OpenSSL 等系统二进制文件，这些 OS 级组件的漏洞（例如 libc、OpenSSL、curl 等库中的 CVE）不会出现在依赖扫描报告里，却会真实地成为攻击面。
2. 代码扫描之后，仍可能被注入有漏洞的依赖。供应链攻击（supply chain attack）可以在构建过程中替换或注入恶意/脆弱依赖——此时你之前对package.json的扫描结果已经"过期"。

因此，在生产环境部署前的最后一步，对组装完成的最终镜像本身做一次扫描，才是更稳妥的做法。

从源码结构看，仓库在 sections/docker/scan-images.md 中把这一理念与 E2E 测试做了类比：各个组件（代码、依赖、OS 二进制、配置）已分别测试过后，还需要对"组装后的完整交付物"做最终检查——镜像扫描正是容器发布流水线中的这一道 E2E 安全检查。

三大扫描器家族：定位与选型

按部署形态，镜像扫描器主要分为三类：

其中第一类（本地/CI 二进制）是社区最常用且速度最快的方案，代表工具包括：

• Trivy（Aqua Security 出品）
• Anchore（Anchore Engine）
• Snyk（Container security 模块）

值得注意的另一点是：大多数 CI 厂商（如 Jenkins、GitLab CI、CircleCI、GitHub Actions 等）都提供了与这些扫描器交互的本地插件，你可以直接把扫描步骤挂进现有流水线，而不必自行编写复杂的集成逻辑。

实操：用 Trivy 扫描最终镜像

原文档给出的最小可行示例是：在 Linux 主机上安装 Trivy 的.deb包，然后对目标镜像执行扫描：

$ sudo apt-get install rpm $ wget https://github.com/aquasecurity/trivy/releases/download/{TRIVY_VERSION}/trivy_{TRIVY_VERSION}_Linux-64bit.deb $ sudo dpkg -i trivy_{TRIVY_VERSION}_Linux-64bit.deb $ trivy image [YOUR_IMAGE_NAME]

其中各步骤的作用如下：

1. sudo apt-get install rpm：安装rpm包解析工具，Trivy 扫描基于 RPM 的 OS 层（如 CentOS、Fedora、Alpine 的 APK 索引以外的发行版）时依赖它来解析软件包元数据；
2. wget .../trivy_{TRIVY_VERSION}_Linux-64bit.deb：从 Trivy 官方 Release 下载对应版本的 Debian 安装包，{TRIVY_VERSION}需替换为实际版本号（例如0.45.0）；
3. sudo dpkg -i ...：用 Debian 包管理器完成安装；
4. trivy image [YOUR_IMAGE_NAME]：扫描目标镜像，[YOUR_IMAGE_NAME]替换为你的镜像名（可含 tag，如my-app:1.0.0或my-app:latest）。

执行后 Trivy 会输出一份漏洞清单，包含漏洞 ID（如 CVE 编号）、严重级别（CRITICAL/HIGH/MEDIUM/LOW）、受影响的软件包以及修复建议（Fixed Version）。如果你只想快速查看高危项，可以追加过滤参数，例如trivy image --severity CRITICAL,HIGH --ignore-unfixed [YOUR_IMAGE_NAME]——后者还能跳过尚未有修复版本的漏洞，让报告更聚焦。

说明：本示例命令直接取自仓库文档 sections/docker/scan-images.md（日文版见 sections/docker/scan-images.japanese.md），适用于 Debian/Ubuntu 系的 Linux 环境；macOS 用户可改用 Homebrew 安装，其他平台请参考 Trivy 官方文档的安装方式。

配合仓库实践：先把镜像做"瘦身"，再扫描

镜像扫描报告的质量，很大程度上取决于你喂给扫描器的镜像是什么。nodebestpractices 仓库的 Docker 章节提供了一整套"构建一个干净、最小、可扫描镜像"的配套实践，与镜像扫描互为表里——镜像越小、组件越少，攻击面与扫描噪音就越少：

• 使用多阶段构建（multi-stage builds）：在构建阶段安装 TypeScript CLI、编译工具等开发依赖，运行时阶段只复制构建产物与生产依赖。完整的示例见 sections/docker/multi_stage_builds.md，仓库还附带了一个可直接参考的 示例 Dockerfile（基于node:14.8.0-alpine构建 TypeScript 应用）。
• 选择更小的基础镜像：官方 Node.js 镜像约 345MB，而 Alpine 变体仅约 39MB（接近 10 倍差距）；基于 Debian 的 Slim 变体也仅约 38MB。详见 sections/docker/smaller_base_images.md。更小的镜像意味着更少的 OS 包，扫描器需要比对的漏洞面也更小。
• 只安装生产依赖：用npm ci保证基于 lockfile 的全新安装，并在运行时阶段执行npm prune --production清理开发依赖，最后npm cache clean --force清掉本地缓存（可再省数十 MB）。实践细节见 sections/docker/install-for-production.md。
• 用 .dockerignore 过滤敏感文件：避免.npmrc、.aws、.env等包含密钥的文件被复制进构建上下文，同时还能提升构建缓存命中率。推荐的默认清单见 sections/docker/docker-ignore.md。

把这套流程串起来，一条推荐的流水线顺序是：多阶段构建 → Alpine/Slim 基础镜像 → 只装生产依赖 → 清缓存 → 对最终镜像执行 Trivy 扫描 → 达到阈值才允许部署。

读懂扫描报告：以 Anchore 输出为例

原文档用一张 Anchore 的扫描结果截图直观展示了这类报告的样子：

Anchore Docker 镜像扫描报告示例

从报告结构可以看出，容器镜像扫描的结果通常按层（Layer）与软件包维度展开，列出每个 OS 包或依赖对应的 CVE、严重级别、以及是否存在修复版本。这类报告的价值在于：它能同时覆盖应用依赖层与OS 二进制层——这正是"只扫代码"做不到的。

阈值策略：避免被海量结果淹没

原文档特别提醒：这些扫描器覆盖面很广，几乎每次扫描都会报出若干发现（findings）——尤其是对长期未更新的基础镜像，一次扫描可能输出成百上千条记录。如果不对结果做分级治理，团队很容易被报告淹没，最终反而忽视真正的严重问题。

因此建议：

1. 设置高阈值门槛：例如规定"存在未修复的 CRITICAL 级漏洞则阻断发布"，HIGH 及以下级别仅记录或走人工评估，而不是一有发现就全量阻塞流水线；
2. 区分"已修复可升级"与"无修复版本"：优先处理有修复版本的漏洞，对上游尚未出修复的条目单独跟踪（Trivy 的--ignore-unfixed正是为此设计）；
3. 固定基础镜像并定期重建：结合仓库中关于镜像 tag 与 lockfile 的实践（参见 sections/docker/image-tags.md 与 sections/production/lockdependencies.md），让每次扫描都基于可复现的产物，减少"玄学式"的扫描噪音。

小结

一句话总结这条最佳实践：在 Node.js 容器应用部署到生产环境之前，把"扫描最终镜像"作为流水线的最后一道关卡。它与 E2E 测试的思路同源——每个组件都测过之后，仍然要对组装好的交付物做最终验证；镜像扫描恰好补上了代码依赖扫描覆盖不到的 OS 层与供应链注入风险。工具选型上，Trivy、Anchore、Snyk 均值得评估，且主流 CI 大多有现成插件可挂；执行策略上，先按仓库配套实践把镜像做小、做干净，再以"高阈值 + 分级治理"的方式解读扫描结果，即可在不被噪音淹没的前提下守住生产发布前的最后一道安全防线。

• 文档
• 教程
• 后端