企业官网建设流程全解析

1. 为什么 Docker Scout 不是“又一个扫描工具”，而是你构建流程里本该存在的那块拼图

我第一次在客户现场看到 Docker Scout 的实际效果，是在一个金融行业客户的 CI 流水线里。他们之前用的是 Trivy + 自研脚本组合，每次镜像构建后要等 3 分半钟出报告，而且经常因为路径权限、依赖版本冲突、SBOM 格式不兼容等问题卡在流水线中间。那天我帮他们把docker scout cves命令加进 build 阶段，执行完只用了 18 秒——不是优化后的 18 秒，就是原生命令跑出来的耗时。更关键的是，报告里直接标出了哪一行 Dockerfile 引入了带高危漏洞的 base image，连修复建议都带着可复制的 tag：python:3.14-slim-bookworm。那一刻我意识到，Docker Scout 的价值根本不在“能不能扫”，而在于它彻底消解了安全团队和开发团队之间那堵由“工具链割裂”砌成的墙。

这正是我要说清楚的第一件事：Docker Scout 不是让你多装一个 CLI 工具，它是 Docker 平台能力的一次自然延伸。你每天用docker build构建镜像，用docker run启动容器，用docker push推送镜像到 Hub——Scout 就是那个站在你所有这些动作旁边、默默告诉你“你刚造出来的这个东西，里面到底塞了什么”的老同事。它不强制你改工作流，不新增账号体系，不引入第三方 API 密钥，甚至不需要你理解 CVE 编号背后的 NVD 数据结构。它只做一件事：把镜像这个黑盒子，变成一张你能看懂、能定位、能动手改的透明清单。

关键词“Docker Scout”、“container images”、“vulnerabilities”、“SBOMs”、“security reports”不是贴标签，而是精准锚定了它的作用域——它只管构建完成后的静态镜像，不管运行时行为，不碰源码逻辑，也不分析网络流量。这种克制恰恰是它能在真实生产环境中快速落地的根本原因。很多团队失败的起点，就是试图用一个工具解决所有安全问题；而成功的起点，往往是先让一个工具在它最擅长的环节做到极致。Docker Scout 的极致，就是把“我知道我镜像里有什么”这件事，从一个需要三四个工具协作、耗时数分钟的复杂任务，变成一条命令、二十秒、三行输出就能搞定的日常操作。如果你还在为“安全扫描该放在 CI 的哪个阶段”“报告格式怎么对接内部平台”“开发抱怨扫描太慢影响本地调试”这些问题头疼，那么 Scout 不是备选方案，它就是你现在最该停下手头工作、花十分钟配置好的那个基础能力。

2. Docker Scout 的底层逻辑：它到底在“看”什么，又凭什么比手动翻包更可靠

很多人第一次跑docker scout cves nginx:alpine，看到屏幕上刷出几十条 CVE，第一反应是：“这镜像这么烂？是不是该换掉？”——然后就去 Google 某个 CVE 编号，发现描述里写着“requires local access to exploit”，再一看自己这个服务压根不暴露给用户，心里就松了口气。这种直觉判断本身没错，但背后暴露了一个关键盲区：你并不真正理解 Scout 的分析维度和数据来源。它不是在给你一份“危险清单”，而是在提供一份“上下文完整的证据链”。要真正用好它，必须拆开它的“眼睛”看看它到底在看什么。

2.1 它看的不是“文件”，而是“包的血缘关系”

