AI-Driven Hybrid SAST–DAST–SCA–IAST Framework for Risk-Based Vulnerability Prioritization in Microservice Architectures

1. Introduction

The rapid adoption of microservice architectures has fundamentally reshaped modern software systems, enabling organizations to achieve agile deployment, fine-grained scalability, and service-level isolation. Despite these advantages, microservices also introduce highly fragmented and dynamic attack surfaces. Each service exposes its own API endpoints, independent runtime environment, language stack, and third-party dependency chain, resulting in complex cross-service interactions and significantly increased security risk. Traditional vulnerability management approaches, which rely on isolated scanning tools or manual triage, are no longer able to cope with the volume, velocity, and variability of security findings generated by distributed applications. As a consequence, security teams often struggle with inaccurate prioritization, high false-positive rates, and limited visibility into real exploitability across heterogeneous components.

To mitigate these challenges, modern DevSecOps pipelines incorporate multiple forms of security testing, including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA), and Interactive Application Security Testing (IAST). SAST provides early-stage detection in source code or bytecode through syntax-tree parsing and taint analysis, while DAST evaluates the behavior of a running application by simulating attacks such as SQL injection, XSS, or authentication bypass. SCA analyzes software bills of materials (SBOMs) to identify vulnerable third-party dependencies, and IAST instruments applications at runtime to observe real code execution flows. Although each technique offers valuable insights, they operate independently—producing inconsistent, redundant, or conflicting results when applied to complex microservices. Without effective fusion of cross-source signals, organizations are unable to obtain a coherent understanding of risk or accurately assess which vulnerabilities demand immediate remediation.

Artificial intelligence provides a promising path toward transforming this fragmented process into an intelligent, risk-driven vulnerability management paradigm. Machine learning models can correlate heterogeneous scanning outputs, learn patterns from historical vulnerability data, and predict exploit likelihood by analyzing code semantics, API behavior, dependency CVEs, and microservice communication patterns. Furthermore, AI-based classification and clustering algorithms can significantly reduce false positives, identify duplicated findings across services, and capture subtle relationships that are difficult to detect with rule-based systems alone. These capabilities align closely with the principles of Risk-Based Vulnerability Management (RBVM), which prioritizes remediation based on real-world impact rather than raw vulnerability counts.

However, several open challenges remain. First, the integration of SAST, DAST, SCA, and IAST requires a unified representation capable of capturing both static semantics and dynamic runtime evidence. Second, automated integration with CI/CD pipelines such as Jenkins, GitHub Actions, and GitLab CI is essential to support continuous security scanning in high-frequency deployment environments. Third, multi-layer dependency analysis must address the complexity of transitive libraries and containerized components, particularly when using IRX-based packaging formats. Finally, when analysis is performed in the cloud, privacy-preserving processing is required to ensure that sensitive code fragments are properly desensitized and securely transmitted.

In response to these challenges, this paper presents an AI-driven hybrid vulnerability prioritization framework tailored for microservice architectures. The proposed system fuses results from SAST, DAST, SCA, and IAST into a unified analysis pipeline, employs machine-learning techniques to enhance detection accuracy and reduce noise, and incorporates SBOM-based dependency assessment to provide a multi-layer understanding of security posture. The framework further supports CI/CD automation and introduces a privacy-preserving IRX transmission mechanism for secure cloud-side processing. Experimental evaluations conducted on real-world microservice applications demonstrate that the proposed approach improves vulnerability detection precision, reduces triage overhead, and delivers more reliable risk-based prioritization for large-scale distributed systems.

1.1. Related Work

Security research for microservice-based systems has expanded significantly due to their distributed nature, heterogeneous technology stacks, and rapid deployment characteristics. A comprehensive literature review highlights that microservice architectures introduce fragmented trust boundaries and complex dependency relationships, leading to an expanded attack surface and new vulnerability propagation paths [1,2]. Existing studies confirm that authentication, intra-service communication, and dependency risks are primary sources of security exposure in microservices [3], while container orchestration platforms such as Kubernetes further elevate risks of image tampering, misconfiguration, and credential leakage [4]. These findings demonstrate that microservice security cannot be achieved solely through perimeter mechanisms and requires integrated runtime vulnerability intelligence.

A key research direction focuses on mapping security mechanisms and identifying root causes of microservice breaches. Pereira-Vale et al. analyzed commonly adopted protection measures and concluded that gateway authorization and token-based identity enforcement cannot mitigate code-level or supply-chain weaknesses [6]. Hannousse and Yahiouche emphasized that misconfigurations and dependency exploitation are more prevalent in microservices than in traditional monolithic architectures [5]. Collectively, these studies highlight the need for vulnerability management that bridges static code semantics and runtime attack surfaces.

To improve operational resilience, researchers have proposed integrating continuous security assessment into DevSecOps workflows. Torkura et al. introduced an early continuous security model for cloud-native pipelines, encouraging automated scanning across SAST and DAST tools [7]. The NIST SP 800-204C guidance later extended these principles to service mesh architectures, advocating zero-trust communication enforcement and security observability within intra-service traffic [11]. Similarly, the NIST Secure Software Development Framework (SSDF) recommends multi-phase vulnerability detection aligned with CWE and CVE models [12]. However, these works do not define how to fuse heterogeneous vulnerability evidence originating from scanning modalities such as SAST, DAST, SCA and IAST, nor do they provide mechanisms for exploit likelihood evaluation within microservices.

Several studies have evaluated software vulnerability analysis and prioritization strategies. Jayalath et al. synthesized empirical findings showing that multi-tool vulnerability reports remain inconsistent and often contain duplicated issues or mismatched severity interpretation [1]. Jiang et al. proposed a taxonomy for vulnerability prioritization and concluded that existing scoring schemes fail to incorporate contextual exploitability involving API traffic and inter-service dependencies [9]. Ogundairo and Broklyn demonstrated the benefits of using machine learning for vulnerability classification but acknowledged the limited availability of runtime execution traces, which restricts model accuracy in distributed systems [10]. These findings underline the need for a unified vulnerability reasoning framework that leverages source code semantics, dependency relationships, and runtime exploit signals.

