1. 为什么 Docker Scout 不是“又一个扫描工具”而是你构建流程里本该存在的那块拼图我第一次在客户现场看到 Docker Scout 的实际效果是在一个金融行业客户的 CI 流水线里。他们之前用的是 Trivy 自研脚本组合每次镜像构建后要等 3 分半钟出报告而且经常因为路径权限、依赖版本冲突、SBOM 格式不兼容等问题卡在流水线中间。那天我帮他们把docker scout cves命令加进 build 阶段执行完只用了 18 秒——不是优化后的 18 秒就是原生命令跑出来的耗时。更关键的是报告里直接标出了哪一行 Dockerfile 引入了带高危漏洞的 base image连修复建议都带着可复制的 tagpython: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 listAlpine、dpkg -lDebian/Ubuntu、rpm -qaRHEL/CentOS的原始输出以及 Python 的pip list --freeze、Node.js 的npm list --all --depth0、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 requestsScout 不仅知道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 不是“清单”而是可审计、可追溯的供应链凭证很多人把 SBOMSoftware Bill of Materials当成一个合规应付的产物导出个 JSON 就完事。Scout 生成的 SBOM 则是设计用来“被机器消费”的。以 SPDX 格式为例它不仅列出package-name: version还强制包含PackageDownloadLocation: 包的下载源如https://alpinelinux.org/packages/openssl-3.0.13-r0.apkPackageChecksum: 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 虽然宣称“内置”但实际落地时环境兼容性是第一个拦路虎。别跳过这三步确认 Docker Desktop 版本打开 Docker Desktop → Settings → About查看版本号。必须 ≥ 4.17.0。低于此版本请立即前往 Docker 官网 下载最新版。旧版 Docker Engine如通过apt install docker-ce安装的即使版本号很高也可能不包含 Scout 插件这是 Docker Desktop 和 Docker Engine 的分发差异导致的无法绕过。验证 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。登录 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 founddocker 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 会向 Docker Hub API 请求该镜像的 manifest解析 manifest 中的 layer digest 列表对每个 layer请求其configblob包含history和rootfs信息从config中提取apk list/dpkg -l等命令的模拟输出用本地缓存的漏洞数据库进行匹配。整个过程不下载任何 layer blob耗时通常在 3-8 秒。你可以把它集成到docker pull前的钩子中#!/bin/bash IMAGEredis: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 21 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 输出是纯文本可直接grepdocker 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: alpineSource: 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 的报告会给出线索你需要据此决策你看到的线索推荐行动理由与实操要点Source: alpine且Fixed in版本号与当前 base image 的发行版强相关如alpine:3.18的openssl修复在3.0.14-r1而alpine:3.19已预装3.0.14-r2升级 base image这是最安全、最省心的方式。修改 DockerfileFROM python:3.14-slim→FROM python:3.14-slim-bookworm。bookworm是 Debian 12 的代号比bullseyeDebian 11更新漏洞更少。Scout 的docker scout recommend base-image命令会直接给出最优推荐。Source: pypi且Affected Package是你requirements.txt里的直接依赖如django4.2.0升级该依赖执行pip install django4.2.1假设 4.2.1 修复了 CVE然后pip freeze requirements.txt。务必在测试环境验证功能因为 Django 小版本升级可能有行为变更。Source: pypi但Affected Package是间接依赖如django依赖的sqlparse升级直接依赖或使用pip-compile锁定不要手动pip install sqlparse这可能导致依赖冲突。用pip-compile requirements.in生成requirements.txt它会自动选择满足所有依赖约束的最新安全版本。Source: githubGo 模块且Fixed in版本是 major 版本如v2.0.0谨慎评估优先找 patch 版本Go 的 major 版本升级通常不兼容。先查 go list -m -u all实操心得我见过太多团队因为盲目升级 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.ymlname: 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/checkoutv4 - name: Set up Docker Buildx uses: docker/setup-buildx-actionv3 - name: Login to Docker Hub uses: docker/login-actionv3 with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} - name: Build image uses: docker/build-push-actionv5 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-artifactv4 with: name: scout-html-report path: scout-report.html retention-days: 7这个模板的关键设计点push: falseload: 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 0Base 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 集成中最常踩的五个“静默陷阱”陷阱Docker-in-DockerDinD环境下 Scout 插件未加载GitHub Actions 默认 runner 不是 Docker DesktopScout 插件需手动安装。在steps中加入- name: Install Docker Scout plugin run: | docker plugin install docker/scout-cli --grant-all-permissions --skip-verify陷阱并发构建时镜像 tag 冲突多个 PR 同时触发 CI都用my-app:ci-${{ github.sha }}可能导致docker scout cves扫描到错误的镜像。解决方案用--iidfile记录构建 IDdocker buildx build --iidfile iid.txt . IMAGE_ID$(cat iid.txt) docker scout cves $IMAGE_ID陷阱扫描超时导致 CI 卡死默认超时是 300 秒。对于超大镜像如含 CUDA 的 AI 镜像可延长docker scout cves my-app:large --timeout 600陷阱JSON 解析失败因 Scout 输出含 ANSI 颜色码在 CI 中Scout 会输出彩色文本jq无法解析。加--no-color参数docker scout cves my-app:latest --format json --no-color report.json陷阱未处理 Scout 的 rate limit免费账户有每日扫描限额。在 CI 中用--quiet减少日志避免触发限流docker scout cves my-app:latest --quiet --only-severity critical,high6. Scout 的边界在哪里它不做什么以及你还需要哪些搭档再强大的工具也有它的疆界。Docker Scout 的设计哲学是“专注构建时的静态镜像分析”这意味着它刻意回避了一些领域。清醒认识它的边界不是贬低它而是为了更聪明地组合工具构建完整的安全防护网。6.1 Scout 明确不覆盖的三大领域及对应的专业搭档领域一运行时安全监控Runtime SecurityScout 扫描的是构建完成的镜像它无法知道容器启动后会发生什么。一个没有 CVE 的镜像可能在运行时被注入恶意进程、遭遇提权攻击、或被利用配置错误如--privileged横向移动。搭档工具FalcoFalco 是 CNCF 毕业项目专为 Kubernetes 和容器运行时设计。它通过 eBPF 技术监听系统调用能实时检测“非预期的进程执行”如curl在生产容器里突然发起外网请求、“敏感文件访问”如/etc/shadow被读取、“异常网络连接”。Scout 告诉你“镜像出厂时是干净的”Falco 告诉你“它在生产里是否一直保持干净”。领域二源代码安全SASTScout 不看你的.py或.js文件。它无法发现硬编码的密码、SQL 注入漏洞、XSS 漏洞——这些都藏在源码逻辑里而非打包进镜像的二进制中。搭档工具SemgrepSemgrep 是一款极速、可编程的 SAST 工具。它用类似正则的语法YAML 规则扫描代码规则库开源且丰富。例如一条规则能瞬间找出所有os.system(input)的调用这正是典型的命令注入风险点。Scout 确保你的“车”没缺陷Semgrep 确保你的“司机”代码没犯错。领域三动态应用安全测试DASTScout 不会启动你的应用并模拟黑客攻击。它不知道你的 API 是否存在未授权访问、业务逻辑是否可被绕过、前端是否泄露敏感信息。搭档工具ZAPZed Attack ProxyZAP 是 OWASP 的旗舰 D