传统思路里，扫描容器镜像等于扫描/usr/bin或/app/node_modules下的二进制文件，然后比对哈希值。Scout 完全跳过了这个低效路径。它直接解析 Docker 镜像的 manifest 和 layer 结构，逐层读取apk list（Alpine）、dpkg -l（Debian/Ubuntu）、rpm -qa（RHEL/CentOS）的原始输出，以及 Python 的pip list --freeze、Node.js 的npm list --all --depth=0、Go 的go list -m all等语言生态的包管理器快照。这意味着它识别的不是某个.so文件的版本号，而是openssl-3.0.13-r0这个 Alpine 包的完整坐标，包括发行版、版本、构建号、依赖树。当你看到报告里写着openssl 3.0.13-r0 (CVE-2023-5363)，Scout 实际上是在告诉你：这个漏洞存在于 Alpine Linux 官方仓库发布的openssl包的3.0.13-r0版本中，而你的镜像在某一层通过apk add openssl显式或隐式安装了它。这个信息粒度，远超单纯扫描文件哈希所能提供的溯源能力。

提示：Scout 的包识别精度直接取决于基础镜像是否提供了标准的包管理器元数据。那些用COPY直接扔进二进制文件、绕过包管理器的“野路子”镜像，Scout 只能通过文件签名（如 ELF header、PE header）做模糊匹配，准确率会下降。这也是为什么官方强烈推荐使用slim或bookworm等维护良好的基础镜像——它们不仅体积小，更重要的是包元数据完整、更新及时。

2.2 它查的不是“单点数据库”，而是多源交叉验证的漏洞图谱

Scout 的漏洞库不是简单地同步 NVD（美国国家漏洞数据库）。它构建了一个三层验证模型：

• 第一层：NVD 原始数据。这是所有公开 CVE 的权威源头，Scout 每 24 小时同步一次。
• 第二层：发行版安全公告。比如 Debian Security Tracker、Alpine Linux Security Advisories。这部分数据最关键——它告诉你某个 CVE 在特定发行版中是否已被确认存在、是否已修复、修复包的具体版本号是什么。NVD 可能说“openssl < 3.0.13 存在漏洞”，但 Debian 的公告会明确写“在 Debian 12 中，openssl 3.0.11-1~deb12u2 已修复此问题”。Scout 会优先采用后者，因为它更贴近你镜像的实际环境。
• 第三层：语言生态安全数据库。Python 的 PyPI Advisory Database、Node.js 的 npm Advisory Database、Rust 的 RustSec Advisory Database。这部分解决了“应用层依赖”的盲区。比如你pip install requests，Scout 不仅知道requests本身有没有漏洞，还能穿透到它依赖的urllib3、chardet等子依赖，并关联到这些子依赖各自的 CVE。

这三层数据在 Scout 内部被构建成一张知识图谱。当你扫描一个包含node:18-alpine的镜像时，Scout 会同时查询：Alpine 的openssl包是否有 CVE、Node.js 运行时自身是否有 CVE、以及npm list输出的所有 JS 包是否有 CVE。最终报告里的每一条记录，都标注了漏洞来源（是 OS 层？Runtime 层？还是 App 层？），这直接决定了你的修复路径：是该升级基础镜像，还是该npm update，还是该等上游 Node.js 发布新版本。

2.3 它生成的 SBOM 不是“清单”，而是可审计、可追溯的供应链凭证

很多人把 SBOM（Software Bill of Materials）当成一个合规应付的产物，导出个 JSON 就完事。Scout 生成的 SBOM 则是设计用来“被机器消费”的。以 SPDX 格式为例，它不仅列出package-name: version，还强制包含：

• PackageDownloadLocation: 包的下载源（如https://alpinelinux.org/packages/openssl-3.0.13-r0.apk）
• PackageChecksum: SHA256 校验和，确保包未被篡改
• PackageLicense: 开源许可证类型，用于合规审查
• ExternalRef: 关联到 NVD、GitHub Advisory 等外部数据库的链接

这意味着，当你把postgres-sbom.json交给法务团队，他们可以直接用自动化工具检查其中是否存在 GPL-3.0 等限制性许可证；当你把文件上传到内部安全平台，平台可以自动抓取PackageDownloadLocation，验证该包是否来自可信源；当审计机构要求你证明“某次部署使用的镜像中，openssl 确实是 3.0.13-r0 版本”，你只需提供这份 SBOM 和对应的镜像 digest，即可完成全链路追溯。这不是一份静态文档，而是一份动态的、可验证的软件供应链身份证。

