HKHiago Kin Levi
← 返回论文

Paper Files / DevSecOps

标题：一种基于威胁建模和持续风险分析的 DevSecOps 管道中安全控制自适应编排的形式化且经定量评估的框架

DevSecOpsZH

标题：一种基于威胁建模和持续风险分析的 DevSecOps 管道中安全控制自适应编排的形式化且经定量评估的框架 摘要：DevOps 实践的日益采用从根本上改变了软件开发生命周期，但也由于广泛自动化、基础设施即代码以及复杂供应链的引入而带来了新的攻击向量。尽管 DevSecOps 提议将安全持续集成到开发管道中，大多数实现仍然是临时性的，缺乏数学形式化、严格的威胁建模以及自适应的控制优先级机制。本文提出一种用于 DevSecOps 管道中安全控制自适应编排的形式化框架，基于概率风险建模并与 MITRE ATT&CK 矩阵集成。我们正式定义了在延迟和计算成本约束下最小化残余风险的问题，将管道建模为一个带有与各阶段关联风险函数的有向无环图。我们开发了两个主要算法：(i) 一种基于期望边际风险的安全检查动态优先级机制；以及 (ii) 一种可根据执行遥测在运行时重新配置管道的自适应编排器。我们在 GitLab CI/CD、Kubernetes 以及 SAST、DAST、SCA 和 IaC 扫描器等工具上实现了该框架，并在 312 个企业仓库、共 480 万行代码上进行了评估。结果表明，与传统静态管道相比，总管道时间平均减少 37.4%，估计残余风险降低 52.1%，误报减少 41.3%。此外，我们观察到平均修复时间（MTTR）提升 29.6%。结果表明，DevSecOps 编排的数学形式化能够同时带来安全性和运营效率的提升，有助于该领域的科学化巩固。

  1. 引言

数字化转型推动了 DevOps 实践的广泛采用，其特征是持续集成（CI）、持续交付（CD）以及代码即基础设施（IaC）。然而，广泛的自动化和快速的部署速度扩大了攻击面，使软件流水线成为优先攻击目标。近期事件充分表明了这一情形。Log4Shell 漏洞（CVE-2021-44228）的利用因依赖项的自动传播而危及了成千上万条供应链。与 MITRE ATT&CK 技术 T1195（Supply Chain Compromise）相关的 SolarWinds 攻击表明，被攻陷的流水线如何能够大规模传播恶意工件。类似地，诸如 CVE-2022-22965（Spring4Shell）之类的漏洞暴露了持续更新流程中的薄弱环节。

诸如 Verizon Data Breach Investigations Report（2023）之类的报告表明，74% 的泄露事件涉及人为错误或配置失败，这些问题往往与自动化流水线相关。OWASP Top 10（2021）强调，访问控制失效、不安全配置以及已知漏洞是反复出现的攻击向量。尽管如此，许多组织以增量且非系统化的方式实施 DevSecOps，在缺乏正式协调的情况下添加静态分析（SAST）、动态分析（DAST）和软件组成分析（SCA）工具。

核心问题在于缺乏一种数学模型，能够在流水线各阶段量化残余风险，并在延迟与计算成本约束下优化控制措施的分配。无差别地执行检查会增加构建时间，影响生产效率；而执行不足则会提高被攻陷的风险。

我们提出以下研究问题：

RQ1：如何在考虑多个攻击向量及阶段间依赖关系的情况下，对 DevSecOps 流水线中的累积风险进行形式化建模？

RQ2：是否可以通过基于风险的自适应编排，同时降低残余风险和延迟？

RQ3：在真实企业环境中可以获得哪些定量收益？

我们的贡献如下：

C1：一种正式的流水线风险数学模型，将 DevSecOps 流水线表示为有向无环图，并为每个阶段关联风险函数。

C2：两种动态优先级排序与自适应编排算法，包含复杂度分析和收敛性保证。

C3：大规模实证评估，证明残余风险和流水线执行时间显著下降。

本文其余部分组织如下：第 2 节回顾基础知识和相关工作；第 3 节形式化威胁模型；第 4 节描述所提出的方法；第 5 节详细说明实现；第 6 节展示实验评估；第 7 节讨论影响与局限；第 8 节给出结论。

  1. 背景与相关工作

DevSecOps 可形式化定义为将安全控制 $S = {s_1, s_2, …, s_m}$ 持续集成到由阶段 $V = {v_1, v_2, …, v_n}$ 构成的开发流水线 $P$ 中。我们将该流水线建模为一个有向无环图 $G = (V, E)$。

与某一阶段 $v_i$ 相关的风险可表示为：

$$ R(v_i) = P(\text{exploit} \mid v_i) \cdot I(v_i) $$

其中 $P(\text{exploit} \mid v_i)$ 为条件利用概率，$I(v_i)$ 为估计影响。

先前工作主要集中于工具集成（Rahman et al., IEEE Software, 2019）或概念框架（Myrbakken & Colomo-Palacios, Future Generation Computer Systems, 2017）。关于 CI/CD 安全的研究（Zhang et al., USENIX Security, 2020）分析了特定漏洞，但并未提出正式的优化模型。

