Kube-OVN 是如何自动修复 CVE 的
2025-06-28 00:02:21

这篇博客是内部分享的一个提示文稿,并没有做仔细整理,大体思路就是捕获所有 Kube-OVN 的依赖:操作系统,Golang,程序依赖,环境组件(k8s,kubevirt 等),然后激进的实时更新所有依赖做到动态清零。

Kube-OVN CVEs 问题修复的流程经历了如下几个阶段:

  • 发版/按需统一进行手动修复
  • 每次 commit 检测可修复安全漏洞,手动进行修复
  • master 依赖自动更新,发版分支部分依赖自动更新,少量手动修复
  • 未来目标:所有依赖自动更新,避免手动修复

按需修复

优势:

  • 相比每个安全漏洞单独修复,整体修复频次低
    劣势:
  • 发版集中修复,研发还要兼顾发版期间赶进度,测试,bug 修复,时间压力大
  • 依赖更新没有经过日常验证,存在未知的风险
  • 大部分安全修复工作没有实际意义还需要花费人工精力

每次 Commit 检测修复

增加工作:

优势:

  • 将 CVE 修复打散到平时,发版时时间压力较低
  • 可以快速发版
  • 大部分依赖更新已经得到了日常自动化测试的验证,风险也较低
    劣势:
  • 最后一次提交和发版扫描之间存在时间差,理论上会遗漏一部分 CVE
  • 会干扰平时正常功能提交,bug 修复,提交经常因为不相关的 CVE 问题被阻塞
  • 大量的手动修复

所有依赖自动更新

只要依赖更新版本就尝试更新,不考虑是否是安全更新。尝试解决比 CVE 修复更大的一个问题,自动就解决了 CVE 问题的修复。

我们的依赖项:

  • OS 镜像及其依赖:ubuntu:24.04, apt-get install ....
  • Go 语言版本,以及代码依赖库
  • 上游依赖:OVS, OVN
  • 其他协作组件依赖: kubernetes, kubevirt,multus, metallb, cilium, talos
  • 采用比较激进的更新策略,依赖大版本更新我们也会尝试更新

要做的事情:

优点:

  • 大部分 CVE 会在不知道情况下被修复,少量可在一天内自动修复,特殊情况再手动修复
  • 大量上游的 bugfix,性能提升和新功能被自动合入,软件整体稳定性提升
  • 大量的版本适配验证工作,如 k8s 版本更新,KubeVirt 版本更新的适配验证也都自动进行,风险提前知晓
  • 人工干预量较少

劣势:

  • 依赖更新多比较吵,需要设置聚合策略
  • 更新量太大无法人工测试,需要有自动化测试保证
  • 需要积极适配上游版本变化
  • 存在上游新版本不稳定风险,目前两年内遇到过两次

renovate 相比 dependabot 优势

  • 可以自定义依赖捕获,Dockerfile、Makefile 里的非标准依赖可以捕获
  • 可以在非 master 分支运行
  • 有 auto merge 能力

还未解决的问题

上一页
2025-06-28 00:02:21