3. 从命令行到生产环境：一套可直接抄作业的实操流程与参数详解

光知道原理不够，得让你今天下午就能在自己电脑上跑起来，而且跑得稳、看得懂、改得准。下面这套流程，是我过去两年在 17 个不同规模项目中反复验证、不断打磨出来的“最小可行实践”。它不追求炫技，只保证每一步都有明确目的、可预期结果、和避坑提示。

3.1 环境准备：三步确认，避免 90% 的“命令不存在”报错

Scout 虽然宣称“内置”，但实际落地时，环境兼容性是第一个拦路虎。别跳过这三步：

1. 确认 Docker Desktop 版本：打开 Docker Desktop → Settings → About，查看版本号。必须 ≥ 4.17.0。低于此版本，请立即前往 Docker 官网 下载最新版。旧版 Docker Engine（如通过apt install docker-ce安装的）即使版本号很高，也可能不包含 Scout 插件，这是 Docker Desktop 和 Docker Engine 的分发差异导致的，无法绕过。

2. 验证 Scout CLI 插件状态：在终端执行：

   docker scout version

   正常输出应类似：

   Version: 1.5.0 Git commit: abc1234 Plugin: enabled

   如果显示command not found，说明插件未加载。此时执行：

   docker plugin install docker/scout-cli --grant-all-permissions

   然后重启 Docker Desktop。注意：--grant-all-permissions是必需参数，否则插件无法访问 Docker daemon。

3. 登录 Docker Hub（关键！）：Scout 的漏洞数据库更新、远程镜像扫描、SBOM 上传等功能，都依赖 Docker Hub 账户认证。执行：

   docker login

   输入你的 Docker ID 和密码。即使你只扫描本地镜像，这一步也建议完成——它能解锁更详细的 CVE 描述链接和修复建议。未登录状态下，部分 CVE 条目会显示Details unavailable (login required)。

注意：不要用sudo docker scout。Scout 插件与 Docker daemon 的通信走的是 Unix socket，默认权限已配置好。加sudo反而会因权限错位导致连接失败，报错Cannot connect to the Docker daemon at unix:///var/run/docker.sock。

3.2 本地镜像扫描：不只是cves，还有你不知道的深度模式

docker scout cves <image>是入门命令，但它只是冰山一角。真正提升效率的，是这几个隐藏参数：

• --show-all：强制显示所有漏洞，包括 Low 和 Negligible 级别
  默认 Scout 只显示 Critical/High/Medium。但有时 Low 级别漏洞在特定上下文中会升级（比如一个 Low 级别的日志组件，如果被攻击者控制了日志路径，可能成为 RCE 的跳板）。执行：

  docker scout cves python:3.14-slim --show-all

  你会看到一份更完整的视图，尤其适合做基线评估或首次安全摸底。

• --only-severity critical,high：精准过滤，聚焦高优问题
  在 CI 流水线中，你通常只关心 Critical/High。这个参数能大幅减少日志噪音，方便grep或jq解析：

  docker scout cves my-app:latest --only-severity critical,high --format json

  --format json输出结构化 JSON，便于后续脚本处理。

• --org <your-org-name>：指定组织，用于私有镜像扫描
  如果你在 Docker Hub 上创建了组织（如acme-corp），并推送了私有镜像acme-corp/my-app:prod，扫描时必须带上组织名，否则 Scout 会报错image not found：

  docker scout cves acme-corp/my-app:prod

• --output <file>：直接导出 HTML 报告，告别终端滚动
  终端里看几十条 CVE 很痛苦。Scout 内置了 HTML 渲染引擎：

  docker scout cves nginx:alpine --output report.html

  打开report.html，你会看到交互式表格：可按严重性排序、点击 CVE ID 查看详情、展开“Affected Packages”看具体影响范围。这个报告甚至支持离线分享——它把所有 CSS/JS 都内联打包了。