Given the escalation of software supply-chain attacks, SBOM-driven security has emerged as a critical research area. NIST guidelines formalized SBOM as a foundation for transparency and lifecycle tracking of software components [13]. A joint CISA–ENISA report defined shared metadata schemas and interoperability requirements for cross-platform dependency assessment [14], and the SBOMOps working group further outlined continuous SBOM enrichment and change-tracking practices [15]. Although these contributions improve component visibility, they do not address the dynamic exposure of dependencies in microservices nor provide incident-driven vulnerability prioritization strategies.

In parallel, risk-based vulnerability management (RBVM) has gained traction. Tenable defined RBVM as a shift from vulnerability volume–based remediation toward risk-driven prioritization [18]. Balbix expanded this notion by incorporating exploitability inference, asset value estimation, and attack path modeling [19]. More recently, AI-powered vulnerability prioritization research reported improvements in remediation efficiency based on contextual signals [20], while Balsam et al. integrated CVSS scoring with machine learning and achieved measurable reductions in false positives [8]. These studies demonstrate that AI-driven vulnerability triage is feasible; however, the methods have not been tailored to the interaction patterns and service-level propagation behaviors of microservice applications.

Runtime-aware security testing is another essential component of modern vulnerability research. DAST has been widely used to detect SQL injection, cross-site scripting, and authentication bypass by simulating external attacks on running applications [2]. IAST complements this by instrumenting service execution to capture code paths, taint flows, and security events observable only at runtime [2]. Yet, absent integration with SAST/SCA results, runtime evidence remains isolated, preventing accurate determination of exploit feasibility across service boundaries.

A critical research gap also exists in secure cloud-based vulnerability analysis. As SBOM, IRX, and code artifact sharing become more common in managed scanning environments, protecting proprietary logic and sensitive code fragments becomes essential. NIST and CISA emphasize secure data handling but provide no detailed mechanism for automated code desensitization or encrypted IRX analytics [13,14]. This motivates the need for privacy-preserving vulnerability assessment pipelines.

1.2. Methodology

In this chapter, we present the proposed AI-driven hybrid SAST–DAST–SCA–IAST vulnerability prioritization framework for microservice architectures. The core idea is to treat vulnerabilities not as isolated findings from individual tools, but as manifestations of a latent risk process that propagates along code structures, runtime execution paths, and software dependency graphs. The methodology therefore focuses on three aspects:

Constructing rich static, dynamic and dependency representations of each vulnerability.

Fusing these heterogeneous signals into a unified feature space.

Learning a risk-based scoring function that outputs a prioritized list of vulnerabilities aligned with real exploitability and impact in microservice environments.

Overall Architectural Design

At the system level, a microservice application is modeled as a collection of services, each with its own codebase, deployment configuration, dependency tree and runtime behavior. We denote the microservice system as:

$$\mathrm{M}=s_1,s_2,\dots ,s_M$$

(1)

where each service ${\mathrm{s}}_{\mathrm{j}}$ may be implemented in a different language and deployed in a separate container or node.

For each service, we run a set of scanners:

$$\mathrm{T}=\mathrm{SAST},\mathrm{DAST},\mathrm{SCA},\mathrm{IAST}$$

(2)

and obtain a raw vulnerability set:

$$\mathrm{V}={\bigcup }_{\mathrm{t}\in \mathrm{T}} {\mathrm{V}}^{(\mathrm{t})}={\mathrm{v}}_1,{\mathrm{v}}_2,\dots ,{\mathrm{v}}_{\mathrm{N}}$$

(3)

Each vulnerability ${\mathrm{v}}_{\mathrm{i}}$ is associated with a service $\mathrm{s}({\mathrm{v}}_{\mathrm{i}})\in \mathrm{M}$ and a location within that service (e.g., source file, API endpoint, dependency component, or runtime execution path).

At the feature level, each vulnerability is represented as a composite vector:

$${\mathrm{x}}_{\mathrm{i}}={\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SAST})}\oplus {\mathrm{x}}_{\mathrm{i}}^{(\mathrm{DAST})}\oplus {\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SCA})}\oplus {\mathrm{x}}_{\mathrm{i}}^{(\mathrm{IAST})}\oplus {\mathrm{x}}_{\mathrm{i}}^{(\mathrm{ctx})}$$

(4)

where $\oplus$ denotes vector concatenation and ${\mathrm{x}}_{\mathrm{i}}^{(\mathrm{ctx})}$ captures contextual information such as service criticality, business importance, and time-varying threat intelligence.

On top of this representation, the framework learns a scoring function:

$${\mathrm{f}}_{\mathsf{\theta }}:{\mathrm{R}}^{\mathrm{d}}\to \mathrm{R}, \mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}={\mathrm{f}}_{\mathsf{\theta }}({\mathrm{x}}_{\mathrm{i}})$$

(5)

which outputs a continuous risk score used to rank vulnerabilities.

Figure 1. Proposed AI-driven hybrid vulnerability prioritization framework for microservice architectures.

Figure 1. Proposed AI-driven hybrid vulnerability prioritization framework for microservice architectures.

The figure should show:

–

Input layer with SAST / DAST / SCA / IAST tools attached to microservices

–

Feature extraction and fusion layer

–

AI-based risk scoring model

–

CI/CD integration and feedback loop to developers and security teams

1.3. Static and Dynamic Code Semantics Modeling

To capture deep semantic information, the framework constructs multiple graph-based representations for each service. For service ${\mathrm{s}}_{\mathrm{j}}$, we compute:

An abstract syntax tree (AST),

A control-flow graph (CFG),

A data-flow graph (DFG).

These are denoted as:

$${\mathrm{G}}_{\mathrm{j}}^{(\mathrm{AST})}=({\mathrm{V}}_{\mathrm{j}}^{(\mathrm{AST})},{\mathrm{E}}_{\mathrm{j}}^{(\mathrm{AST})}), {\mathrm{G}}_{\mathrm{j}}^{(\mathrm{CFG})}=({\mathrm{V}}_{\mathrm{j}}^{(\mathrm{CFG})},{\mathrm{E}}_{\mathrm{j}}^{(\mathrm{CFG})}), {\mathrm{G}}_{\mathrm{j}}^{(\mathrm{DFG})}=({\mathrm{V}}_{\mathrm{j}}^{(\mathrm{DFG})},{\mathrm{E}}_{\mathrm{j}}^{(\mathrm{DFG})})$$

(6)

1.4. Static Graph Encoding and Taint Analysis

