你想象这样的场景：你要坐飞机去旅行，出发前把衣服、洗漱用品、电脑塞进一个行李箱。过安检时，X 光机会把箱子里的每一层夹层都照一遍，对照全球通缉名单检查有没有违禁品；如果有问题，安检员会叫你开箱处理。容器安全扫描干的就是这件事——你把应用打包成一个“行李箱”（镜像），在它登机之前，用“X 光机”（Trivy、Grype 等扫描器）对照“通缉名单”（CVE 漏洞数据库）逐层检查。发现可疑软件包就提醒你，在 CI 流水线里设一道“安检闸机”拦截问题构建，最后再对查出来的违禁品分级处置、维护一套“标准打包方案”（基线镜像）。这篇文章就带你完整走一遍这套流程：安检为什么重要、通缉名单怎么维护、X 光机怎么选、夹层里藏了钥匙怎么办、闸机怎么设，以及查出来的违禁品如何分级处理。

岗位关联

容器安全扫描是 DevOps 工程师的“上线安检防线”，掌握它意味着你能够在应用发布前拦截已知漏洞、密钥泄露与不安全配置，把生产事故和合规风险挡在门外——这是 AI 工程化落地中必备的工程素养。

目录
  1. 可视化演示
  2. 安全扫描概述
  3. 漏洞数据库机制
  4. 扫描工具对比
  5. 敏感信息检测
  6. CI流水线集成
  7. 分级处置与维护
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示镜像层扫描检测CVE漏洞、漏洞严重性分级及CI/CD流水线安全门禁三种核心安全扫描模式。

本节配有交互动效（进入视口后自动加载，约 3KB）。

镜像层扫描检测 逐层解析镜像文件系统匹配CVE漏洞数据库 扫描波逐层穿透检测存在风险的软件包 layer × CVE_DB → vulns Trivy/Grype对比镜像层与漏洞库识别风险组件

安全扫描概述

想象你去机场：行李托运前，安检机要把它从里到外照一遍；到了登机口，还要再核验一次身份。容器世界也分两道关卡：镜像（image）是打包好的行李箱，容器（container）是行李在目的地被打开使用的状态。镜像安全扫描的核心任务，就是在“托运”之前——也就是构建阶段——把箱子彻底检查一遍。

为什么要选构建阶段？因为此时发现问题，改一行代码重新打包，成本几乎为零；如果等镜像已经在生产环境跑起来才发现漏洞，就像行李已经上了飞机才想起夹层里藏了违禁品，处理代价巨大。运行阶段当然也有防护手段，比如只读文件系统、最小权限运行，但这些是“落地后的隔离”，替代不了登机前的检查。

镜像的攻击面主要有三个入口：基础镜像、软件依赖、应用配置。基础镜像相当于箱子的骨架，骨架如果用了有漏洞的操作系统镜像，往里塞再多新衣服也白搭。安全扫描要做三件事：查漏洞（CVE）、查密钥（敏感信息）、查配置（不安全的运行方式）。而这一切的前提，是准确识别镜像身份——每一层文件系统变更都会算出一个唯一的“指纹”，也就是 digest。

回到安检口：安检员先把行李箱的整体信息录进系统，确认身份无误，才敢开始逐层扫描。镜像的 digest 就是这张“身份证”，而接下来通缉名单怎么查，就是下一节的故事。

digest=SHA256(层数据)\text{digest} = \mathrm{SHA256}(\text{层数据})
这一行公式的意思是：镜像每一层的内容都会经过 SHA256 哈希运算，生成一串固定长度的“指纹”。任何一字节的改动都会让指纹完全变化，所以它能用来确认这一层没被篡改、没被偷偷塞入额外文件。
  1. 层数据采集镜像每一层都记录一次文件系统变更，扫描前先把这一层含有的全部文件拼成待校验的数据块。
    layer={Δf1,Δf2,…,Δfn}\text{layer} = \{\Delta f_1, \Delta f_2, \dots, \Delta f_n\}
  2. SHA256 哈希压缩把任意长度的层数据压缩成固定 256 位的摘要，内容改动一个字节，摘要就完全不同。
    H:{0,1}∗→{0,1}256H: \{0,1\}^* \to \{0,1\}^{256}
  3. 输出指纹 digest得到的哈希值就是这一层的身份指纹；各层指纹再串联后整体哈希，就形成整个镜像的唯一标识。
    digestimage=SHA256(d1∥d2∥…∥dn)\text{digest}_{\text{image}} = \mathrm{SHA256}(d_1 \| d_2 \| \dots \| d_n)