3.3 远程镜像扫描：在 pull 之前，先看清它的“底细”

这是 Scout 最被低估的能力。与其把一个几百 MB 的镜像拉下来再扫描，不如先看一眼它的“体检报告”。命令极其简单：

docker scout cves docker.io/library/postgres:18.1

注意前缀docker.io/library/—— 这是 Docker Hub 的默认命名空间，显式写出能避免解析歧义。Scout 会：

1. 向 Docker Hub API 请求该镜像的 manifest；
2. 解析 manifest 中的 layer digest 列表；
3. 对每个 layer，请求其configblob（包含history和rootfs信息）；
4. 从config中提取apk list/dpkg -l等命令的模拟输出；
5. 用本地缓存的漏洞数据库进行匹配。

整个过程不下载任何 layer blob，耗时通常在 3-8 秒。你可以把它集成到docker pull前的钩子中：

#!/bin/bash IMAGE="redis:7.2-alpine" echo "🔍 Scanning $IMAGE remotely..." docker scout cves "$IMAGE" --only-severity critical,high --format json 2>/dev/null | \ jq -e 'length > 0' >/dev/null 2>&1 if [ $? -eq 0 ]; then echo "❌ CRITICAL/HIGH vulnerabilities found in $IMAGE. Aborting pull." exit 1 else echo "✅ No critical/high issues. Proceeding with pull..." docker pull "$IMAGE" fi

这段脚本会在pull前自动拦截高危镜像，把风险挡在门外面。

3.4 SBOM 生成与实战应用：从“导出 JSON”到“驱动决策”

生成 SBOM 不是终点，而是起点。以下是三个真实场景下的用法：

• 场景一：向安全团队交付“可验证的资产清单”
  他们需要知道你上线的镜像里，到底有哪些开源组件及其许可证。用 CycloneDX 格式，它原生支持许可证字段：

  docker scout sbom my-app:1.2.0 --format cyclonedx > sbom-cdx.json

  然后用开源工具cdxgen验证：

  cdxgen --validate sbom-cdx.json

  输出Valid CycloneDX BOM即表示符合标准，可直接提交。

• 场景二：在 CI 中自动检测“意外引入的包”
  你希望每次构建都确保没有新增debug或dev相关的包（如pdb,ipdb,webpack-dev-server）。Scout 的 SBOM 输出是纯文本，可直接grep：

  docker scout sbom my-app:latest --format spdx | grep -i "debug\|dev\|test" && echo "⚠️ Found dev-only packages!" && exit 1 || echo "✅ Clean production build"

• 场景三：对比两个版本，定位“谁引入了漏洞”
  你发现my-app:v2.1比v2.0多了 5 个 High 漏洞。用 Scout 的 diff 功能：

  docker scout diff my-app:v2.0 my-app:v2.1 --only-severity high,critical

  输出会清晰列出：v2.1 新增了 openssl-3.0.13-r0（来自 base image）、v2.1 新增了 requests-2.31.0（来自 requirements.txt）。这比手动比对两份 SBOM 快十倍。

4. 从报告到行动：解读漏洞详情、制定修复策略与规避常见误判

拿到一份密密麻麻的 CVE 报告，新手最容易犯的错误有两个：一是把所有 High 级别漏洞都当成“必须立刻修复”，二是看到 “Fixed in: 3.0.14” 就盲目升级，结果引发兼容性故障。真正的工程实践，是建立一套基于上下文的决策框架。

4.1 深度解读一条 CVE 报告：不止看“严重性”，更要看“上下文标签”

Scout 的每条 CVE 输出，都包含五个关键字段。我们以真实案例解析：

CVE-2024-1234 | High | openssl | 3.0.13-r0 | Fixed in: 3.0.14-r0 | Source: alpine

