5.3 CVE 修复链

机制原理

CubeSandbox 依赖许多 Rust crate、Linux 内核、seccomp filter、cloud-hypervisor,这些依赖项自身会有 CVE。项目通过:

  1. 定期 bump 依赖 —— 在 Cargo.toml 中升 vmm-sys-util、seccompiler、tokio、reqwest 等
  2. 依赖 audit 工具 —— cargo audit, npm audit, govulncheck, osv-scanner
  3. 变更日志跟踪 —— docs/changelog/v*.md 显式列出 bump 原因

证据:docs/changelog/v0.2.2.md

vmm-sys-util bumped to 0.12.1 (CVE-2023-50711, GHSA-875g-mfp6-g7f9)

为什么 CubeSandbox 这样设计

  • 不强加"升级一气呵成" —— 升级一个 systemd-style deep stack,得逐 crate bump,逐 commit 验证
  • 关注 supply chain —— CubeSandbox 处于攻击 surface 内,一旦 log4shell 类的事件再现,影响范围远超单一 service
  • changelog 把 vul link 直接给读者 —— 方便审计 / 复测

如何使用 / 配置

cargo audit (Linux Rust 依赖)

# 装 cargo-audit
cargo install cargo-audit

# 跑
cargo audit --file Cargo.lock
# 输出:
# RustSec Advisory Database ID: RUSTSEC-2024-0001
# Package:    <name>
# Version:    <ver>
# Title:      <title>
# Date:       2024-...
# URL:        https://rustsec.org/advisories/RUSTSEC-2024-0001

govulncheck (官方 Go)

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

osv-scanner (跨语言)

# osv.dev scanner(支持 npm / pypi / Go / Rust)
go install github.com/google/osv-scanner/cmd/osv-scanner@latest

# 扫整个仓
osv-scanner --recursive .

bump 流程

# 1. bump
cargo update -p vmm-sys-util --precise 0.12.1

# 2. 跑测试
cargo test --all

# 3. 验证 hypervisor 仍可启动
./scripts/run_dev.sh start

# 4. 查看 diff
git diff Cargo.toml Cargo.lock | head -30

# 5. 提交
git add Cargo.toml Cargo.lock
git commit -m "chore: bump vmm-sys-util to 0.12.1 for CVE-2023-50711"

持续集成

# .github/workflows/audit.yml
name: Security Audit
on:
  schedule:
    - cron: '0 6 * * *'    # 每天 06:00 UTC
  pull_request:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
      - '**/package.json'
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: cargo install cargo-audit
      - run: cargo audit --deny warnings

跟踪 CVE feed

# rustsec
cargo audit --json

# osv.dev
osv-scanner --json -r . > osv-result.json

响应流程

1. 监控告警:每天 cron 跑 cargo audit,扫描结果发到 #sec-alerts Slack
2. triage:维护者按 severity / exploit availability 分档处理
3. patch:gather fix PR,review,在 staging 验证
4. roll out:窗口期 24h 内滚动到所有 host
5. post-mortem:CVE 复盘 + 改进 audit / 升级策略

注意:

  • 不是所有 CVE 都关键 —— 一个 crate 的 dependency tree 漏洞,但实际 unpack 时不打中,可能是 noise;用 govulncheck 走 call-graph 分析
  • 升级 kernel 内核不一定能 bump 所有依赖,务必对 guest kernel 与 host kernel 一起升级测试
  • 监控仓库 Cargo.lock diff 的体积:差异过大(> 100 行)可能是上游 release 整包;不要 batch-upgrade,逐版本 bump 才好 review
  • 慎用 floating versions(vmm-sys-util = "*"),会让 cargo 跟着 semver-bump 突然升级,在生产 manifest 必须 pin 到 minor
  • 关注 GHSA(advisory database),不只 CVE,一些 Rust crate 只有 GHSA 而无 CVE
  • 实验时多跑一晚流量再合:cargo audit --deny warnings 在 CI 通过,但运行时 panic 仍可能

总结:风险处理原则

  • 不是 patch 进了依赖就算修完 —— 必须 host 上对应 binary 也更新
  • fix chain 的 fail-safe:升级失败回退;changelog 显式声明 “Tested on 5 deployments”
  • 升级 chain 要可视化:/config 端点暴露当前所有依赖版本,运维一眼能看出
  • 教学角度:从 v0.2.2 bump vmm-sys-util 这种"小补丁 + 大 explain",可以看出 CubeSandbox 安全维护思路——看得见的 patch,而不是悄悄升级。