## 4 Results and Discussion
### Rq3  
The vulnerability detection step was performed based on the aggregation of the two sub-results, and the outcomesof this step are shown in Table 9. \begin{table}
\begin{tabular}{c c c} \hline \hline  & **GPT-4** & **GPT-3.5** \\ \hline Components with Incorrect & 0 & 23 \\ Service Detection & & \\ Components with Incorrect & 14 & 96 \\ AuthGuard Detection & & \\ Components with Incorrect & & \\ Protection Level & 4 & 112 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Results of sensitive service identification by the two GPT models. Detected vulnerability refers to correctly identified instances that align with the CWE-653 vulnerability. These are cases where a service handling sensitive data can be accessed from a component without adequate protection. This scenario poses a potential threat of data leakage or unauthorized use, either due to developer oversight or user malfeasance. In contrast, a false vulnerability is the number of cases that, although detected as vulnerabilities by the pipeline, are in fact not vulnerabilities because either the sensitivity level has been incorrectly scored high or the protection level has been incorrectly scored as low. The undetected vulnerability is the more severe problem: cases where the CWE-653 vulnerability was detected during manual validation but was not detected by the pipeline due to incorrect protection or sensitivity level. As evident, our assumptions about GPT-3.5 were validated. The aggregated poor results from previous steps led to only a 1% successful detection rate for vulnerabilities. However, our initial naive assumption about the identification of sensitive services had very serious consequences for GPT-4 in the first round. Of the total number of errors that should have been identified, only less than 45% were successfully detected, and 20% of the errors (i.e., cases where a vulnerability should have been detected but was not) were in the high-sensitivity category, meaning that attempts to retrieve or manipulate highly-sensitive health, financial, or other personal data could theoretically be accessed fromthe front-end using an interface that was not supposedto handle such data. A significant part of the problem was identified in the RQ1 investigation as the monolith service, where services did not have one well-defined task and role but rather developers crammed several similar procedures into them without any consideration that all levels from non-sensitive to high-sensitivity data categories could appear within a single service. This problem caused the sensitivity level of the services to vary enormously in many cases, where a service was identified as having either medium or high sensitivity in a single component, while in another it was declared irrelevant to sensitive data. To address these issues and improve the detection results, we significantly enhanced the vulnerability detection criteria for GPT-4. If a service was categorized as handling sensitive data in any component of the application, it was deemed sensitive across the entire application. Consequently, it was assigned the highest sensitivity level observed in any affected component. A spectacular improvement in the results can be seen in Table 10. \begin{table}
\begin{tabular}{c c c} \hline \hline  & **GPT-4** & **GPT-3.5** \\ \hline Detected Vulnerability & 40 & 17 \\ False Vulnerability & 0 & 8 \\ Undetected Vulnerability & 49 & 80 \\ Undetected High-Sensitivity Vulnerability & 10 & 16 \\ Undetected & & \\ Medium-Sensitivity & 31 & 56 \\ Vulnerability & & \\ Undetected & & \\ Low-Sensitivity Vulnerability & 8 & 8 \\ \hline \hline \end{tabular}
\end{table} 
Table 9: Results of the vulnerability detection. The detection success rate has jumped from 45% to 88.76%, and the high-sensitivity category misses have completely disappeared. In other words, with this tightening, which could have been performed in the sensitive element detection step as a post-processing step, we achieved an improvement of 44%.