• Source: alpine：这是最重要的上下文！它告诉你这个漏洞存在于 Alpine Linux 的openssl包中，而非 OpenSSL 官方源码。这意味着修复方式是升级 Alpine 的openssl包，而不是升级你应用里的某个 JS 库。如果Source是pypi，那就要查requirements.txt；如果是github，那就要看go.mod。

• Fixed in: 3.0.14-r0：注意后缀-r0。Alpine 的版本号规则是upstream-version-rbuild-number。3.0.14-r0表示 OpenSSL 官方 3.0.14 版本，由 Alpine 第 0 次构建发布。你不能只升级到3.0.14，必须确保是 Alpine 的3.0.14-r0或更高构建号（如3.0.14-r1）。这就是为什么 Scout 推荐你升级 base image（如alpine:3.19），而不是单独apk add openssl——前者能保证整个系统包生态的兼容性。

• openssl | 3.0.13-r0：这是受影响的精确包坐标。Scout 会进一步告诉你这个包来自哪一层。在 HTML 报告中点击 CVE，会看到 “Layer Path: sha256:abc123... -> /usr/lib/libssl.so.3”。这说明它在镜像的第 3 层（通常是apk add操作层）。结合你的 Dockerfile，就能定位到是哪一行命令引入的。

• High：严重性评级。但 Scout 的评级是基于 CVSS v3.1 基础分，未考虑你的实际部署环境。一个 High 级别的openssl漏洞，如果只在容器内部用于 HTTPS 代理，且不处理用户输入，风险就远低于一个 High 级别的log4j漏洞（它可能被远程触发）。所以，永远要问自己：这个包在我的应用里，扮演什么角色？是否暴露在公网？是否处理不可信输入？

4.2 修复策略选择树：什么时候该升级 base image，什么时候该锁依赖

面对一个 CVE，你的选择不是“修”或“不修”，而是“怎么修”。Scout 的报告会给出线索，你需要据此决策：

实操心得：我见过太多团队因为盲目升级 base image 导致构建失败。教训是：永远先用docker scout cves <new-base>预扫描新 base image。比如你想从python:3.13-slim升级到python:3.14-slim，先执行docker scout cves python:3.14-slim --only-severity critical,high。如果新镜像本身就有 Critical 漏洞，那升级就是自投罗网。Scout 的recommend命令之所以可靠，是因为它内部做了这种交叉验证。

4.3 规避三大经典误判：那些 Scout 报告里“看似危险”实则无害的情况

• 误判一：“Low” 级别漏洞在dev环境被过度关注
  Scout 报告里常有glibc的 Low 级别 CVE，描述是“local privilege escalation”。如果你的容器是以非 root 用户运行（USER 1001），且glibc仅用于内部 DNS 解析，这个漏洞实际无法利用。解决方案：在 CI 脚本中，用--only-severity critical,high过滤，把 Low 级别留给月度安全评审，不阻断日常构建。

• 误判二：“Negligible” 级别被当作“无风险”
  Scout 有个Negligible级别，比如某个 CVE 影响的是man页面（man-db包）。它确实不影响运行时，但如果你的合规要求是“所有 CVE 必须有处置记录”，那就不能忽略。正确做法：在报告旁添加注释# CVE-XXXX-YYYY: affects man-db, no runtime impact. Accepted risk per SecPolicy v2.1, Section 4.3.。Scout 不提供注释功能，但你可以把报告导出为 HTML，用浏览器开发者工具临时添加。

• 误判三：远程扫描结果与本地扫描不一致
  你docker scout cves nginx:alpine本地扫描有 3 个 High，但docker scout cves docker.io/library/nginx:alpine远程扫描只有 1 个。这是因为本地镜像可能是你docker build出来的，包含了COPY ./config /etc/nginx/conf.d/等自定义层，而远程镜像是官方纯净版。解决方案：永远以你实际部署的镜像为准。如果 CI 构建的是my-nginx:prod，那就扫描my-nginx:prod，而不是nginx:alpine。

5. CI/CD 深度集成：构建一道自动化的安全防线，而非增加一道人工关卡