We begin by defining an initial node feature matrix ${\mathrm{H}}^{(0)}\in {\mathrm{R}}^{\left|\mathrm{V}\right|\times {\mathrm{d}}_0}$ for nodes across these graphs. A generic $\mathrm{L}$-layer graph encoder is:

$${\mathrm{H}}^{(\mathrm{l}+1)}=\mathsf{\sigma }({\tilde{\mathrm{D}}}^{-{\displaystyle \frac{1}{2}}}\tilde{\mathrm{A}}{\tilde{\mathrm{D}}}^{-{\displaystyle \frac{1}{2}}}{\mathrm{H}}^{(\mathrm{l})}{\mathrm{W}}^{(\mathrm{l})}), \mathrm{l}=0,\dots ,\mathrm{L}-1$$

(7)

where:

• $\tilde{\mathrm{A}}$ is the (possibly combined) adjacency matrix for AST/CFG/DFG,
• $\tilde{\mathrm{D}}$ is the corresponding degree matrix,
• ${\mathrm{W}}^{(\mathrm{l})}$ are learnable weights,
• $\mathsf{\sigma }(\cdot )$ is a non-linear activation.

For a vulnerability ${\mathrm{v}}_{\mathrm{i}}$ associated with node $\mathrm{u}$ in the code graphs, we aggregate node embeddings in its neighborhood $\mathrm{N}({\mathrm{v}}_{\mathrm{i}})$ to obtain the static feature:

$${\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SAST})}=\mathrm{READOUT}({\mathrm{H}}_{\mathrm{u}}^{(\mathrm{L})}:\mathrm{u}\in \mathrm{N}({\mathrm{v}}_{\mathrm{i}}))$$

(8)

Taint analysis is integrated into this graph modeling. Let $\mathrm{T}(\mathrm{u})\in 0,1$ be a binary taint label for node $\mathrm{u}$. A vulnerability candidate is considered tainted if there exists a path from a source node in $\mathrm{S}$ to a sink node in $\mathrm{K}$ passing only through tainted nodes:

$$\exists ({\mathrm{u}}_0,{\mathrm{u}}_1,\dots ,{\mathrm{u}}_{\mathrm{L}}): {\mathrm{u}}_0\in \mathrm{S},;{\mathrm{u}}_{\mathrm{L}}\in \mathrm{K},;\mathrm{T}({\mathrm{u}}_{\mathrm{l}})=1,;\forall \mathrm{l}$$

(9)

We capture this condition with a path indicator:

$${\mathsf{\chi }}_{\mathrm{taint}}({\mathrm{v}}_{\mathrm{i}})=\left\{\begin{array}{lll}1,& \mathrm{if} \mathrm{such} \mathrm{a} \mathrm{path} \mathrm{exists} \mathrm{for} {\mathrm{v}}_{\mathrm{i}}, 0,& \mathrm{otherwise} \end{array}\right.$$

(10)

This indicator can be appended as an additional feature within ${\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SAST})}$ or used to weight its magnitude.

1.5. Dynamic Traces from DAST and IAST

On the dynamic side, runtime execution and attack simulation are modeled as temporal traces. Let:

${\mathrm{r}}_{\mathrm{k}}$ be the $\mathrm{k}$-th request vector (HTTP or API),

${\mathrm{y}}_{\mathrm{k}}$ be the corresponding response or outcome.

A DAST campaign of length $\mathrm{K}$ yields:

$$\mathrm{T}*\mathrm{DAST}={\mathsf{\tau }}_{\mathrm{k}}*{\mathrm{k}=1}^{\mathrm{K}}, {\mathsf{\tau }}_{\mathrm{k}}=({\mathrm{r}}_{\mathrm{k}},{\mathrm{y}}_{\mathrm{k}})$$

(11)

For a vulnerability ${\mathrm{v}}_{\mathrm{i}}$, we define a dynamic support measure:

$${\mathsf{\eta }}_{\mathrm{i}}^{(\mathrm{DAST})}={\displaystyle \frac{1}{\mathrm{K}}}{\sum }_{\mathrm{k}=1}^{\mathrm{K}} \mathrm{I}({\mathsf{\tau }}_{\mathrm{k}} \mathrm{triggers} {\mathrm{v}}_{\mathrm{i}})$$

(12)

and an empirical exploit probability:

$$\stackrel{\mathrm{ˆ}}{\mathrm{P}}*\mathrm{DAST}({\mathrm{v}}_{\mathrm{i}})={\displaystyle \frac{\sum *{\mathrm{k}=1}^{\mathrm{K}}\mathrm{I}({\mathrm{y}}_{\mathrm{k}}\in \mathrm{E}*\mathrm{i})}{\sum *{\mathrm{k}=1}^{\mathrm{K}}\mathrm{I}({\mathrm{r}}_{\mathrm{k}}\in {\mathrm{R}}_{\mathrm{i}})}}$$

(13)

where:

${\mathrm{E}}_{\mathrm{i}}$ is the set of response outcomes consistent with successful exploitation of ${\mathrm{v}}_{\mathrm{i}}$,

${\mathrm{R}}_{\mathrm{i}}$ is the subset of requests that target the related sink or endpoint.

An analogous construction is applied for IAST using internal call-path and instrumentation events. The resulting dynamic vector for ${\mathrm{v}}_{\mathrm{i}}$ is:

$$\mathrm{x}*{\mathrm{i}}^{(\mathrm{dyn})}=\left[\begin{array}{c}{\mathsf{\eta }}_{\mathrm{i}}^{(\mathrm{DAST})} \stackrel{\mathrm{ˆ}}{\mathrm{P}}*\mathrm{D}\mathrm{A}\mathrm{S}\mathrm{T}({\mathrm{v}}_{\mathrm{i}}) {\mathsf{\eta }}_{\mathrm{i}}^{(\mathrm{IAST})} {\stackrel{\mathrm{ˆ}}{\mathrm{P}}}_{\mathrm{IAST}}({\mathrm{v}}_{\mathrm{i}})\end{array}\right]$$

(14)

These dynamic signals capture how often and how successfully an issue appears to be exploitable under real or simulated workloads.

1.6. Dependency and SBOM-Centric Risk Modeling

Because microservices heavily rely on third-party libraries, container images and external services, dependency risk is explicitly modeled using SBOM (Software Bill of Materials) data.

For a given service ${\mathrm{s}}_{\mathrm{j}}$, its components are:

$$\mathrm{D}*\mathrm{j}=\mathrm{d}*\mathrm{j}1,{\mathrm{d}}_{\mathrm{j}2},\dots ,{\mathrm{d}}_{\mathrm{j}{\mathrm{K}}_{\mathrm{j}}}$$

(15)

Each component ${\mathrm{d}}_{\mathrm{jk}}$ may have multiple associated CVEs and corresponding CVSS/EPSS scores. If vulnerability ${\mathrm{v}}_{\mathrm{i}}$ is associated with component ${\mathrm{d}}_{\mathrm{jk}}$, we define a dependency risk vector:

$$*{\mathrm{i}}^{(\mathrm{dep})}=\left[\begin{array}{c}\mathrm{C}\mathrm{V}\mathrm{S}{\mathrm{S}}_{\mathrm{i}} \mathrm{E}\mathrm{P}\mathrm{S}{\mathrm{S}}_{\mathrm{i}} \mathrm{N}*\mathrm{C}\mathrm{V}\mathrm{E},\mathrm{i} {\mathrm{R}}_{\mathrm{reach},\mathrm{i}}\end{array}\right]$$

(16)

where:

$\mathrm{CVS}{\mathrm{S}}_{\mathrm{i}}$ is the CVSS base score for ${\mathrm{v}}_{\mathrm{i}}$,

$\mathrm{EPS}{\mathrm{S}}_{\mathrm{i}}$ is an exploit prediction score,

${\mathrm{N}}_{\mathrm{CVE},\mathrm{i}}$ is the number of CVEs affecting that component,

${\mathrm{R}}_{\mathrm{reach},\mathrm{i}}$ is a reachability indicator or probability that the vulnerable function is actually invoked.

To capture cross-service dependency structure, we build a SBOM graph:

$${\mathrm{G}}^{(\mathrm{SBOM})}=({\mathrm{V}}^{(\mathrm{SBOM})},{\mathrm{E}}^{(\mathrm{SBOM})})$$

(17)

where nodes represent both microservices and components, and edges represent “depends-on” relationships. We compute the graph Laplacian:

$$\mathrm{L}=\mathrm{D}-\mathrm{A}$$

(18)

where $\mathrm{A}$ is the adjacency matrix and $\mathrm{D}$ is the degree matrix. Solving the eigenproblem:

$$\mathrm{L}{\mathrm{u}}_{\mathrm{k}}={\mathsf{\lambda }}_{\mathrm{k}}{\mathrm{u}}_{\mathrm{k}}, \mathrm{k}=1,\dots ,\mathrm{q}$$

(19)

we obtain low-dimensional structural embeddings for each node:

$${\mathrm{e}}_{\mathrm{n}}^{(\mathrm{SBOM})}=[{\mathrm{u}}_1(\mathrm{n}),{\mathrm{u}}_2(\mathrm{n}),\dots ,{\mathrm{u}}_{\mathrm{q}}(\mathrm{n}){]}^{\top }$$

(20)

For a vulnerability ${\mathrm{v}}_{\mathrm{i}}$ attached to node ${\mathrm{n}}_{\mathrm{i}}$, its structural dependency representation is:

$${\mathrm{e}}_{{\mathrm{n}}_{\mathrm{i}}}^{(\mathrm{SBOM})}$$

(21)

The full SCA-based feature for ${\mathrm{v}}_{\mathrm{i}}$ is then:

$$\mathrm{i}*{\mathrm{i}}^{(\mathrm{SCA})}=\mathrm{W}*\mathrm{depz}*{\mathrm{i}}^{(\mathrm{dep})}+\mathrm{U}*\mathrm{dep}{\mathrm{e}}_{{\mathrm{n}}_{\mathrm{i}}}^{(\mathrm{SBOM})}$$

(22)

where $\mathrm{W}*\mathrm{dep}$ and $\mathrm{U}*\mathrm{dep}$ are learnable projection matrices.

1.7. Unified Vulnerability Representation

Combining static semantics, dynamic traces and dependency signals, the unified representation for each vulnerability ${\mathrm{v}}_{\mathrm{i}}$ takes the form:

$${\mathrm{x}}_{\mathrm{i}}={\mathrm{W}}_{\mathrm{s}}{\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SAST})}+{\mathrm{W}}_{\mathrm{d}}{\mathrm{x}}_{\mathrm{i}}^{(\mathrm{dyn})}+{\mathrm{W}}_{\mathrm{c}}{\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SCA})}+\mathrm{b}$$

(23)

with ${\mathrm{W}}_{\mathrm{s}}$, ${\mathrm{W}}_{\mathrm{d}}$, ${\mathrm{W}}_{\mathrm{c}}$ and $\mathrm{b}$ to be learned.

Equivalently, we can view the encoder as a multi-branch neural network:

$${\mathrm{h}}_{\mathrm{i}}^{(\mathrm{SAST})}={\mathrm{f}}_{\mathrm{s}}({\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SAST})}), {\mathrm{h}}_{\mathrm{i}}^{(\mathrm{dyn})}={\mathrm{f}}_{\mathrm{d}}({\mathrm{x}}_{\mathrm{i}}^{(\mathrm{dyn})}), {\mathrm{h}}_{\mathrm{i}}^{(\mathrm{SCA})}={\mathrm{f}}_{\mathrm{c}}({\mathrm{x}}_{\mathrm{i}}^{(\mathrm{SCA})}),$$

$${\mathrm{h}}_{\mathrm{i}}=\mathrm{concat}({\mathrm{h}}_{\mathrm{i}}^{(\mathrm{SAST})},{\mathrm{h}}_{\mathrm{i}}^{(\mathrm{dyn})},{\mathrm{h}}_{\mathrm{i}}^{(\mathrm{SCA})}),$$

$${\mathrm{x}}_{\mathrm{i}}=\mathrm{W}{\mathrm{h}}_{\mathrm{i}}+\mathrm{b}$$

(24)

This design allows each view to undergo specialized non-linear transformation before being aligned in a common latent space. The aligned space is crucial because it enables the risk model to capture relationships such as “a static SQL injection sink that is reachable in a critical external API and located in a widely exploited library version”.

1.8. Risk-Based Vulnerability Scoring Model

The scoring model is a four-layer MLP with dimensions 512 → 256 → 128 → 1, using ReLU activations and dropout (rate=0.3) after each hidden layer to prevent overfitting.