漏洞数据库机制

安检员能一眼认出违禁品，靠的不是过目不忘，而是手里那本实时更新的“全球通缉名单”。容器安全的通缉名单，就是漏洞数据库。全球的安全研究员发现软件漏洞后，会向 CVE（Common Vulnerabilities and Exposures，公共漏洞与暴露）机构申请一个唯一编号，就像给每个逃犯发一张通缉令。

一条 CVE 记录通常包含三样信息：漏洞编号（如 CVE-2024-3094）、受影响的软件包及版本区间、以及严重程度评分。扫描器要做的事情看似简单却很严谨——把镜像里每一个软件包的名称和精确版本，拿去和名单逐条比对，命中就报告。这好比安检系统扫描到行李箱里一件物品，自动和通缉名单上的物品特征做匹配。

严重程度通常用 CVSS 评分量化，0 到 10 分，分数越高越危险。但请注意：同一个漏洞，在不同镜像里的实际风险并不一样。一个只在容器内部使用的库，和一个直接暴露在公网端口上的服务，风险天差地别。所以最终处置优先级还要乘上“可利用性”和“暴露程度”两个系数。

名单本身也得与时俱进。漏洞数据库通常每小时到每天更新一次，如果拿着去年的名单抓今年的逃犯，安检形同虚设。这也是为什么“扫过一次没漏洞”不能代表永远安全。

R=Wseverity×Eexploit×IexposureR = W_{\text{severity}} \times E_{\text{exploit}} \times I_{\text{exposure}}
通俗地说：漏洞风险不是只看“通缉令上的赏金”，还要看“这个逃犯有没有武器、有没有可能出现在你家门口”。三项相乘，才是你该采取行动的紧急程度。
  1. 严重度权重 W漏洞自身的 CVSS 评分，介于 0 到 10 分，评分越高说明漏洞越致命，这是通缉令的基本赏金。
    Wseverity∈[0,10]W_{\text{severity}} \in [0, 10]
  2. 可利用性系数 E表示漏洞被真实利用的难易与热度，攻击代码已公开时趋近 1，仅有理论可能时趋近 0。
    Eexploit∈[0,1]E_{\text{exploit}} \in [0, 1]
  3. 暴露系数 I表示该软件是否暴露在网络可达路径上，无法被外部访问时取 0，可被公网直接访问时取 1。
    Iexposure∈{0,0.5,1}I_{\text{exposure}} \in \{0, 0.5, 1\}
  4. 综合风险分 R三项相乘得到实际风险优先级，分数越高越要先处理。
    R∈[0,10]R \in [0, 10]

扫描工具对比

安检机也有不同型号：有的吞吐量大、适合机场高峰，有的识别种类全、适合重点旅客。容器扫描工具里，Trivy 和 Grype 是两款明星产品，相当于安检设备里的“快速型”和“精细化”两台机器。

Trivy（读作“try-vee“）由 Aqua Security 开源，单个二进制文件就能运行，安装简单、扫描速度快，开箱即用。它不只扫系统软件包，还能扫编程语言依赖、检测硬编码密钥，以及检查基础设施即代码（IaC）配置。Grype 由 Anchore 出品，最大的特色是和 Syft 工具深度联动——Syft 先从镜像里提取一份”软件物料清单”（SBOM），Grype 再基于这份清单做精细审计，相当于先给行李箱登记所有物品再逐件核对。

怎么选？看三点：一是团队生态，如果已经在用 Anchore 的整套方案，Grype 更顺；二是扫描范围，需要 IaC 巡检时 Trivy 更省事；三是性能预算，两者都支持漏洞库缓存和增量扫描，在 CI 里都能把耗时压到几秒到几十秒。不同型号的 X 光机，看的还是同一份通缉名单——匹配逻辑才是核心。

就像安检机再好也要定期升级识别算法，扫描工具同样需要及时更新漏洞库和扫描规则，否则再贵的设备也会漏检。

