容器镜像在推送到镜像仓库之前必须完成漏洞扫描，把高危组件拦在入库门外，这是当前交付流水线里回报最高的安全动作。
Docker镜像漏洞扫描和入库后扫描对比：时间差就是风险差
先看一个真实场景,某电商团队周三下午发现生产镜像里含有Log4j高危漏洞，但那个镜像已经进入Harbor仓库，还被三个测试环境拉取过，入库后再扫描，等于污染扩散之后才做水质检测。
这就是时间差带来的风险差,入库前扫描和入库后扫描，看着只是顺序不同，实际影响完全不同。
| 对比项 | 入库前扫描 | 入库后扫描 |
|---|---|---|
| 扫描时点 | 构建完成后、推送之前 | 已进入仓库，可能已被拉取 |
| 影响范围 | 只影响当前构建流水线 | 可能已扩散到测试、预发环境 |
| 修复动作 | 修改Dockerfile或依赖后重新构建 | 同时处理仓库、节点、运行容器 |
| 流水线阻塞 | 有针对性阻断，成本低 | 往往需要紧急回滚和全量排查 |
| 安全水位 | 主动拦截 | 被动响应 |
行业共识认为,漏洞发现得越早，修复动作越轻，供应链污染面越小，把扫描卡在入库前，等于把已知风险挡在制品库门外，镜像一旦进入仓库，再想追回，就不是一条命令能解决的事了。
镜像仓库安全扫描怎么做？入库前卡住这道门
很多团队不是不想做,而是不知道从哪儿下手，入库前扫描的关键不是装一个工具，而是把扫描节点放到正确的位置：构建完成之后，推送之前。
在CI流水线里插入扫描节点
以GitLab CI为例，流水线可以拆成三步：构建、扫描、推送。
build:
script:
- docker build -t registry.example.com/app:latest .
scan:
script:
- trivy image --severity HIGH,CRITICAL --exit-code 1 registry.example.com/app:latest
push:
script:
- docker push registry.example.com/app:latest
needs: ["scan"]
--exit-code 1 表示发现高危或严重漏洞时，命令返回非零状态，GitLab会中断后续任务，镜像自然不会被推送，这就是最基本的入库前拦截。
在镜像仓库侧配置漏洞策略
如果团队已经在使用Harbor,还可以再做一层仓库侧策略，操作路径是：项目 -> 策略 -> 漏洞扫描，勾选“阻止潜在漏洞的镜像”。
这里可以设置严重级别,多数团队会把Critical设为必须阻断，High设为需要人工确认，注意不要把阈值设得太低，否则一次中危漏洞也会让整个流水线停下，开发效率会明显下降。
把基础镜像扫描放进构建前检查
很多漏洞不是业务代码带进来的,而是基础镜像里就有的，Dockerfile第一行写 FROM node:18-alpine，构建前可以先跑一次：
trivy image node:18-alpine
如果基础镜像里已经存在高危OpenSSL版本,那就换一个更干净的版本再开始构建，入库前扫描不只是扫最终镜像，也扫起点。
容器镜像漏洞扫描工具哪个好？先看这3个标准
工具选型不能只看名气,入库前扫描对工具的要求和日常安全审计不一样。
先看三个标准：
- 漏洞库更新速度：新漏洞爆发后，工具多久能识别
- CI/CD集成难度：能不能一条命令跑完，能不能门禁式阻断
- 扫描结果可操作性：输出里能不能直接定位到包名和修复版本
业内专家指出,没有哪个工具适合所有场景，关键看它在你流水线里的位置和脾气。
| 工具 | 扫描对象 | 授权模式 | 主要特点 |
|---|---|---|---|
| Trivy | OS包、语言依赖、IaC文件 | 开源免费 | 命令简单，适合CI阶段 |
| Grype | OS包、语言依赖 | 开源免费 | 输出格式友好，适合单独扫描 |
| Clair | OS包为主 | 开源免费 | 与Quay、Harbor集成顺 |
| Docker Scout | 镜像、依赖、策略 | 商业订阅 | 云侧策略和持续监控较好 |
中小团队多数选择Trivy作为第一道闸门
不是因为它最强大,而是因为它最容易跑起来，一个上海SaaS团队在GitLab Runner上跑Trivy，每次构建扫描控制在几十秒内，误报通过
.trivyignore 文件过滤，零许可成本，流水线改动也小。
容器漏洞扫描收费吗？开源和商业账本要分开算
很多人一听到漏洞扫描,脑子里先跳出“贵不贵”，其实这个问题的答案取决于你用什么路线。
开源工具的免费账单
Trivy、Grype、Clair这类工具本身免费，但免费不等于零成本，你得自己维护漏洞数据库更新，处理误报，调优策略，还要安排人理解扫描结果。
对一个小团队来说,这是把现金支出换成了人力支出，如果团队里没有对漏洞库和Linux包管理特别熟的人，可能折腾几天也调不好阻断策略。
商业扫描服务的计费方式
商业方案多数按扫描次数、仓库节点数或年订阅计费，部分提供有限免费额度，适合先评估再决定。
商业工具的核心价值不在“扫描”本身，而在于漏洞库托管、误报率控制、合规报告导出，如果团队经常要应付等保或行业检查，商业扫描可以直接给出符合要求的报告。
| 维度 | 开源工具 | 商业服务 |
|---|---|---|
| 初始现金投入 | 低 | 中高 |
| 持续维护人力 | 中 | 低 |
| 漏洞库更新 | 手动或定时同步 | 厂商托管 |
| 误报调优 | 团队自己处理 | 厂商辅助 |
| 合规报告 | 需要自己生成 | 多数内置 |
相当一部分团队的做法是：入库前用开源工具做阻断，仓库侧再按需采购商业扫描做持续监控和报告。
上海容器镜像安全扫描服务怎么选？私有化部署是关键
上海及周边的金融、医疗、政务团队，对镜像数据出域非常敏感，把镜像推给外部SaaS扫描，很多时候不被允许，这时候选型标准就变成：扫描器能不能本地运行。
先确认扫描器是否能本地运行
Trivy、Grype、Clair都支持完全本地运行，商业方案如果只提供云API，就需要评估数据出境或出域风险，私有化部署不是加分项，在这些行业里往往是准入门槛。
把漏洞库更新也留在内网
内网环境通常不能直接访问外网更新漏洞库,Trivy支持离线模式：
trivy image --skip-update --cache-dir /data/trivy your-image:tag
可以把漏洞库下载到本地后定期同步进内网,扫描器完全不需要出网，这样既满足了入库前扫描，也守住了数据边界。
入库前扫描的实操清单和常见误区
误区比工具更危险,很多团队扫了一段时间后发现效果不好，不是工具不行，而是踩了这几个坑。
- 只扫应用代码,不扫基础镜像，结果漏洞从根上漏进来
- 扫描阈值设得太低,中危漏洞也阻断，流水线天天挂
- 漏洞库长期不更新,扫描形同虚设
- 只看漏洞数量,不看是否已有修复版本和可利用路径
实操清单建议直接贴在CI配置旁边：
- 构建后立即扫描,不跳过任何一次构建
- Critical必须阻断,High需人工确认
- 固定基础镜像版本,不用
latest漂移 - 每周重扫一次已有仓库镜像,因为新漏洞会持续出现
- 扫描结果输出到CI日志,同时留存机器可读格式
入库前扫描不是添堵，是最便宜的一次拦截
把漏洞挡在镜像仓库门外,比事后从生产环境里拔出来容易得多，入库前扫描不需要高大上的平台，一条命令加一个阻断策略，就能拦住相当一部分已知风险。
容器镜像入库前漏洞扫描必须做吗？
必须做,多数生产事故里的高危漏洞或恶意投毒，都是通过未经验证的镜像直接进入仓库后扩散，入库前扫描成本远低于事后应急处理。
镜像入库前扫描用Trivy还是Clair？
如果扫描点放在CI流水线,Trivy更轻，命令简单，适合开发团队直接使用，如果扫描点固定在镜像仓库，Clair与Quay或Harbor集成更顺，多数团队会用Trivy做入库前第一道拦截，Clair做仓库侧持续复核。
容器漏洞扫描会拖慢CI流水线吗？
首次扫描会下载漏洞库,之后缓存命中，多数中型镜像扫描在几十秒到几分钟之间，通过并行运行和只扫高危级别，可以把影响控制在可接受范围，部分团队把完整扫描放在夜间执行，同时保留入库前的高危阻断扫描，是目前多数高发布频率团队采用的折中方案。