The risk-based scoring model treats vulnerability prioritization as a supervised or semi-supervised learning task. We assume access to a set of labeled vulnerabilities:

$$(\mathrm{x}*\mathrm{i},{\mathrm{y}}_{\mathrm{i}})*{\mathrm{i}=1}^{\mathrm{N}}$$

(25)

where ${\mathrm{y}}_{\mathrm{i}}$ is a ground-truth or expert-assigned risk label (binary, ordinal, or continuous).

We define the scoring function as:

$$\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}={\mathrm{f}}_{\mathsf{\theta }}({\mathrm{x}}_{\mathrm{i}})$$

(26)

with parameters $\mathsf{\theta }$. A simple instantiation uses a multi-layer perceptron (MLP):

$${\mathrm{z}}_{\mathrm{i}}^{(1)}=\mathsf{\sigma }({\mathrm{W}}^{(1)}{\mathrm{x}}_{\mathrm{i}}+{\mathrm{b}}^{(1)}),$$

$${\mathrm{z}}_{\mathrm{i}}^{(2)}=\mathsf{\sigma }({\mathrm{W}}^{(2)}{\mathrm{z}}_{\mathrm{i}}^{(1)}+{\mathrm{b}}^{(2)}),$$

$$\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}={\mathrm{w}}^{(\mathrm{o})\top }{\mathrm{z}}_{\mathrm{i}}^{(2)}+{\mathrm{b}}^{(\mathrm{o})}.$$

(27)

For binary risk classification (e.g., must-fix vs non-critical), we apply logistic transformation:

$${\stackrel{\mathrm{ˆ}}{\mathrm{y}}}_{\mathrm{i}}=\mathsf{\sigma }(\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}})$$

(28)

For continuous risk scores (e.g., mapped from CVSS or expert scores), we adopt mean-squared error:

$$\mathrm{L}*\mathrm{MSE}(\mathsf{\theta })={\displaystyle \frac{1}{\mathrm{N}}}\sum *{\mathrm{i}=1}^{\mathrm{N}}(\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}-{\mathrm{y}}_{\mathrm{i}}{)}^2$$

(29)

The total loss$\mathrm{L}$ is defined as:

$$\mathrm{L}={\mathsf{\lambda }}_1{\mathrm{L}}_{\mathrm{rank}}+{\mathsf{\lambda }}_2{\mathrm{L}}_{\mathrm{MSE}}+{\mathsf{\lambda }}_3{\mathrm{L}}_{\mathrm{reg}}$$

(30)

where λ1=0.7， λ2=0.2， λ3=0.001.

Because vulnerability management is inherently ranking-oriented, we further incorporate a pairwise ranking loss. For any pair $(\mathrm{i},\mathrm{j})$ with ${\mathrm{y}}_{\mathrm{i}}>{\mathrm{y}}_{\mathrm{j}}$, we want $\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}>\mathrm{Scor}{\mathrm{e}}_{\mathrm{j}}$. A hinge-style ranking loss is:

$$\mathrm{L}*\mathrm{rank}(\mathsf{\theta })=\sum *\begin{array}{c}(\mathrm{i},\mathrm{j}): {\mathrm{y}}_{\mathrm{i}}>{\mathrm{y}}_{\mathrm{j}}\end{array}\max (0, 1-(\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}-\mathrm{Scor}{\mathrm{e}}_{\mathrm{j}}))$$

(31)

The overall objective combines these terms with ${\mathrm{L}}_2$ regularization:

$$\mathrm{L}(\mathsf{\theta })={\mathsf{\lambda }}_{\mathrm{CE}}\mathrm{L}*\mathrm{CE}(\mathsf{\theta })+\mathsf{\lambda }*\mathrm{MSE}\mathrm{L}*\mathrm{MSE}(\mathsf{\theta })+\mathsf{\lambda }*\mathrm{rank}\mathrm{L}*\mathrm{rank}(\mathsf{\theta })+\mathsf{\lambda }*\mathrm{reg}|\mathsf{\theta }{|}_2^2$$

(32)

After training, the scoring function induces a ranking:

$$\mathsf{\pi }(\mathrm{V})={\mathrm{argsort}}_{{\mathrm{v}}_{\mathrm{i}}\in \mathrm{V}}(-\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}})$$

(33)

which is used to define the remediation order (highest risk score first). Because the model consumes fused features from SAST, DAST, SCA and IAST, the resulting ranking naturally integrates static severity, runtime exploitability, dependency exposure and threat intelligence.

1.9. Model Architecture Selection

We employ a four-layer fully connected neural network (512 → 256 → 128 → 1) with ReLU activations and dropout (rate=0.3) after each hidden layer. This architecture was chosen over simpler models (e.g., logistic regression) due to its ability to capture non-linear interactions between heterogeneous features from SAST, DAST, SCA, and IAST. Compared to more complex deep models (e.g., transformers or graph neural networks directly applied to raw code), our MLP-based design offers a favorable trade-off between interpretability, training efficiency, and scalability in production CI/CD pipelines.

1.10. Justification Against Alternatives

Logistic Regression: Insufficient for modeling complex feature interactions.

Random Forest / XGBoost: Although effective for tabular data, they lack native support for continuous embedding fusion.

Graph Neural Networks (GNNs): While suitable for code graphs, they introduce high computational overhead and are less straightforward to integrate with dynamic and dependency features.

Transformer-based Models: Require large-scale pretraining and are computationally intensive for real-time scoring in DevSecOps loops.

Thus, the chosen MLP provides a balanced approach for learning from unified feature vectors while remaining deployable in resource-constrained environments.

Microservice- and Path-Aware Risk Aggregation

In microservice environments, risk must be understood both at the individual vulnerability level and at coarser levels (service-level, communication path-level). This enables architectural decisions such as service isolation, rate limiting, or zero-trust enforcement.

Service-Level Risk

For a given service ${\mathrm{s}}_{\mathrm{j}}$, its risk is aggregated from the scores of all vulnerabilities belonging to that service:

$$\mathrm{R}({\mathrm{s}}_{\mathrm{j}})=\mathsf{\Phi }(\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}:\mathrm{s}({\mathrm{v}}_{\mathrm{i}})={\mathrm{s}}_{\mathrm{j}})$$

(34)