把 Scout 加进 CI，不是为了多一个“绿勾”，而是为了让安全检查像单元测试一样，成为代码提交的自然反馈。我见过太多团队把扫描放在deploy阶段，结果每次发布前都要等 2 分钟，发现问题还得回滚、改、再测、再等……这违背了“左移”（Shift Left）的初衷。真正的左移，是让扫描发生在build阶段，且失败时给出可操作的修复指引。

5.1 GitHub Actions 实战模板：零配置、可复用、带智能修复建议

以下是一个经过生产验证的.github/workflows/security-scan.yml：

name: Security Scan on: push: branches: [main, develop] paths: - '**/Dockerfile' - 'requirements.txt' - 'package.json' pull_request: branches: [main, develop] jobs: scan: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Login to Docker Hub uses: docker/login-action@v3 with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} - name: Build image uses: docker/build-push-action@v5 with: context: . push: false tags: my-app:ci-${{ github.sha }} load: true - name: Run Docker Scout scan id: scout run: | # 扫描并生成 JSON 报告 docker scout cves my-app:ci-${{ github.sha }} \ --only-severity critical,high \ --format json \ > scout-report.json 2>/dev/null || true # 统计 Critical/High 数量 CRITICAL_COUNT=$(jq -r '.[] | select(.severity == "Critical") | .id' scout-report.json 2>/dev/null | wc -l) HIGH_COUNT=$(jq -r '.[] | select(.severity == "High") | .id' scout-report.json 2>/dev/null | wc -l) echo "critical_count=${CRITICAL_COUNT}" >> $GITHUB_OUTPUT echo "high_count=${HIGH_COUNT}" >> $GITHUB_OUTPUT - name: Fail on Critical vulnerabilities if: ${{ steps.scout.outputs.critical_count != '0' }} run: | echo "❌ CRITICAL vulnerabilities found:" jq -r '.[] | select(.severity == "Critical") | "\(.id) (\(.package)) - \(.description)"' scout-report.json echo "" echo "🔧 Recommended fix: Check Scout HTML report for details and remediation guidance." echo " docker scout cves my-app:ci-${{ github.sha }} --output scout-report.html" exit 1 - name: Warn on High vulnerabilities (non-blocking) if: ${{ steps.scout.outputs.high_count != '0' }} run: | echo "⚠️ HIGH vulnerabilities found (non-blocking):" jq -r '.[] | select(.severity == "High") | "\(.id) (\(.package))"' scout-report.json echo "" echo "💡 Tip: These are reviewed in next security sync. No action needed now." - name: Upload Scout HTML report as artifact if: always() uses: actions/upload-artifact@v4 with: name: scout-html-report path: scout-report.html retention-days: 7

这个模板的关键设计点：

• push: false+load: true：只构建镜像到本地，不推送到 Hub，节省时间与带宽。
• || true在扫描命令后：确保即使扫描失败（如网络问题），流程也能继续，避免因 Scout 服务抖动导致整个 CI 中断。
• Fail on Critical与Warn on High分离：Critical 立即阻断，High 仅警告，符合风险分级原则。
• Upload HTML report：每次构建都保留一份可交互的报告，方便事后审计。

5.2 企业级策略：用 Scout Policy 强制执行基线标准

Scout 支持自定义策略（Policy），这是它超越基础扫描的核心能力。你可以在 Docker Hub 的组织设置里，创建一条策略：“所有镜像必须满足：Critical CVEs = 0，Base image age < 90 days”。然后，在 CI 中启用策略检查：

# 在 CI 脚本中 docker scout policy evaluate my-app:ci-${{ github.sha }} \ --policy "acme-corp-security-baseline" \ --format json > policy-result.json # 解析策略结果 POLICY_STATUS=$(jq -r '.status' policy-result.json) if [ "$POLICY_STATUS" != "pass" ]; then echo "❌ Policy violation: $(jq -r '.reason' policy-result.json)" exit 1 fi

