外观
开源 ML 部署项目的漏洞实证研究
摘要
Rahman 等人从 GitHub Security Advisory 中收集 12 个开源 ML 部署项目的 149 个漏洞，分析严重性、后果和项目采用的质量保障活动。68 个漏洞被标为高危或严重，62.4% 的后果编码涉及未授权访问。研究说明 MLOps 控制面集中代码、数据与部署权限后，传统认证和输入处理缺陷会获得更大的 AI 生命周期影响。
核心创新与差异
原研究不是枚举单一产品 CVE，而是以可复核样本描述 ML 部署项目的漏洞分布，并检查 CI、代码审查、依赖升级、模糊测试和静态分析。本站把结论限定为开源项目与 GHSA 样本，不把漏洞比例外推到所有托管 MLOps 服务。
核心特点与评估范围
作者从搜索结果中筛选开源、与 ML 部署相关且存在 GHSA 记录的 12 个项目；样本包含 Airflow 等能编排训练与部署任务的控制面。两名研究者对漏洞后果开放编码，Cohen's Kappa 为 0.63。
评估方法与实际过程
研究统计 GHSA 严重性，归纳 10 类后果，并人工检查五类质量保障活动是否出现在项目仓库。数据集公开，允许复核样本与编码。本站未重新抓取当前 GHSA，因此不声称反映 2026 年最新漏洞数量。
关键结果与实际影响
149 个漏洞中 25 个严重、43 个高危；未授权访问占后果映射 62.4%，其次是恶意内容注入 10.7% 和信息暴露 9.4%。多数项目采用代码审查等活动，但模糊测试最少见，表明“已有 DevSecOps 流程”不能自动覆盖 MLOps 控制面输入和状态空间。
防护措施与验证方法
对 Notebook、流水线、注册表和部署入口做项目级最小权限；将模型、数据、Artifact URI 和工作负载身份纳入威胁建模；持续回放 GHSA/CVE 修复；为解析器、API 和 Pipeline 参数增加模糊测试与越权测试；把漏洞与受影响模型、作业和部署记录关联。
局限与待验证问题
样本只来自 GHSA 和开源项目，搜索与纳入标准也可能遗漏项目；研究没有测量每个漏洞的真实利用率或修复时延。专有 SageMaker、Vertex AI 等托管控制面不在结论范围内。