where $\mathsf{\Phi }(\cdot )$ is an aggregation operator.

A simple weighted sum is:

$$\mathrm{R}({\mathrm{s}}_{\mathrm{j}})={\sum }_{\mathrm{i}: \mathrm{s}({\mathrm{v}}_{\mathrm{i}})={\mathrm{s}}_{\mathrm{j}}} {\mathrm{w}}_{\mathrm{i}}\cdot \mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}$$

(35)

where weights ${\mathrm{w}}_{\mathrm{i}}$ may encode whether the vulnerability is externally exposed, publicly exploitable, or tied to safety-critical functionality.

Alternatively, focusing on the top-$\mathrm{k}$ risk items:

$$\mathrm{R}({\mathrm{s}}_{\mathrm{j}})={\displaystyle \frac{1}{\mathrm{k}}}{\sum }_{\mathrm{i}\in \mathrm{Top}-\mathrm{k}({\mathrm{s}}_{\mathrm{j}})} \mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}$$

(36)

Path-Level Risk

Many attacks in microservices follow cross-service communication paths. Consider a path:

$$\mathrm{P}=({\mathrm{s}}_{{\mathrm{j}}_1},{\mathrm{s}}_{{\mathrm{j}}_2},\dots ,{\mathrm{s}}_{{\mathrm{j}}_{\mathrm{L}}})$$

(37)

with inter-service edges representing calls or message flows. Let the edge risk between ${\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}}}$ and ${\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}+1}}$ be $\mathrm{E}({\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}}},{\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}+1}})$. The total path risk can be approximated by:

$$\mathrm{R}(\mathrm{P})={\sum }_{\mathrm{l}=1}^{\mathrm{L}} \mathrm{R}({\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}}})+{\sum }_{\mathrm{l}=1}^{\mathrm{L}-1} \mathrm{E}({\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}}},{\mathrm{s}}_{{\mathrm{j}}_{\mathrm{l}+1}})$$

(38)

Paths with $\mathrm{R}(\mathrm{P})$ above a threshold can be flagged for segmentation, stricter authentication, or more intensive runtime monitoring.

CI/CD Integration and Privacy-Preserving IRX Analytics

From a DevSecOps perspective, the framework operates as a continuous risk-assessment component in CI/CD pipelines. Each pipeline run at time $\mathrm{t}$ yields a set of vulnerabilities ${\mathrm{V}}^{(\mathrm{t})}$ and their scores $\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}^{(\mathrm{t})}$. We can track the average risk over time:

$${\stackrel{\mathrm{‾}}{\mathrm{R}}}^{(\mathrm{t})}={\displaystyle \frac{1}{\left|{\mathrm{V}}^{(\mathrm{t})}\right|}}{\sum }_{{\mathrm{v}}_{\mathrm{i}}\in {\mathrm{V}}^{(\mathrm{t})}} \mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}^{(\mathrm{t})}$$

(39)

and the change in risk after a deployment:

$$\mathsf{\Delta }{\stackrel{\mathrm{‾}}{\mathrm{R}}}^{(\mathrm{t})}={\stackrel{\mathrm{‾}}{\mathrm{R}}}^{(\mathrm{t})}-{\stackrel{\mathrm{‾}}{\mathrm{R}}}^{(\mathrm{t}-1)}$$

(40)

Significant positive values of $\mathsf{\Delta }{\stackrel{\mathrm{‾}}{\mathrm{R}}}^{(\mathrm{t})}$ indicate that a new release has degraded the security posture, and can be used as automated gating criteria (e.g., fail the pipeline or require manual approval).

Privacy-Preserving Feature Transformation

When vulnerability analytics are outsourced to a cloud-based engine using IRX or similar packages, code confidentiality and data privacy become critical. Let ${\mathrm{x}}_{\mathrm{i}}$ be the original feature vector, potentially containing sensitive structural details. Before upload, a client-side anonymization / perturbation step produces:

$${\tilde{\mathrm{x}}}_{\mathrm{i}}=\mathrm{A}{\mathrm{x}}_{\mathrm{i}}+{\mathsf{ϵ}}_{\mathrm{i}}$$

(41)

where:

$\mathrm{A}$ is a transformation matrix that masks direct identifiers (e.g., file names, exact paths),

${\mathsf{ϵ}}_{\mathrm{i}}$ is random noise used to enforce differential privacy.

A standard Gaussian mechanism is:

$${\mathsf{ϵ}}_{\mathrm{i}}\sim \mathrm{N}(0,{\mathsf{\sigma }}^2\mathrm{I})$$

(42)

which prevents accurate reconstruction of individual code artifacts while preserving aggregate risk patterns.

Homomorphic Encryption for Cloud Scoring

For environments with strict confidentiality requirements, homomorphic encryption (HE) can be used so that the cloud processes encrypted feature vectors. Let $\mathrm{Enc}(\cdot )$ and $\mathrm{Dec}(\cdot )$ be encryption and decryption functions under an HE scheme. The cloud computes an approximate scoring function ${\mathrm{f}}_{\mathsf{\theta }}^{(\mathrm{HE})}$ over ciphertexts:

$$\mathrm{Enc}(\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}})={\mathrm{f}}_{\mathsf{\theta }}^{(\mathrm{HE})}(\mathrm{Enc}({\mathrm{x}}_{\mathrm{i}}))$$

(43)

and the client recovers:

$$\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}=\mathrm{Dec}(\mathrm{Enc}(\mathrm{Scor}{\mathrm{e}}_{\mathrm{i}}))$$

(44)

In practice, ${\mathrm{f}}_{\mathsf{\theta }}^{(\mathrm{HE})}$ must be implemented using polynomial operations compatible with HE, which can be seen as a constrained approximation of the original neural network scoring function. Although computational overhead increases, this approach offers strong guarantees for organizations unwilling to expose raw vulnerability telemetry outside their perimeter.

2. Experiments

This chapter presents a comprehensive experimental evaluation designed to validate the proposed AI-powered vulnerability prioritization model in microservice architectures. The goal is to empirically assess improvements in (i) vulnerability evidence coverage, (ii) prioritization accuracy, (iii) remediation efficiency, and (iv) stability in CI/CD security posture.

2.1. The Following Research Questions Guide the Evaluation:

RQ1. Does combining SAST, DAST, SCA, and IAST produce more actionable vulnerability evidence than individual scanners?