match(p,v)=1{(p,v)∈DBCVE}\text{match}(p, v) = \mathbf{1}\{(p, v) \in \mathrm{DB}_{\mathrm{CVE}}\}
这行公式描述了扫描器工作的本质：拿镜像里解析出的“包名+版本”，去 CVE 数据库里查有没有对应记录。命中返回 1，就是发现一个已知漏洞。
  1. 提取软件包信息扫描器先解析镜像文件系统，整理出每个软件包的名称和精确版本，比如 openssl 1.1.1t。
    (p,v)=(package_name,version)(p, v) = (\text{package\_name}, \text{version})
  2. 定义 CVE 数据库集合数据库由多条“包名 + 受影响版本区间 + 漏洞编号”的记录构成。
    r=(pkg,  [vmin⁡,vmax⁡],  CVE-ID)r = (\text{pkg},\; [v_{\min}, v_{\max}],\; \text{CVE-ID})
  3. 指示函数判定当包名与版本同时落入某条记录的区间，函数输出 1，表示命中一个已知漏洞。
    1{⋅}∈{0,1}\mathbf{1}\{\cdot\} \in \{0, 1\}

敏感信息检测

安检最怕的不是液体，而是有人在行李箱夹层里藏了一把你家钥匙。镜像里的硬编码密钥，就是这把钥匙——数据库密码、API Key、云厂商密钥一旦被打进镜像，等于把大门钥匙贴在了行李标签上。

敏感信息泄露有三个常见来源。第一是硬编码：开发图省事，把密钥直接写在代码或配置文件里。第二是历史层残留：你以为文件删掉了，但旧的镜像层依然保存着这些内容，就像行李夹层里那张用过的登机牌，不拆开根本发现不了。第三是不安全配置：用 root 用户运行容器、暴露高危端口、装了调试工具却忘了关。

扫描器通过内置的规则库识别常见密钥格式，比如 OpenAI 的密钥以 sk- 开头、AWS 密钥以 AKIA 开头。一旦命中，就报告文件路径和行号。修复办法不是“删掉再重建”这么简单——密钥泄露必须立即轮换（作废旧密钥、生成新密钥），同时清理镜像层、重建镜像，确保旧密钥在任何历史层都不再出现。

夹层里的钥匙，光拿出来还不够——锁必须换。同理，密钥一旦泄露，正确姿势永远是先轮换、再清理、最后重建镜像。

Alert(s)=1{s∈Lsecret}\text{Alert}(s) = \mathbf{1}\left\{ s \in \mathcal{L}_{\text{secret}} \right\}
这段公式是说：扫描器把每个文件的文本拿去和“密钥规则语言”比对，一旦匹配就发出告警，告警里带着文件路径、行号和密钥类型，方便你精准定位处置。
  1. 定义密钥规则语言规则库描述各种服务商密钥的格式，比如 OpenAI 密钥以 sk- 开头、AWS 密钥以 AKIA 开头。
    Lsecret={s∣s 符合已知密钥模式}\mathcal{L}_{\text{secret}} = \{s \mid s \text{ 符合已知密钥模式}\}
  2. 字符串匹配判定把被扫描文件内容逐段与规则语言比对，命中输出 1，未命中输出 0。
    1{⋅}∈{0,1}\mathbf{1}\{\cdot\} \in \{0, 1\}
  3. 告警信息结构化告警记录包含文件路径、所在行号与密钥类型，供开发人员快速定位与处置。
    Alert=(path,line,type)\text{Alert} = (\text{path}, \text{line}, \text{type})

CI流水线集成

机场光有安检机还不够，登机口还有一道自动闸机：机票信息对不上，闸机就不开。把扫描放进 CI 流水线，就是给镜像发布装上一道自动闸机。

推荐的流水线阶段是：代码构建产出镜像 → 镜像安全扫描 → 生成扫描报告与 SBOM → 推送镜像仓库 → 部署上线。扫描是硬性门禁，不是可选项。门禁用阈值表达，比如“存在任何一个 Critical（严重）漏洞，或者 High（高危）漏洞超过 5 个，构建直接 FAIL”。