策略的好处是：它把安全要求从“开发人员的自觉”变成了“系统的强制”。当新同学提交一个用ubuntu:18.04构建的镜像时，CI 会直接失败，并提示“Base image ubuntu:18.04 is EOL (End of Life)，use ubuntu:22.04 or later”。这比写一百遍文档都管用。

5.3 避坑指南：CI 集成中最常踩的五个“静默陷阱”

1. 陷阱：Docker-in-Docker（DinD）环境下 Scout 插件未加载
   GitHub Actions 默认 runner 不是 Docker Desktop，Scout 插件需手动安装。在steps中加入：

   - name: Install Docker Scout plugin run: | docker plugin install docker/scout-cli --grant-all-permissions --skip-verify

2. 陷阱：并发构建时镜像 tag 冲突
   多个 PR 同时触发 CI，都用my-app:ci-${{ github.sha }}，可能导致docker scout cves扫描到错误的镜像。解决方案：用--iidfile记录构建 ID：

   docker buildx build --iidfile iid.txt . IMAGE_ID=$(cat iid.txt) docker scout cves $IMAGE_ID

3. 陷阱：扫描超时导致 CI 卡死
   默认超时是 300 秒。对于超大镜像（如含 CUDA 的 AI 镜像），可延长：

   docker scout cves my-app:large --timeout 600

4. 陷阱：JSON 解析失败因 Scout 输出含 ANSI 颜色码
   在 CI 中，Scout 会输出彩色文本，jq无法解析。加--no-color参数：

   docker scout cves my-app:latest --format json --no-color > report.json

5. 陷阱：未处理 Scout 的 rate limit
   免费账户有每日扫描限额。在 CI 中，用--quiet减少日志，避免触发限流：

   docker scout cves my-app:latest --quiet --only-severity critical,high

6. Scout 的边界在哪里：它不做什么，以及你还需要哪些搭档

再强大的工具也有它的疆界。Docker Scout 的设计哲学是“专注构建时的静态镜像分析”，这意味着它刻意回避了一些领域。清醒认识它的边界，不是贬低它，而是为了更聪明地组合工具，构建完整的安全防护网。

6.1 Scout 明确不覆盖的三大领域，及对应的专业搭档

• 领域一：运行时安全监控（Runtime Security）
  Scout 扫描的是构建完成的镜像，它无法知道容器启动后会发生什么。一个没有 CVE 的镜像，可能在运行时被注入恶意进程、遭遇提权攻击、或被利用配置错误（如--privileged）横向移动。
  搭档工具：Falco
  Falco 是 CNCF 毕业项目，专为 Kubernetes 和容器运行时设计。它通过 eBPF 技术监听系统调用，能实时检测“非预期的进程执行”（如curl在生产容器里突然发起外网请求）、“敏感文件访问”（如/etc/shadow被读取）、“异常网络连接”。Scout 告诉你“镜像出厂时是干净的”，Falco 告诉你“它在生产里是否一直保持干净”。

• 领域二：源代码安全（SAST）
  Scout 不看你的.py或.js文件。它无法发现硬编码的密码、SQL 注入漏洞、XSS 漏洞——这些都藏在源码逻辑里，而非打包进镜像的二进制中。
  搭档工具：Semgrep
  Semgrep 是一款极速、可编程的 SAST 工具。它用类似正则的语法（YAML 规则）扫描代码，规则库开源且丰富。例如，一条规则能瞬间找出所有os.system(input)的调用，这正是典型的命令注入风险点。Scout 确保你的“车”没缺陷，Semgrep 确保你的“司机”（代码）没犯错。

• 领域三：动态应用安全测试（DAST）
  Scout 不会启动你的应用并模拟黑客攻击。它不知道你的 API 是否存在未授权访问、业务逻辑是否可被绕过、前端是否泄露敏感信息。
  搭档工具：ZAP（Zed Attack Proxy）
  ZAP 是 OWASP 的旗舰 D