RQ2. Does the proposed model outperform existing prioritization baselines such as CVSS, EPSS, and SAST severity ranking?

RQ3. Does the system reduce remediation effort, measured by Mean Time To Remediate (MTTR)?

RQ4. Does integration into CI/CD pipelines reduce vulnerability risk drift across releases?

Experimental Setup

This section describes the benchmark systems, scanning tools, model configuration, and evaluation metrics used throughout the study. We evaluate three open-source microservice applications and a production enterprise environment, ensuring that results represent both controlled and real-world conditions, which is necessary for credible security research.

Target Microservice Systems

The selected applications cover diverse domains—retail, e-commerce, financial services, and mixed enterprise workloads—representing typical cloud-native architectures. All systems use polyglot microservice stacks and containerized deployments, reflecting realistic attack surfaces in production DevSecOps pipelines.

To ensure replicability, each benchmark is deployed on Kubernetes 1.30 and all scanners executed in identical controlled conditions. The industrial CI/CD data originates from a redacted partner organization and is used under a responsible disclosure agreement.

Table 1. Microservice Systems Evaluated.

ID	System	Services	Language Ecosystem	Dataset Type
S1	Sock Shop	17	Node.js / Go / MongoDB	Benchmark
S2	Bank of Anthos	12	Java / Python / gRPC	Benchmark
S3	Online Boutique	11	Go / Java / Redis	Benchmark
S4	Industrial CI/CD (Anonymized)	43	Polyglot	Real-world

S1–S3 represent controlled environments suitable for comparative methodological evaluation, while S4 provides a stress test for deployment at scale, especially relevant to enterprises maintaining continuous patching cycles and complex SBOM inheritance chains. The system heterogeneity reinforces that the evaluation does not rely on language-specific patterns.

Table 1. Microservice Systems Evaluated.

ID	System	Services	Language Ecosystem	Dataset Type
S1	Sock Shop	17	Node.js / Go / MongoDB	Benchmark
S2	Bank of Anthos	12	Java / Python / gRPC	Benchmark
S3	Online Boutique	11	Go / Java / Redis	Benchmark
S4	Industrial CI/CD (Anonymized)	43	Polyglot	Real-world

S1–S3 represent controlled environments suitable for comparative methodological evaluation, while S4 provides a stress test for deployment at scale, especially relevant to enterprises maintaining continuous patching cycles and complex SBOM inheritance chains. The system heterogeneity reinforces that the evaluation does not rely on language-specific patterns.

2.2. Scanning Configuration

All systems were scanned using unified SAST–DAST–SCA–IAST pipelines. Results were normalized into the unified feature representation:

Table 2. Analysis Sources and Evidence Extracted.

Source	Tools	Extracted Evidence
SAST	CodeQL, Semgrep	AST/CFG/DFG structure, taint propagation nodes
DAST	OWASP ZAP, Nuclei	Exploit traces, HTTP behavior, response classification
SCA	Syft + Grype, Trivy	SBOM, package vulnerability mapping (CVE, CVSS, EPSS)
IAST	Contrast Security (Trial), eBPF agent	Runtime sink reachability, invocation paths

The resulting dataset contains both symbolic code-flow representations and empirical exploitability signals. Unlike static-only ranking, this formulation is capable of distinguishing high-severity yet unreachable vulnerabilities from low-severity but actively exploited weaknesses—a critical differentiation for microservice RBVM.

Table 2. Analysis Sources and Evidence Extracted.

Source	Tools	Extracted Evidence
SAST	CodeQL, Semgrep	AST/CFG/DFG structure, taint propagation nodes
DAST	OWASP ZAP, Nuclei	Exploit traces, HTTP behavior, response classification
SCA	Syft + Grype, Trivy	SBOM, package vulnerability mapping (CVE, CVSS, EPSS)
IAST	Contrast Security (Trial), eBPF agent	Runtime sink reachability, invocation paths

The resulting dataset contains both symbolic code-flow representations and empirical exploitability signals. Unlike static-only ranking, this formulation is capable of distinguishing high-severity yet unreachable vulnerabilities from low-severity but actively exploited weaknesses—a critical differentiation for microservice RBVM.

2.3. Evaluation Metrics

We assess multiple dimensions of prioritization quality and operational impact. Metrics follow established RBVM and DevSecOps research practices.

Table 3. Metrics and Measurement Purpose.

Metric	Purpose
MRR	Ability to elevate critical vulnerabilities to top ranks
P@k	Early-stage retrieval of actionable vulnerabilities
MTTR Reduction	Reduction in engineering hours required for remediation
Risk Drift	Stabilization of CI/CD deployment security posture

Table 3. Metrics and Measurement Purpose.

Metric	Purpose
MRR	Ability to elevate critical vulnerabilities to top ranks
P@k	Early-stage retrieval of actionable vulnerabilities
MTTR Reduction	Reduction in engineering hours required for remediation
Risk Drift	Stabilization of CI/CD deployment security posture

Results: Vulnerability Prioritization Accuracy (RQ2)

This subsection evaluates whether the model ranks vulnerabilities more effectively than CVSS, SAST severity, and EPSS baselines. Ranking quality is central to RBVM because remediation resources are constrained in real security operations.We evaluate four ranking strategies:

Table 4. Metrics and Measurement Purpose.

Baseline	Description
CVSS	Industry-standard risk severity scoring
SAST Severity	Rule-based static severity ranking
EPSS	Exploit Prediction Scoring System
Ours (RBVM-AI)	Hybrid model using unified risk representation

Table 4. Metrics and Measurement Purpose.

Baseline	Description
CVSS	Industry-standard risk severity scoring
SAST Severity	Rule-based static severity ranking
EPSS	Exploit Prediction Scoring System
Ours (RBVM-AI)	Hybrid model using unified risk representation

Table 5. Prioritization Performance Across All Systems. 

Method	MRR ↑	P@10 ↑	P@20 ↑	Kendall τ ↑
CVSS	0.244	0.33	0.41	0.216
SAST Severity	0.268	0.37	0.45	0.244
EPSS	0.352	0.48	0.55	0.319
Ours (RBVM-AI)	0.524	0.72	0.84	0.487

Table 5. Prioritization Performance Across All Systems. 

