标题：基于图驱动混合分析与定量风险优先级排序的 Application Security（AppSec）正式化可扩展架构

1. 引言

应用安全（Application Security – AppSec）如今已成为公共和私营组织中主要的网络风险驱动因素之一。向基于微服务、RESTful API、基础设施即代码以及高度自动化 CI/CD 流水线的架构迁移，彻底改变了传统威胁模型。与孤立的单体系统不同，现代应用包含数百甚至数千个第三方依赖，其中许多依赖独立演进，从而引入潜在漏洞。

近期事件说明了该问题的严重性。Log4Shell 漏洞（CVE-2021-44228）通过 JNDI 注入实现远程代码执行，影响了全球数百万系统。Apache Struts（CVE-2017-5638）的利用与针对 Equifax 的攻击相关，暴露了补丁管理和输入验证方面持续存在的缺陷。在 MITRE ATT&CK 语境下，诸如 T1190（Exploit Public-Facing Application）和 T1059（Command and Scripting Interpreter）等技术，在 Mandiant 和 Verizon DBIR 报告中仍然位居最常见之列。

尽管 SAST（Static Application Security Testing）、DAST（Dynamic Application Security Testing）和 SCA（Software Composition Analysis）工具取得了进展，但仍可观察到较高的误报率、缺乏可利用性上下文，以及难以进行优先级排序。在企业环境中，流水线通常会生成成千上万条告警，而人工分流能力有限。数据流、传递依赖与风险指标之间缺乏语义集成，削弱了运行效能。

基于这一背景，我们提出如下研究问题：

RQ1：如何在一个统一模型中形式化地整合多种 AppSec 技术，以捕获结构性依赖和真实可利用的数据流？

RQ2：如何在考虑标准化度量（如 CVSS）及代码结构属性的同时，对漏洞风险进行上下文化量化？

RQ3：在保持较高分析精度的同时，是否可以实现对大规模应用的可扩展性？

我们的主要贡献如下：

C1：我们提出了一种基于带标签有向图的形式化模型，将静态、动态和依赖分析整合于共同语义之下。

C2：我们引入了一种基于图中心性、估计可利用概率和 CVSS 严重度的定量风险优先级机制。

C3：我们实现并经验评估了一个分布式系统，证明其在降低误报和提升运行优先级方面具有显著效果。

本文其余部分组织如下。第 2 节介绍基础知识和相关工作。第 3 节定义威胁模型并形式化问题。第 4 节描述所提方法。第 5 节详细说明实现。第 6 节给出实验评估。第 7 节讨论启示与局限。第 8 节总结全文并指出未来方向。

2. 背景与相关工作

形式化地，我们将一个应用建模为带标签有向图 $G = (V, E, \lambda)$，其中 $V$ 表示代码实体（函数、类、端点），$E \subseteq V \times V$ 表示关系（调用、数据流、依赖），而 $\lambda: V \cup E \rightarrow \Sigma$ 将语义标签关联到节点和边。

SAST 方法，如 Livshits 和 Lam 在 USENIX Security 2005 中描述的方案，利用数据流分析识别 SQL 注入等漏洞。DAST 则基于模糊测试和受监控执行，正如 Zalewski 关于 AFL 的工作中所讨论的那样。SCA 工具，如 Black Duck 和 OWASP Dependency-Check，则侧重于版本映射与 CVE 数据库。

我们可以将现有方法分为三类：

1. 基于签名的孤立分析。
2. 基于跨过程流的静态分析。
3. 结合动态插桩的混合方法。

然而，局限依然存在：(i) 由于缺乏执行上下文而导致较高的误报率；(ii) 对具有数百万节点的图而言可扩展性不足；(iii) 缺乏面向结构性影响的优先级排序。

近期工作探索了程序图和机器学习用于漏洞检测（例如 Devign，Zhou 等，NeurIPS 2019），但往往缺乏与 DevSecOps 流水线和正式风险度量的操作性集成。

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

我们假设攻击者具备以下能力：

• 利用已知漏洞（超出范围的是零日漏洞）。
• 与公共端点交互。
• 链式组合漏洞（chaining）。
• 操纵任意输入。

我们不假设其已在内部获得预先控制权限。

我们将检测到的漏洞集合定义为 $Vul = {v_1, v_2, …, v_n}$。每个漏洞 $v_i$ 都与一个节点子集 $S_i \subseteq V$ 相关联。

上下文化风险建模如下：

$$ R(v_i) = S_{cvss}(v_i) \cdot P_{exploit}(v_i) \cdot C_{struct}(v_i) $$

其中：

• $S_{cvss}$ 为归一化后的 CVSS 评分。
• $P_{exploit}$ 为通过基于结构特征的逻辑回归估计得到的可利用概率。
• $C_{struct}$ 为图中的介数中心性：

$$ C_{struct}(v_i) = \sum_{s \neq t} \frac{\sigma_{st}(v_i)}{\sigma_{st}} $$