实现上，扫描应尽量在镜像构建完成后立刻执行，利用漏洞库缓存避免重复下载，把扫描时间控制在秒级。报告需要归档，方便后续审计和追溯——出了事故翻记录，谁批准的这个镜像，一目了然。还可以把“扫描通过”作为推送镜像到生产仓库的前置条件，从源头杜绝问题镜像流向下游。

闸机的好处是铁面无私：不管是谁提交的构建，分数超了就是不让过。这比依赖某个人“记得跑一下扫描”可靠得多。

Gate={PASSmax⁡iSi≤TFAILmax⁡iSi>T\text{Gate} = \begin{cases} \text{PASS} & \max_i S_i \leq T \\ \text{FAIL} & \max_i S_i > T \end{cases}
门禁的数学表达：把所有漏洞分数拉出来，看最高分有没有超过阈值 T。超过就 FAIL 阻断，没超过就 PASS 放行。安全策略本质上就是一次“最坏情况判断”。
  1. 采集扫描结果列表流水线把扫描报告中的每个漏洞及其风险分整理成列表。
    S={s1,s2,…,sn}S = \{s_1, s_2, \dots, s_n\}
  2. 取风险最大值门禁关注最坏情况，以最高分代表该镜像的风险水位。
    Smax⁡=max⁡iSiS_{\max} = \max_i S_i
  3. 与阈值比较阈值 T 由团队按业务容忍度设定，通常以高危分数为门槛。
    T∈[0,10]T \in [0, 10]
  4. 输出门禁决策高于阈值则 FAIL 阻断流水线，反之 PASS 放行进入发布环节。
    Gate∈{PASS,FAIL}\text{Gate} \in \{\text{PASS}, \text{FAIL}\}

分级处置与维护

安检查出违禁品，处置方式各不同：易燃易爆物当场没收，超量液体现场处理，来路可疑的粉末记录在案、跟踪调查。漏洞处置也是这样，不可能也不应该把所有漏洞一次性修完。

先按严重度分级：Critical（≥9.0）必须立即修复，通常当天处理；High（7.0~8.9）优先安排，一到两天内解决；Medium（4.0~6.9）排入迭代计划；Low（<4.0）持续跟踪。在此基础上，处置优先级 = 严重度 × 可利用性 × 暴露程度。如果某个漏洞经过评估确实无法被利用（比如依赖库从未被调用、服务未暴露外网），可以申请豁免，但必须设复审时间窗，不能永久豁免。

更聪明的做法是从源头治理——维护一个“基线镜像”（也叫黄金镜像）：由安全团队维护，经过完整扫描、高危漏洞清零或全部豁免，并纳入每周自动更新机制。每次漏洞库更新后自动重新构建基线，业务团队所有镜像都从基线派生，相当于整个公司统一使用“通过认证的标准打包方案”，漏洞从源头被压到最低。

有了分级和基线，安检就不再是一刀切：危险品立即没收，普通违禁品按规矩处理，而标准打包方案本身也在不断进化。这就是一套可持续运转的容器安全体系。

B=10−∑i=1nwi×si10B = 10 - \sum_{i=1}^{n} w_i \times \frac{s_i}{10}
基线分就是把每个未修复漏洞的严重度扣除，按资产权重加权求和，再用满分 10 分减去。分数掉到阈值以下，就说明基线镜像已经“脏”了，该重建了。
  1. 统计未修复漏洞基线镜像当前仍有 n 个未修复或已豁免的漏洞，逐一列出。
    V={v1,v2,…,vn}V = \{v_1, v_2, \dots, v_n\}
  2. 分数归一化每个漏洞的 CVSS 分数除以 10，映射到 0 到 1 之间，方便加权。
    si′=si10s_i' = \frac{s_i}{10}
  3. 资产加权求和核心组件的权重 w_i 更大，按资产价值与暴露程度设定。
    D=∑i=1nwisi′D = \sum_{i=1}^{n} w_i s_i'
  4. 计算基线分 B满分 10 分，扣掉加权风险总和；低于阈值就触发基线镜像重建。
    B∈[0,10]B \in [0, 10]

AI 应用场景

AI 推理镜像发布安全门禁

阶段：模型服务构建与发布阶段

解决的问题：AI 推理镜像往往基于完整的 CUDA/驱动镜像，软件包多、体积大，传统做法靠人工检查依赖版本，漏洞全靠上线后知后觉。把扫描器接入镜像构建流水线后，高危漏洞在发布前即被自动拦截，像机场闸机一样铁面无私。

具体案例：某团队上线一个基于 llama.cpp 的推理服务，CI 扫描发现基础镜像中的 OpenSSL 版本命中高危 CVE，流水线当场 FAIL。开发将基础镜像升级到修复版本后重扫通过，避免了“带病上线”。

镜像仓库批量安全巡检

阶段：存量模型服务治理

解决的问题：仓库里躺着几百个历史镜像，哪些有漏洞、哪个最危险，人工根本数不清。定时任务批量扫描全部镜像，生成绩效看板，让风险一目了然。

具体案例：安全团队每周对镜像仓库做全量扫描，按风险评分排序生成 Top10 风险镜像清单，推送通知对应负责人限期处理，并在下次巡检时复核整改情况。

漏洞修复优先级辅助决策

阶段：漏洞运营处置

解决的问题：扫描结果动辄上百条，逐条人工分析成本高。借助大模型阅读扫描报告，结合可利用性信息辅助判断优先级，并生成升级建议，把“查漏”和“补漏”之间的链路缩短。

具体案例：将 Trivy 的 JSON 报告输入 AI 助手，自动提炼“哪些漏洞可被公网利用、建议升级到哪个版本”，形成处置工单分发给对应开发。

Python 演示

python77 行
#!/usr/bin/env python3"""mini-image-scanner.py: 模拟 Docker 镜像安全扫描与 CI 门禁判定""" VULN_DB = [    {"cve": "CVE-2024-2144",  "pkg": "openssl",      "bad_to": "1.1.1",  "score": 9.8},    {"cve": "CVE-2023-44487", "pkg": "nginx",         "bad_to": "1.24.0", "score": 7.5},    {"cve": "CVE-2024-1086",  "pkg": "linux-kernel", "bad_to": "6.1.99", "score": 8.4},    {"cve": "CVE-2022-0847",  "pkg": "curl",          "bad_to": "7.83.0", "score": 7.8},]  def parse_version(ver):    return tuple(int(p) for p in ver.split(".") if p.isdigit())  def is_affected(pkg, version):    for rec in VULN_DB:        if rec["pkg"] == pkg and parse_version(version) <= parse_version(rec["bad_to"]):            return rec    return None  class ContainerScanner:    def __init__(self, layers):        self.layers = layers        self.report_list = []     def scan(self):        self.report_list = []        for layer in self.layers:            for name, ver in layer["pkgs"].items():                hit = is_affected(name, ver)                if hit:                    self.report_list.append(                        {                            "layer": layer["name"],                            "pkg": name,                            "version": ver,                            "cve": hit["cve"],                            "score": hit["score"],                        }                    )        return self.report_list     def summary(self):        total = len(self.report_list)        critical = [v for v in self.report_list if v["score"] >= 9.0]        high = [v for v in self.report_list if 7.0 <= v["score"] < 9.0]        return total, critical, high     def gate_check(self, threshold=8.0):        blocked = [v for v in self.report_list if v["score"] >= threshold]        return ("FAIL" if blocked else "PASS"), blocked  def main():    image = ContainerScanner(        [            {"name": "runtime", "pkgs": {"curl": "7.82.0"}},            {"name": "app", "pkgs": {"nginx": "1.24.0", "openssl": "1.1.1t"}},            {"name": "base", "pkgs": {"openssl": "1.1.1s", "linux-kernel": "6.1.90"}},        ]    )    image.scan()    total, critical, high = image.summary()    print("[镜像扫描报告] 漏洞总数:", total)    print("  Critical:", len(critical), " High:", len(high))    for v in image.report_list:        print("  - [%.1f] %s %s %s (in %s layer)" % (v["score"], v["cve"], v["pkg"], v["version"], v["layer"]))    status, blocked = image.gate_check()    print("[CI 门禁] 状态:", status, " 阻断高危漏洞数:", len(blocked))    if status == "FAIL":        print("  请升级依赖或更新基础镜像后重新构建!")  if __name__ == "__main__":    main()
目的：用约 60 行代码模拟了 Trivy 的核心工作流程——解析镜像各层软件包、与漏洞数据库比对、生成报告、执行 CI 门禁判定，帮助理解扫描原理。
  1. VULN_DB = [...]模拟“全球通缉名单”：每条记录含 CVE 编号、包名、受影响版本上限和风险分
  2. def parse_version(ver):把 "1.2.3" 这样的版本号拆成可比较的数字元组 (1, 2, 3)
  3. def is_affected(pkg, version):名单比对核心逻辑：包名一致且版本 ≤ 受影响上限则命中
  4. class ContainerScanner:扫描器本体，相当于安检 X 光机
  5. self.report_list = []扫描结果容器，累计所有命中的漏洞记录
  6. for layer in self.layers:逐层翻查行李箱，每一层夹层都不放过
  7. hit = is_affected(name, ver)对每个软件包执行通缉名单匹配
  8. def gate_check(self, threshold=8.0):CI 门禁决策：超过阈值返回 FAIL
  9. if __name__ == "__main__":可执行入口，模拟一次完整的构建阶段扫描

常见误区

误区“我构建的时候跑过 Trivy，报告是干净的，这个镜像之后肯定没问题。”

正解漏洞库在持续更新。上个月没上榜的组件，这个月可能就被披露新 CVE。正确的做法是定期重扫，至少每次漏洞库更新后，对生产使用的镜像重新评估一遍。好比通缉名单每天都有新名字，上个月通过安检的行李箱，这个月再过一遍可能就查出东西了。

为何常见：把扫描当成一次性验收动作，忽略了“名单会更新”这个事实。

误区“基础镜像都是官方拉的，不用扫，我自己写的那一层没漏洞就行。”

正解底层基础镜像恰恰是最容易藏漏洞的地方——系统库、glibc、OpenSSL 这些高危目标都在底层。而且历史层里的文件即使后来删了，只要镜像还在，内容就还在。扫描必须覆盖全部层，一个都不能少。

为何常见：以为“我自己写的代码才重要”，忽视了供应链上游的依赖风险。

误区“报告里有 10 个高危，我今晚加班全升级掉，不然不安全。”

正解修复有成本且可能引入新问题。正确做法是先评估可利用性和暴露程度——仅内部网络、从未被调用的组件，实际风险远低于暴露公网的服务。按优先级排序修复，对确实无法利用的申请豁免并设置复审窗口。盲修一遍可能引入不兼容，反而制造新的故障。

为何常见：把“风险评分”直接当成“修复工作量”，缺少对实际场景的分析。

误区“镜像都已经上线了，直接在服务器上装个扫描器扫一遍不就好了？”

正解扫描应该发生在构建阶段，此时发现问题的修复成本最低。生产环境里跑扫描，发现问题时镜像已经暴露了；生产环境资源有限，安装扫描器还会引入额外攻击面。运行时应该做的是隔离与监控兜底。

为何常见：只看到“扫”的动作，没理解时机决策背后的成本逻辑。

误区“我的镜像只检出 2 个低危漏洞，很安全！”

正解安全不只是 CVE。镜像里硬编码的密钥、以 root 运行、暴露高危端口、历史层残留的敏感文件，每一项都是严重风险。一个“0 漏洞”的镜像可能带着一把明晃晃的钥匙。完整的安全扫描必须覆盖漏洞、密钥、配置三类检查。

为何常见：把“漏洞数”当成安全性的唯一指标，忽视了其他攻击面。

面试题

Q1. 容器镜像安全扫描最合适的执行时机是？

单选题 · easy

  • A.生产运行阶段排查
  • B.事故发生时再扫描
  • C.构建阶段前置检查← 正确答案
  • D.项目验收阶段审计

答案：C。构建阶段发现问题，重新打包的成本最低，就像行李在托运前被拦下只需重新整理；等镜像上线再扫，相当于行李已经上飞机才处理，代价大得多。A/B/D 都属于“事后补救”。

Q2. 下列关于 CVE 编号的说法，正确的是？

单选题 · easy

  • A.标记镜像构建序号
  • B.唯一标识已知漏洞← 正确答案
  • C.记录容器运行日志
  • D.生成网络安全密钥

答案：B。CVE 是公共漏洞与暴露的编号体系，相当于漏洞的“身份证号”，全球通用。它不参与构建、不记日志、不生成密钥，A/C/D 都把它和别的概念混为一谈。

Q3. 面对一个高危漏洞，第一步应该做什么？

单选题 · mid

  • A.直接删除整个镜像
  • B.通知所有下游用户
  • C.立即停用全部服务
  • D.评估可利用与暴露面← 正确答案

答案：D。先评估“这个逃犯能不能到我家门口”，即漏洞是否可被利用、服务是否暴露。D 正确。A/C 是过激反应，可能中断业务；B 在信息不足时通知用户会造成恐慌。

Q4. 以下哪项是 Trivy 扫描器不能直接完成的工作？

单选题 · mid

  • A.扫描系统软件包版本
  • B.检测硬编码密钥信息
  • C.自动更新漏洞数据库
  • D.一键修复所有漏洞← 正确答案

答案：D。Trivy 负责“查出问题”，修复需要开发人员升级依赖、更换基础镜像后重新构建。就像安检机只负责发现违禁品，不负责帮你重新打包行李。

Q5. 镜像中的“历史层残留”指的是？

单选题 · mid

  • A.镜像构建的历史日志
  • B.容器运行时的临时缓存
  • C.底层删除的文件仍存在← 正确答案
  • D.仓库里过期的旧镜像

答案：C。Docker 镜像由多层构成，删除文件只是在新层里加一条删除记录，底层文件本身还在。这就是为什么密钥“删了”还能被扫出来，C 正确。

Q6. 下列哪些属于镜像的不安全配置？

多选题 · mid

  • A.使用瘦身基础镜像构建
  • B.开启多阶段构建缓存
  • C.以 root 用户运行容器← 正确答案
  • D.暴露高特权管理端口← 正确答案

答案：CD。以 root 运行容器一旦被攻破，攻击者直接获得宿主机 root 权限；暴露高特权端口等于把家门钥匙插在门上。瘦身镜像和多阶段构建是安全实践，不应选。

Q7. CVSS 评分体系主要评估漏洞的哪个维度？

单选题 · hard

  • A.代码行数与复杂度
  • B.镜像大小与启动速度
  • C.严重程度与可利用性← 正确答案
  • D.团队规模与交付周期

答案：C。CVSS 从攻击途径、攻击复杂度、所需权限、影响范围等维度量化漏洞的严重程度与可利用性，最终归一到 0~10 分。它不关心代码实现细节、性能或项目管理因素。

Q8. CI 流水线中镜像扫描门禁 FAIL 后，合理的处置包括？

多选题 · hard

  • A.阻断构建并通知责任人← 正确答案
  • B.跳过扫描继续发布版本
  • C.升级依赖后重新扫描← 正确答案
  • D.删除流水线日志记录

答案：AC。门禁 FAIL 意味着镜像不满足安全基线，应阻断构建并通知开发修复，修复后重扫通过再放行。跳过扫描会让门禁形同虚设，删除日志则破坏了审计追溯能力。

Q9. 关于基线镜像维护机制，下列说法正确的有？

多选题 · hard

  • A.每周随漏洞库更新重建← 正确答案
  • B.基线漏洞清零或已豁免← 正确答案
  • C.业务镜像从基线派生← 正确答案
  • D.基线镜像上线后永不更新

答案：ABC。基线镜像是团队的“标准打包方案”，必须保持干净并定期随漏洞库更新重建，业务镜像从它派生才能从源头降低风险。永不更新会导致漏洞和依赖老化，与维护机制的初衷相悖。

Q10. Grype 扫描通常与哪个工具联动来提取软件物料清单（SBOM）？

单选题 · easy

  • A.联动 Trivy 扫描依赖漏洞
  • B.联动 Nmap 探测暴露端口
  • C.联动 Git 管理镜像版本
  • D.联动 Syft 提取软件清单← 正确答案

答案：D。Grype 与 Syft 是 Anchore 生态的一对搭档，Syft 负责从镜像提取 SBOM，Grype 基于清单做漏洞比对。与 Trivy 是竞品关系，与 Nmap/Git 更是毫无关联。