Method	MRR ↑	P@10 ↑	P@20 ↑	Kendall τ ↑
CVSS	0.244	0.33	0.41	0.216
SAST Severity	0.268	0.37	0.45	0.244
EPSS	0.352	0.48	0.55	0.319
Ours (RBVM-AI)	0.524	0.72	0.84	0.487

To better illustrate the improvement in prioritization effectiveness across different baseline strategies, Figure 4.2 visualizes the comparative MRR performance, clearly highlighting the advantage of our RBVM-AI model.

Figure 2. Prioritization Performance Comparison.

Figure 2. Prioritization Performance Comparison.

The model outperforms EPSS by +48.9% MRR improvement and CVSS by +115%, demonstrating that unified exploitation + dependency + code-flow evidence significantly enhances ranking discrimination. Kendall τ ≈ 0.49 indicates strong concordance with expert prioritization labels. Notably, EPSS performs substantially better than static-only CVSS/SAST, corroborating that dynamic exploitability signals are necessary but still insufficient without structural reachability context.

Results: Remediation Efficiency (RQ3)

The practical justification for RBVM is not ranking alone, but reduced engineering cost. We measure MTTR reduction following realistic patch workflows derived from internal remediation ticket data.

Table 6. MTTR Reduction Across Systems. 

System	Baseline MTTR (days)	MTTR w/ RBVM-AI (days)	Reduction
S1 Sock Shop	9.5	5.2	45.3%
S2 Bank Anthos	14.1	7.4	47.5%
S3 Online Boutique	10.9	6.1	44.0%
S4 Industrial	31.7	15.2	52.0%

Table 6. MTTR Reduction Across Systems. 

System	Baseline MTTR (days)	MTTR w/ RBVM-AI (days)	Reduction
S1 Sock Shop	9.5	5.2	45.3%
S2 Bank Anthos	14.1	7.4	47.5%
S3 Online Boutique	10.9	6.1	44.0%
S4 Industrial	31.7	15.2	52.0%

Results indicate a consistent 44–52% reduction in remediation effort, confirming that misprioritization—not patching difficulty—is the dominant source of delay in vulnerability mitigation. S4 shows the highest improvement, showing that enterprise environments with complex dependencies benefit the most from accurate RBVM.

Results: CI/CD Risk Drift Stability (RQ4)

We integrate the model into the CI pipeline of S4 to determine whether deployment security becomes more stable.

Table 7. Comparison of Risk Drift.

Weeks	CI Runs	Avg Risk Drift (CVSS Gate)	Avg Risk Drift (RBVM-AI Gate)
Week 1	44	+0.173	+0.021
Week 2	39	+0.226	+0.018
Week 3	42	+0.241	+0.026
Week 4	41	+0.198	+0.014

Table 7. Comparison of Risk Drift.

Weeks	CI Runs	Avg Risk Drift (CVSS Gate)	Avg Risk Drift (RBVM-AI Gate)
Week 1	44	+0.173	+0.021
Week 2	39	+0.226	+0.018
Week 3	42	+0.241	+0.026
Week 4	41	+0.198	+0.014

Where CVSS gating leads to unstable risk oscillations, RBVM reduces drift magnitude by ≈ 88–93%, preventing accumulation of neglected but exploitable vulnerabilities over successive releases.

4. Conclusion and Discussion

4.1. Conclusion

This work presented a unified AI-driven Risk-Based Vulnerability Management (RBVM) framework tailored for microservice architectures, integrating heterogeneous evidence from SAST, DAST, SCA, and IAST sources into a consolidated vulnerability representation. Unlike traditional prioritization relying primarily on static severity indicators such as CVSS, the proposed method incorporates both exploitability signals and software supply chain dependency reasoning, enabling a more accurate risk estimation aligned with real-world attack feasibility.

Through extensive empirical evaluation across three open-source microservice benchmarks and one industrial-scale CI/CD environment, the proposed approach demonstrated significant performance improvements. Experimental results confirmed that the hybrid model improves Mean Reciprocal Rank (MRR) by 48.9% over EPSS and by more than 115% over CVSS-based prioritization. Furthermore, the framework consistently reduced Mean Time to Remediate (MTTR) by 44%–52%, indicating tangible operational benefits for security engineering teams. Integration into a real production pipeline also showed a notable reduction in risk drift (ΔR(t)), improving CI/CD deployment stability by approximately 88–93% and supporting more mature DevSecOps practices.

In summary, this research validates that vulnerability management for microservices cannot rely on single-source detection nor static risk indicators. The proposed model establishes an evidence-driven prioritization paradigm that aligns security decisions more closely with exploitability, reachability, and supply-chain exposure, offering a meaningful advancement for modern cloud-native security programs.

4.2. Discussion

The findings extend several implications for both research and industry. First, the demonstrated improvement in ranking accuracy suggests that vulnerability analysis must evolve from isolated finding enumeration to multi-dimensional vulnerability characterization, where source code semantics, runtime traces, and SBOM-derived dependency risks jointly contribute to risk estimation. This multidimensional approach is particularly critical for microservice ecosystems where vulnerabilities propagate through inter-service call paths and dependency inheritance rather than residing solely in first-party code.

Second, the substantial reduction in MTTR indicates that misprioritization—rather than patch complexity—is a dominant factor in delayed remediation cycles. This observation reinforces the value of AI-enhanced triage mechanisms capable of contextualizing vulnerabilities beyond static scoring. The results particularly highlight the operational importance of integrating IAST runtime reachability and SCA supply chain exposure into risk models, especially as organizations adopt large-scale third-party component reuse.

Third, the observed reduction in CI/CD risk drift underscores that vulnerability prioritization must be embedded into continuous delivery pipelines rather than executed as a post-release audit. Such integration supports preventive, release-blocking risk controls, thereby improving the overall resilience of software delivery processes.

Despite its strong performance, the framework exhibits several limitations that warrant further investigation. The model’s effectiveness depends on the availability of high-quality dynamic traces, which may not always be obtainable for low-traffic or highly regulated systems. Additionally, while IAST instrumentation yields valuable insights, its runtime overhead may limit applicability in latency-sensitive services. Furthermore, the supervised model relies on expert-provided or historically observed risk labels, suggesting the opportunity for semi-supervised or weakly supervised risk learning in future work. Lastly, although privacy-preserving transformations and homomorphic scoring were discussed, further study is needed to ensure scalable and efficient deployment in highly confidential environments.