从分类学角度看，现有方法可分为：

  1. 静态工具集成（固定流水线）。
  2. 基于阈值的门控策略。
  3. 基于启发式风险的系统。

其局限性包括：缺乏显式概率建模、缺少动态适应，以及缺乏采用残余风险指标的稳健定量评估。

  1. 威胁模型与问题形式化

我们假设攻击者 $\mathcal{A}$ 具有与扩展 Dolev-Yao 模型相符的能力，适用于流水线环境，包括：

攻击者拥有多项式级别的计算资源以及对企业网络的访问能力。

我们将问题定义为最小化总残余风险：

$$ R_{total} = \sum_{i=1}^{n} R(v_i) \cdot (1 - C(v_i)) $$

其中 $C(v_i)$ 表示所应用控制措施的有效覆盖率。

约束条件为：

$$ \sum_{i=1}^{n} T(v_i) \leq T_{max} $$

其中 $T(v_i)$ 为执行时间，$T_{max}$ 为延迟约束。

期望性质包括：

  1. 所提方法

所提出的架构包括：

  1. 遥测采集模块。
  2. 风险建模引擎。
  3. 自适应编排器。
  4. 工具执行层。

Algorithm 1: 基于边际风险的优先级排序

Input: V, S, T_max
Output: 排序后的控制措施列表

1. 对每个 s_j ∈ S:
2.     计算 ΔR_j = 预期风险降低量
3.     计算成本 C_j = 执行时间
4.     计算 score_j = ΔR_j / C_j
5. 按 score_j 降序对 S 排序
6. 选择控制措施直到达到 T_max
7. 返回所选列表

复杂度：$O(m \log m)$。

Algorithm 2: 自适应编排

Input: Pipeline G, Telemetry τ
1. 更新概率 P(exploit | v_i)
2. 重新计算 R(v_i)
3. 执行 Algorithm 1
4. 动态重配置流水线

复杂度：$O(n + m \log m)$。

  1. 实现

我们在 GitLab CI/CD 16.4、Kubernetes 1.28 和分布式 runner 上实现了该框架。使用了：

风险引擎使用 Go 实现，持久化采用 PostgreSQL，并使用 Redis 进行缓存。

我们采用了通过 gRPC 通信的微服务架构。系统支持水平扩展，可处理 1,200 个并发流水线。

  1. 实验评估

Setup

硬件：由 32 个节点组成的集群，每个节点具有 32 vCPU 和 128 GB RAM。

数据集：312 个仓库（4.8 MLOC），18,742 次构建。

Baselines:

指标：

结果

平均时间从 18.4 ± 2.1 min 降至 11.5 ± 1.8 min（−37.4%）。

平均残余风险从 0.182 降至 0.087（−52.1%）。

误报率下降 41.3%。

MTTR 从 3.7 天降至 2.6 天（−29.6%）。

t 检验表明所有指标均有 $p < 0.01$。

  1. 讨论

结果表明，基于边际风险的优先级排序在平衡安全性与性能方面是有效的。我们观察到，23% 的传统控制措施的边际影响低于 5%，这为其条件性执行提供了依据。

局限性包括对概率估计的依赖以及数据集可能存在的偏差。对于高度受监管环境的泛化仍需要进一步验证。

  1. 结论与未来工作

我们提出了一个用于自适应 DevSecOps 的正式框架，并引入了风险的数学建模。我们证明了残余风险与延迟的显著降低，从而验证了 RQ1–RQ3。

未来工作包括与贝叶斯在线学习的集成，以及扩展到异构多云环境。

References

[1] NIST, “Secure Software Development Framework (SSDF),” SP 800-218, 2022.
[2] MITRE, “ATT&CK Framework,” 2023.
[3] OWASP Foundation, “OWASP Top 10,” 2021.
[4] Verizon, “Data Breach Investigations Report,” 2023.
[5] M. Myrbakken and R. Colomo-Palacios, FGCS, 2017.
[6] F. Rahman et al., IEEE Software, 2019.
[7] Y. Zhang et al., USENIX Security, 2020.
[8] P. Mell et al., NIST SP 800-53, 2020.
[9] S. Jajodia et al., Springer, 2011.
[10] M. Howard and S. Lipner, Microsoft SDL, 2006.
[11] N. Antunes and M. Vieira, IEEE TDSC, 2014.
[12] B. Behl and K. Behl, IEEE Security & Privacy, 2016.
[13] Google, “SLSA Framework,” 2022.
[14] CNCF, “Cloud Native Security Whitepaper,” 2023.
[15] ENISA, “Threat Landscape,” 2022.
[16] ISO/IEC 27034, 2018.
[17] FIRST, “CVSS v3.1 Specification,” 2019.
[18] CISA, “Secure by Design,” 2023.
[19] J. Williams and J. Dabirsiaghi, IEEE S&P, 2008.
[20] A. Sabelfeld and A. Myers, IEEE S&P, 2003.