测验：镜像漏洞

Dockerfile 中作为curl | tar xz安装的二进制文件不会出现在扫描结果或 SBOM 中的任何位置。为什么？

• 因为静态链接的二进制文件没有漏洞。
• 扫描器读取包管理器元数据以创建列表，但以这种方式输入的文件不会在任何数据库中注册。
• 这是因为用tar解压后的文件不会保存在图层中。
• 这是因为扫描仪运行了图像并确定它未被使用。

原本为 Total: 1247 的扫描结果在使用 --ignore-unfixed --severity CRITICAL,HIGH 后变成了 Total: 4。应如何正确理解？

• 一切都没有变得更安全，只剩下现在能做的事情了。
• 您的图像实际上更安全
• 由于过滤器设置不正确而导致结果丢失
• 其余 1,243 例为误报。

将基础更改为 distroless/nodejs22（19 个包）而不是 node:22（432 个包）的操作的最准确性质是什么？

• 通过减少图像合成本身来消除攻击面，消除1247的方式不是打补丁而是基础替换。
• 报告的漏洞已被一一修复。
• 他们通过看不到扫描仪来逃避检测。
• 这是针对运行时性能的优化，与安全性无关。

最现实的 CI 漏洞门控策略是什么？

• 即使有一个 Critical，它也会无条件失败。
• 只记录结果，不要失败
• 通过一切失败来统一标准，甚至是低/中。
• 仅在存在修订的“严重”/“高”情况下失败，并将到期日期附加到例外情况。

所有三种情况的 CVSS 评级为：CVE-2021-44228 (epss 0.9444)、CVE-2023-45853 (epss 0.00412) 和 CVE-2024-5535 (epss 0.00196) 均为“严重”。这意味着什么？

• EPSS 不可靠，所以你应该只看 CVSS
• 所有关键等级必须同时处理。
• EPSS 低不是漏洞
• 仅凭 CVSS 评级无法确定优先级；还必须考虑可利用性、暴露性和可达性。

什么最能描述 SBOM 的实用价值？

• 通过提前了解依赖关系来减少构建时间
• 通过查找并删除不必要的包来减小图像大小。
• 自动修补发现的漏洞
• 在发现新漏洞的当天，我们可以在 5 分钟内回答 40 个服务中的哪一个包含该软件包的哪个版本。