其中 $\sigma_{st}$ 表示 $s$ 与 $t$ 之间的最短路径数量。

该问题在于根据 $R(v_i)$ 对 $Vul$ 进行排序，并最大化其与实际观测到的利用行为之间的相关性。

4. 所提方法

该架构由四个模块组成：

1. 语义图提取。
2. 混合分析引擎。
3. 可利用概率估计器。
4. 优先级排序机制。

Algorithm 1: 构建集成图

Input: 源代码 C, 依赖 D
Output: 图 G

1: V <- extrair_entidades(C, D)
2: E_call <- extrair_chamadas(C)
3: E_data <- analisar_fluxo_dados(C)
4: E_dep <- mapear_dependencias(D)
5: G <- (V, E_call ∪ E_data ∪ E_dep)
6: return G

近似复杂度：增量构建为 $O(|V| + |E|)$。

Algorithm 2: 漏洞优先级排序

Input: 漏洞 Vul, 图 G
Output: 排序列表 L

1: for v in Vul:
2:     S_cvss <- normalizar_cvss(v)
3:     P_exploit <- estimar_probabilidade(v, G)
4:     C_struct <- calcular_centralidade(v, G)
5:     R[v] <- S_cvss  P_exploit  C_struct
6: L <- ordenar_por_valor(R)
7: return L

中心性计算采用 Brandes 近似算法，复杂度为 $O(|V||E|)$，并通过采样进行优化。

5. 实现

我们在基于 Kubernetes 的分布式架构上实现了原型。后端使用 Rust 开发静态分析部分，使用 Python 进行统计建模。我们使用 Neo4j 存储最多 120 万节点的图。

我们与 GitHub Actions 和 GitLab CI 集成，支持 Java、Python 和 JavaScript 语言。平均流水线在由 16 个节点组成的集群上（每节点 Intel Xeon 32 核、128GB RAM）处理了 530 万行代码，耗时 38 ± 4.2 分钟。

权衡主要体现在完整跨过程精度与摘要式分析之间的选择，以换取性能提升。

6. 实验评估

我们评估了 42 个开源项目，共计 9,317 个已知 CVE。

指标：

• 精确率（Precision）
• 召回率（Recall）
• F1-score
• 误报率

平均结果：

• 传统 SAST：精确率 0.61；召回率 0.74；F1 0.67。
• 我们的方法：精确率 0.84；召回率 0.79；F1 0.81。

误报减少：37.4%。

风险排序与模拟真实利用之间的 Spearman 相关系数为 0.72，而单独使用 CVSS 时为 0.46。

额外计算开销比单独 SAST 高 18%，但仍处于企业流水线 SLA 范围内（<60 分钟）。

7. 讨论

结果表明，结构中心性是预测可利用影响的强指标。具有较高介数中心性的漏洞，在模拟攻击链中参与的概率高出 2.3 倍。

局限性包括对流建模质量的依赖以及缺乏深度二进制分析。对复杂动态语言的泛化仍需进一步改进。

有效性威胁包括开源数据集偏差以及受控的利用模拟。

8. 结论与未来工作

我们证明了一种面向图的形式化架构，结合混合分析与定量优先级排序，能够显著提升 AppSec 中的精确性与运行相关性。

作为未来工作，我们计划通过图深度学习集成零日漏洞检测，并扩展对基础设施即代码（IaC）及基于 eBPF 的运行时策略分析的支持。

References

[1] MITRE, “ATT&CK Framework,” 2023.
[2] OWASP, “Top 10,” 2021.
[3] NIST, “SP 800-53,” 2020.
[4] T. H. Austin and C. Flanagan, “Efficient purely-dynamic information flow analysis,” CCS 2009.
[5] V. B. Livshits and M. S. Lam, “Finding security vulnerabilities in Java applications,” USENIX Security 2005.
[6] M. Zalewski, “American Fuzzy Lop,” 2014.
[7] P. Mell et al., “CVSS v3.1 Specification,” FIRST, 2019.
[8] Apache Foundation, “CVE-2017-5638.”
[9] Apache Foundation, “CVE-2021-44228.”
[10] Verizon, “Data Breach Investigations Report,” 2023.
[11] FireEye Mandiant, “M-Trends,” 2022.
[12] S. Zhou et al., “Devign,” NeurIPS 2019.
[13] Neo4j Documentation, 2024.
[14] Kubernetes Documentation, 2024.
[15] GitHub, “Actions Documentation,” 2024.
[16] OWASP, “Dependency-Check,” 2023.
[17] Black Duck Software, “Open Source Security Report,” 2023.
[18] U. Brandes, “A Faster Algorithm for Betweenness Centrality,” J. Math. Sociology, 2001.
[19] ISO/IEC 27034, “Application Security,” 2011.
[20] ENISA, “Threat Landscape,” 2023.